なぜプロジェクトは遅れやすいのでしょうか?
1. ソフトウェアの研究開発は創造的な仕事です
プロジェクトの遅延は一般的な現象であり、マネージャーにとって最大の悩みの種です。しかし部外者には理解できない。それは明らかにあなた自身の計画ですが、なぜいつもこれほど多くの問題が起こるのですか？最終的には、これは私たちの仕事の性質によって決まります。私たちがやっていることはクリエイティブな仕事であり、家を建てるようなものではなく、具体的な手順があります。関数を実装するとき、関数の書き方や、関数を書く前にコードが何行あるのかはわかりません。
私自身の経験に基づくと、プロジェクトの遅延には他にも 2 つの理由があると思います。
2. 仕事では緊急事態がたくさんあります
仕事量を評価するときは、過去の経験に基づいて評価します。このような経験的な評価は、現実世界の設定では信頼できません。緊急事態には対応できません。実際の開発過程では予期せぬトラブルが多すぎました。
3. コラボレーション間の高い結合
技術者の仕事の結合度が高すぎます。最初から、プロダクト マネージャーが要件を提案し、UI デザインのプロトタイプ、UE デザインの経験を積み、プログラマーがシステム設計を行い、コードを書き、テスターがテスト ケースを書きます。それらはすべてリンクされており、リンクのいずれかで「事故」が発生すると、時間を延期する必要があります。
仕事が遅れる一般的な理由
仕事が遅れる一般的な理由のリストは次のとおりです。
- 需要の変化とは通常、変化し続ける新しい需要または需要の詳細を指します。
- ニーズ評価の作業量が不十分であり、機能実装の難易度が過小評価されている。
- 要件が正しく理解されておらず、機能が正しく実行されていません。それは最終テストまたはドッキング中にのみ発見されました。
- 一時的に挿入する必要があります。たとえば、バグがオンライン上に突然現れ、修正する必要があります。
- 新しい要件自体に論理的な問題があり、実装前に発見されたのではなく、実装の過程で発見されました。
- セルフテストが注意しないと、テストであまりにも多くの問題が見つかり、修正されるバグが増えていきます。
- 臨時スタッフの変更。
- 計画から逸脱した後、適切な措置を講じなかった場合。
- 技術的な問題の調査中に問題が発生し、実装計画を変更する必要がありました。
……
それは私たちにできることは何もないということですか？あまり。問題よりも方法の方が常に多く、発生するすべての問題に対する解決策がある限り、予定通りにオンラインに接続することは可能です。もちろん、複雑な問題を一度に解決することは困難ですが、幸いなことに、反復することは可能です。プロジェクトのレビューは、各プロジェクトの終了時に実行する必要があります。
プロジェクトの遅延を解決するにはどうすればよいですか?
これがプロジェクトの遅延に対処するための私の解決策です。レビュー - 問題の発見 - 問題の分解 - 解決策の開発 - 反復 - レビュー
1. 問題を確認して見つける
復習：前回の延期の理由は何でしたか？問題の原因を調べます。たとえば、前回は需要の変化が原因でした。
2. 問題を分解して解決策を立てる
次に、分解の問題があります。なぜ変化が必要なのでしょうか? この機能の方が重要だからです。この答えは本当ですか? この機能は本当に重要ですか? まあ、それは本当です。では、基準は何でしょうか？ない場合。それから私はそれを解決する必要があります。この標準を使用すると、次回新しい要件が発生したときに、それをこのバージョンに追加するかどうかを迅速に決定できます。解体はまだ続けられますが、新たな需要による遅れなのでしょうか? はい、新しい要件があり、起動時間が変更されていないためです。それでは、次に新たな要求に直面したとき、より長い開発期間を費やすことができるでしょうか?
この方法の利点は、毎回上達を実感できることです。デメリットは期間が長すぎることです。しかし良いニュースは、私たちは他の人の経験から学ぶことができるということです。他の人が通った穴を再び通る必要はありません。
プロジェクトの遅延を解決するための 3 つの重要な要素
私の長年のプロジェクト管理の経験に基づいて、プロジェクト遅延の問題を解決するには 3 つのことを行う必要があると考えています。
1. プロジェクト開始前: 要件管理
プロジェクトを開始する前の要件管理には 4 つの重要なステップがあります
1. 要件の優先順位付けについて合意に達する
まず、要件の優先順位付けについて合意に達する必要があります。最も重要で満たさなければならない要件は何ですか? 各社異なる場合があります。私はビジネス価値とユーザー価値の 2 つの側面に基づいてそれらを分類します。
ビジネス価値とは、企業に直接利益をもたらし、運営コストを削減し、企業の長期戦略目標を達成する機能を指します。ユーザー価値とは、ユーザー エクスペリエンスを向上させ、ユーザーの効率を向上させ、ユーザーの問題点を解決できる機能です。
これら 2 つの側面に基づいて、4 象限図を描き、ビジネス価値とユーザー価値の 2 つの側面に従って、すべてのニーズを異なる象限に分類できます。商品価値が高く、ユーザー価値も高い商品に。すぐにやるべきです。商品価値が高くユーザー価値が低いニーズを二番目に優先するか、商品価値が低くユーザー価値が高いニーズを優先するかは、企業の実情に応じて判断する必要があります。
なぜ要件を優先するのでしょうか? 時間は限られており、やるべきことが多すぎます。ビジネス価値とユーザー価値に基づいて解体した後もニーズがたくさんある場合は、重要と緊急の2つの側面を使用してそれらを解体し続けることができます。
2. 要件の目的を明確にする
合意に達した後の 2 番目のステップは、要件レビュー中に最初に要件の目的を説明することを製品に要求することです。私たちがやりたいことだけではなく、達成したいこと。これには 2 つの利点があります。
- 全員を巻き込み、チーム全員の価値を引き出し、共同で共創することでより良いソリューションを実現します。
- その後、構築した機能が目標に一歩近づいているかどうかが明確にわかります。ない場合。その後、レビューするときに、より的を絞った方法で問題の原因を見つけることができます。
3. 要件の詳細を明確にする
3 番目のステップは、開発者が要件の詳細を把握する必要があることです。すべての開発者は、細部を見抜く能力を養う必要があります。
コードの世界には 0 と 1 だけがあり、カジュアルなものは何もありません。製品がその要件を伝えるとき、製品はシステムの具体的な実装を知りません。彼はいくつかの詳細を知りませんでした。そのため、多くの要件を作成する過程で繰り返し確認する必要がある内容が多くなり、それがうまく行われていないと、テスト中に多くの細かい問題が反映されてしまいます。たとえば、商品に「今回はイベントを開催します」と記載されている場合、ユーザーは 29 個以上の注文で送料無料になります。非常に単純な要件のように思えますが、システムが十分に複雑な場合、開発者は店舗間の状況をどうするかを検討する必要があります。仮想グッズが含まれている場合はどうすればよいですか? ストアが他のアクティビティを設定しており、それらが競合する場合はどうすればよいでしょうか? 後から要望があれば49送料無料になりますか？レビュー中にこれらのことが考慮されていない場合は、プロセス中に製品とのコミュニケーションを維持する必要があります。初めてここに来る人は恥ずかしくて聞けない人もいますが、実はそんなことはありません。この能力は蓄積するのに時間がかかります。
要件を明確にすることには、次の 2 つの利点もあります。
- 評価の作業負荷はより正確になります。
- 要件に隠れた問題を早期に発見します。
4. 完全なプロジェクト開始スケジュールを出力する
4 番目のステップは、要件を上下に同期させて、需要計画を生成することです。まず、ニーズを細分化し、大きなニーズを小さなニーズに変換します。次に、小規模な要件のワークロードを評価します。自分の個人的なスケジュールをエクスポートします。その後、部門は要件を内部で統合し、部門の計画完了フォームを出力します。最後に、他のチームメンバーとプロジェクト全体のスケジュールを作成します。通常はガントチャートを作成します。これにより、実行中に問題を見つけやすくなります。
異常事態
これら 4 つの重要なステップは、言うのは簡単ですが、実際にうまく実行するのは困難です。それができれば基本的に需要管理には大きな問題はありません。もちろん例外もあるでしょう。たとえば、需要が決定された後、それを変更することはできますか? 一般的な要件を決定した後は、一時的な変更を行わないことが最善です。特別な事情がない限り。
では、特別な状況とは何でしょうか？これは、より緊急で、低コストで、ビジネス価値が高く、ユーザー価値の高い要件が実際に存在する場合に、要件の優先順位ルールを策定する利点です。私たちは変えることができます。チームのメンバー全員がこのルールに同意する限り、要件の変更を実装するのが簡単になります。
では、リーダーがルールに従って要件を変更しなかったらどうなるでしょうか?
誰が責任を負い、誰が決定を下すのか。私たちの視点は異なるため、価値の高いタスクと考えているものが必ずしも正しいとは限りません。これは現場の原則であり、要件を実現するか否かが決まる前は、プロジェクトチームの一員として自分の意見を言うことはできますが、最終的に担当者がやると決めた場合には毅然とした態度で臨むことです。それを実装します。
2. プロジェクトの開始: プロセス管理
プロセス管理の鍵は、情報の非同期の問題を解決することです。私の解決策は次のとおりです。
1. 毎日立食朝礼を行う。
朝に朝礼をしても無駄だという人も多いが、管理職は会議を通じて仕事を進めるしかないということだろう。朝礼が複雑だったり、時間がかかったりするわけではないと思いますが、これだけ決まった「コミュニケーション」の事項があるからこそ、みんなで考えて、自然と今の仕事を計画通りに整理して進めることができるのです。ここでは、当社で起立朝礼を行うための具体的な手順をご紹介します。
- まずチーム内で合意に達します。朝礼の目的は報告ではなくコラボレーションであることを明確にしましょう。一人あたりたったの2分。話す時間をコントロールしましょう。
- レポートの内容を決定します。その日の計画が実際の進捗と一致しているかどうかを全員で話し合います。何か問題が発生しましたか?サポートが必要ですか?
- スピーチの順序は固定されており、スピーチ中に他の人がコメントしたり答えたりすることはありません。具体的な問題については、会議後に関係者と協議します。
- 朝礼の司会者は非常に重要で、プロセスと時間を管理し、本題から外れた発言をした場合は注意を促す必要があります。
- 最後に議事録を作成し、誰かが遭遇した問題や要望、プロジェクト全体の進捗状況が正常かどうかだけを記録します。
集合時間は、正式な勤務時間の 30 分後 (9 時など) にすることをお勧めします。9:30に始まります。10時前に終了。注: 当社はフレックスタイム制を採用しており、9:30 に会社に到着することができます。
朝礼はチーム内の情報の非対称性の問題を効果的に解決し、全員が互いのプロジェクトの進捗状況をよりよく理解し、協力し合うことができます。さらに、誰もが面目を保ちたいと考えています。自分が立てた計画が完了しなかった場合、計画通りに完了できなかった理由を言わなければならないのは非常にストレスであり、このプレッシャーは無意識のうちに日々のタスクの完了と集中力に影響を及ぼします。 。
朝礼を報告会にしてしまい、最終的にはほとんど情報のない合宿会になってしまう企業も少なくありません。このツールが使いにくいわけではなく、正しい方法で使用していないだけです。上で述べた原則を思い出していただければ、あなたのチームに合った朝礼を企画できると思います。
2. 部門を越えた連携の場合、毎日の「表比較」が必要
部門を超えた連携であれば。また、情報を同期するための「テーブルの照合」も毎日行う必要があります。
3. 主要なノードをフォローアップします。
オンラインになるまで待たずにプロジェクトの進捗状況を確認すると、問題が見つかっても解決する時間がなくなります。
4. 異常な問題に対処するためのメカニズムを開発します。
すべての異常事態に対しては、対応計画を立てる必要があり、対応計画があれば、少なくとも問題を解決するためのプロセスが存在し、パニックは起こりません。解決するのははるかに簡単です。
5. 独自の質問リスト ライブラリを作成します。
多くの大企業は、このような製品問題リストのライブラリを持っています。カスタマー サービスの同僚がユーザーの問題に対処する場合、キーワード検索を通じて共通の解決策を見つけることができます。これにより、問題に対処する顧客サービスの効率が大幅に向上します。同じアプローチは実際の開発でも使用できます。おそらく、同僚が昔に遭遇した問題は、他の同僚も遭遇する可能性があります。この場合、キーワード検索を行うことで、本来は半日かかっていた問題が1分で解けることもあります。この質問リストライブラリを作成する場合、最初にフォーマットを定義する必要があることに注意してください。これにより管理が容易になります。
上記を実行すると、プロジェクトは予定通りに開始できるようになりますか? 多分。ここで最も重要なのはそれを実行する人だからです。人材管理は芸術です。詳しくは後ほどお話します。
3. プロジェクトの終了後: プロジェクトを確認します。
検討会：全員参加
それをうまく行う場合は、それを標準化し、複製可能にする方法を見つける必要があります。
うまくいかない場合は、対応計画を立てる方法を見つける必要があります。
プロジェクトの遅延を防ぐためのいくつかのオプション
最後に、プロジェクトの遅延を防ぐための私の個人的な経験について話したいと思います。
1. 大規模プロジェクトは段階的にテストに移行する必要があります。
テストと設計の両方の作業を 1 つの期間に集中させないでください。バージョンの反復期間は 1 か月を超えてはなりません。
2. テストのための時間を確保する
開発者はタスクを完了するたびに、テスト時間を確保する必要があります。同時に、開発者との合意形成も必要で、開発が遅れた場合は、他の同僚の進捗に影響を与えないよう、残業をして進捗を追いつく必要があります。
3. 一般的な異常事態に対処するための基準を策定します。
それが冒頭にありました、本当に需要が変化するのであれば、需要を変化させるための基準を作らなければなりません。要件は変化する可能性がありますが、変化した後にどのように対処するか。これも明確にする必要があります。バージョンに直接入れて時間をかけて解決できるものもあれば、破棄できるものもあります。公開時には変更を加えないように注意してください。
4. プラン B を立てます。
予期せぬ緊急事態に備えた計画は何ですか? たとえば、誰かが一時的なリクエストをした場合はどうすればよいですか? 技術的な問題を克服できない場合はどうすればよいですか? マネージャーとして、事前に代替案を考えておく必要があります。
5. 2 つのリリース計画を作成します。
1 つの計画は全員の作業計画が統合された後のリリース時期に基づく内部計画であり、もう 1 つはオンライン起動のための外部計画です。私たちのチームは、オンライン化するために内部時間を追求する必要があります。しかし、何か問題が発生した場合、確保された時間は緩衝地帯となります。もちろん、社内向けには 9 月 10 日、社外向けには 9 月中旬など、社外に対して曖昧な発売時期を与えることもできます。
上記は、プロジェクトの遅延に対処した私の経験の一部です。それがあなたにインスピレーションをもたらすことを願っています。