私は1年前に最初はリンク構築/ SEO関連のマーケティング会社に雇われましたが、実際にはWeb開発者であり、必死になって仕事に就きました(私はまだかなり若く、大学2年生を終えたばかりです) )。 3日目から、上司は私がそんなことにはまったく興味がないと気づき、彼がWebベースのアプリのアイデアを持っていたので、それを計画し始めました。
私はそれを行うのに2か月以上かかることはないと推定しましたが、それを作成していたとき、それをさらに改善するためにさらに多くのものを追加したいことにすぐに気付きました。
そのため、私自身の開発は約4か月続きましたが、その後、エンタープライズサイズのアプリになり、別のプログラマーを雇って一緒に作業しました。彼の仕事は素晴らしかったが、私はプログラマー/プロジェクトマネージャーに任命されたため、期限付きのマイルストーンを設定する必要があり、ほとんどの場合、作業が多すぎて、経験から、私は本当に楽観的な期限を設定することができました。私たちはまだ機能を追加し続け、アプリケーションのアーキテクチャを2回変更しました。
私の上司は素晴らしい人であり、機能を追加すると、物事が行われるべき時間枠が拡大するので、彼は私や他の人に腹を立てませんでした。しかし、私は計画を立てるのが苦手でした(私はまだそうです)。
プログラミングの面でたくさんの経験を積んだのですが、それでも管理/計画のスキルが不足しているので、頭がおかしくなります。そのため、昨年、私はおそらくこのアプリに約8か月の作業を費やし(明らかに私の研究がアプリに影響を与えました)、今月はクローズドベータ版としてリリースします。だから私の質問は、プロジェクトの計画/管理をどのようにして上手くできるのか、どのように時間を見積もるのですか?目標を設定する際に何を考慮しますか。
もう一人が街から引っ越してきたので、また一人で働いています。しかし、私はそれを維持するために私たちを雇うと確信しているので、私はそれをより良くする必要があります。
トピックに関するヒント、ポイント、または何かをいただければ幸いです。
Joel Spolskyによる優れた記事を以下に示します。 http://www.joelonsoftware.com/items/2007/10/26.html
これは非常に単純なプロセスであり、基本的に、過去の見積もりの誤りを追跡することにより、見積もりがどれほど間違っているかを見積もることを提唱しています。時間が経つにつれて、物事を行うのにかかる時間ではるかに良い推測ができるようになります。これは即座の修正ではありませんが、ソフトウェアプロジェクトの正確なスケジューリングは非常に困難です。
彼はまた、プロジェクトを非常に小さな(そして理論的には推定しやすい)部分に分割することを提唱しています。
見積もりを上手く行う唯一の方法は、それをもっと行うことです。経験の浅い開発者は、一般的に過度に楽観的です。あなたが書いたものから、見積もりが問題であるようには見えません、それは scope creep でした。
最終的にはプロジェクト管理についてのクラスができますが、簡単な概要として、PMは、スケジュールを設定して順調に進めるだけではありません。また、プロジェクトチャーター/その他のドキュメントで最初に定義されたプロジェクトが作業対象のプロジェクトであることを確認する責任もあります。あなたの場合、小さなアプリから企業全体のアプリに移行したため、これはうまくいかなかったようです。これは、特にプロジェクトの開発者でもある場合は、管理が困難です。開発者は常に、作業するすべてのものを無期限に追加および改善したいと思う傾向があり、リリース部分に実際に到達することはありません。 PMとして、開発者に彼らの計画が範囲外であるか、X機能がYの作業を開始するのに十分であると伝える必要がある場合があります。
タイムライン、依存関係などを計画する方法を知ることの一部は、経験から得られます。ただし、そうは言っても、Web開発やプログラミングとは非常に異なるスキルセットです。あなたが得ているその経験の一部は、プロジェクト管理はおそらくあなたのものではないということです、そしてそれで恥ずべきことは何もありません。正直なところ、あなたがまだ勉強の途中であることを知って、彼らがあなたから完全なプロジェクトマネージャーを期待していたことに驚いています。私は、プロジェクト管理を長年専門的に行ってきたが、まだそれを十分に理解していない人々を知っています!
あなたが本当にお金を必要としているのでない限り、私はあなたがこの仕事についてあなたの研究にもっと重点を置くことを勧めます。 Web開発を本当に楽しんでいて、成功したい場合は、そのタイプの作業の知識とスキルセットの向上に焦点を当て、このプロジェクト管理の役割から離れてください。上司に、噛む以上の力で噛み砕き、組織に害を及ぼす可能性のある個人的な制限にぶつかったことを悟ったことを恥ずかしがることはありません。彼と一緒に仕事を続けたいが、厳密には開発の役割を果たしたいと彼に伝えてください。彼が素晴らしい上司である場合、彼はそれがあなたとあなたの両方にどのように利益をもたらすかを認識します。
私たちを大いに助ける1つのことは、すべてのプロジェクトで使用する標準の見積もりテンプレートを用意することです。これにより、開発者が会議やクライアントとのコミュニケーション、プロジェクト管理、単体テスト、QAおよびUATテストのサポート、ドキュメントなど、見積もりに忘れてしまう可能性のある時間を含める必要があります。すべてのピースを追加すると、8時間の開発時間が22時間または23時間に簡単に変わる可能性があります。
あなたがまた苦しんだスコープクリープは、新しい見積もりを意味します。毎回例外なく。新しい機能を追加することを決定した場合(または追加を要求された場合)、追加の時間数とそれが期限を延期する距離を知る必要があります。ほとんどの場合、製品をプッシュし、スコープの変更を次のイテレーションに移動することをお勧めします。
よりクールなものを追加するために継続的に遅延するのではなく、製品を入手して機能を追加します。また、スコープのクリープが開発者からのものでないことを確認してください。スコープの変更は、開発者からではなく、組織のクライアントまたは利害関係者から行う必要があります。その言い訳は本当にありません。追加したいものを思いついたら、実際にそれほど壊れていない限り、現在のバージョンを遅らせるのではなく、利害関係者とアイデアを確認した後、それを次のバージョンに追加してください。製品の発送は、持つべき重要なスキルです。これまでに作成されたすべてのソフトウェアは、実現する前に、いくつかの追加の光沢のある新しいものを追加できます。誘惑に抵抗し、将来のリリースでの新機能の計画を立ててください。