project-management - 失敗したプロジェクトを軌道に戻すにはどうすればよいですか?

Question

失敗した/失敗したプロジェクトの典型的な話を聞いたことがあるはずです。

経験の浅いプログラマーのチームが 24 時間年中無休で働いています
バグは、新しいバグを導入するためだけに修正されます
お客様は、基本的なこと (保存/クエリ) などを行うことさえできなかったと叫んでいます。
仕様を受け継ぐことに慣れたプログラマーは即興に苦労する
自動化された単体テストがないことが状況を悪化させる
紙の上では見栄えのするアーキテクチャドキュメントは、実際には守られていませんでした
そもそも適合性がテストされていないサードパーティのコンポーネントがボトルネックになる
マイルストーンを逃した後のマイルストーン
実際に実行する必要がある作業量について誰も同意しないため、チームは納期を決めることができません
技術的なリーダーシップがない、または技術的な問題に対処できるカウボーイコーダーがいない

では、あなたが10番として連れてこられるとしたら、あなたの最初のステップは何ですか?

更新: まず第一に: 参加してくれてありがとう。うーん...私は #10 として参加しています。クライアントに提案を行ったとき、私は最初のアーキテクトであり、ソリューションを固定していました。残念ながら、私は別の場所に配属されたため、配達の責任を負うことができませんでした。:)

それが既存のデスクトップアプリケーションの Web 化であるとしましょう。私は今、＃10として連れてこられています。悲しいことに、逃げることは選択肢ではありません。これは、アジャイルのベストプラクティスに従うことで逆転できると確信しており、コミュニティからアイデアを引き出したかっただけです.

より大きな問題は、おそらく次のようなものです。開発チームが仕様を持っておらず、実行中のアプリケーションの (ベースライン化された) コードしか持っていない場合、元のソリューションでは、コードを見てその場でビジネスルールを抽出する必要がありました。現在、経験の浅いプログラマーは、VB 6.0 のコードを見てドキュメントを欲しがるのをためらっています。では、アジャイルプロセスを導入する場合、どのようにこれと戦うのでしょうか?

score 22 · Accepted Answer

Vyas、私はこの質問を書くことができたような気がします. 私の以前の仕事は、1 年間の開発の後に失敗した KVM プロジェクトを復活させることでした。仕様は、ユーザーマニュアルと開発者の同様の製品での経験の形式でした。結局、私は 3 人のアセンブリプログラマに C を教え、ゼロから再構築しました。4 か月で製品を市場に投入することに成功しました。（それから私は辞任しました。図を見てください。）

特に経験の浅いチームでは、私がもう一度やりたいことのいくつか:

1. 経験の浅いプログラマーのチームが年中無休で働い
ている

「再充電」するために、プロジェクトから (短い!) 休憩を取ります。たぶん一日、午後、またはあなたの長い昼食。それは「古い」プロジェクトの終わりと成功の始まりを示します。
彼らが戻ってきたら、彼らのお尻を取り除くことに同意してもらい、あなたが頼りになる男、チアリーダー、そして防弾チョッキになることを約束してください. あなたは集合的にチームであり、あなたの仕事は彼らの道を築き、気を散らすものを取り除き、彼らを導くことです.
どんなに小さくてもすぐに成功するように計画し、「できる」という姿勢を維持します。

8. マイルストーンを逃した後のマイルストーン
9. 実際に実行する必要がある作業の量について誰も同意しないため、チームは納期を決めること
ができません 3. 顧客は、基本的なことさえできなかったと叫んでいます (節約/クエリ)など

少し噛んでください！ 各ピースを可能な限り分解してから、小さなコンポーネントに対処します。「落とし穴」を早期に特定し、プロジェクト全体の範囲をより適切に把握できるようになります。
インターフェイスを定義します。チャンクを分離できるときはいつでも実行してください。 これにより、パラメーター、前提条件、仮定、内部で何が起こるか、および戻り値が既に決定されているため、並列開発が可能になります。それをスタブ化し、他のモジュールとテストを個別に構築できます。
優先する。 最初に顧客に影響を与える欠陥や問題に焦点を当てます。新機能は最後に来ます。必要に応じて、バグのあるコードを配信するのではなく、機能を延期します。
責任を割り当てます。 それぞれの専門分野のボランティアが好まれますが、各タスクには1人が責任を負う必要があります。
欠陥を追跡し、再現、特定、修正に役立つすべてを記録します。配達時に残っているものはすべて記録して、顧客が驚かないようにします。

4. 仕様を伝承することに慣れたプログラマーは即興で苦労
する

スペックの詳細は、必要になる直前に各ピースを作成します。誰もが現在のタスクを理解し、全体像を把握している限り、きれいで完全である必要はありません。
開発者がコーディングする準備ができたら、一度に 1 つずつ実装について話し合います。必要に応じてスケルトンを自分で作成し、チームに「内臓」を埋めさせます。「即興」ではなく、各タスクに集中してもらいたいと考えています。
質問が発生したときに答えられるようにします。あなたの主な目標は、チームの生産性を維持することです。

2. バグは、新しいバグを導入するためだけに修正される
5. 自動化された単体テストがないことが状況を悪化させる

できるだけ早く単体テストを計画して開始します。可能であれば、チーム外のリソースを参加させます。
小さな問題が大きくなる前に、または隠れてしまう前に修正してください。ひとつひとつの小さなピースへの自信が、全体への自信を築きます。

7. 使用されているサードパーティ製コンポーネントがボトルネックになり、そもそも適合性がテストされていない

コーディングしていないときに解決策をブレインストーミングします。可能であれば、彼らにあなたの進歩を止めさせないでください。それらをカプセル化またはコーディングできますか? それらを交換しますか？

一般的な提案:

チームの先頭に立ってください。 チームが問題にぶつかる前に、問題を予測して解決しようとします。必要になる前に必要な情報を収集します。
常にコミュニケーションをとってください。 驚きを望んでいないことを明確にし、懸念、質問、ステータス、障害などを 1 日を通して求めます。コラボレーションを促進し、チーム全体で「発見」を共有します。
すべての成功を祝います。 巧妙な解決策を称賛する、問題が解決したときにドーナツを持ってくる、新しい機能を実演するなど、あなたがチームに感謝していることを示すものなら何でも構いません。
各タスクを完了してから、先に進みます。成功への直接の障害とならないものを微調整、強化、または作り直すために時間を無駄にしないでください。
チーム、顧客、経営陣に対する約束を守りましょう。

頑張ってください -- 情報をお寄せください!

score 11 · Accepted Answer

逃げるか、新しい仕事を見つけてください。これは死の行進であり、スケープゴートが必要です。

多くの場合、死の行進では、チームメンバーに特に過酷な時間帯や週末に働くように依頼したり、「問題に (十分な) 体を投げつけよう」と試みたりして、さまざまな結果をもたらし、しばしば燃え尽き症候群を引き起こすなどして、プロジェクトの方向性を正そうと必死に試みます。

score 9 · Accepted Answer

リリースを凍結し、プログラムの問題の修正を開始します....顧客の苦情に優先順位を付けて対処し (会社のビジネス側が優先順位を付けることができます)、プログラムを実行します。最大の問題を解決したら、コードのクリーンアップを開始します。他の開発者にタスクを割り当て、すべての新しいコードにコーディングプラクティスを適用し始めます。

やりたいことが何でもできるなら、本当の問題が何であるかを見て、それらに対処してください。それが、ソフトウェアをゼロから開発するために新しいチームを編成することを意味する場合は、それで構いません。ただし、少なくとも主要なバグを修正するようにしてください。新しい機能を導入する必要はありません。それらは問題を悪化させるだけであり、プログラムが機能せず、問題が解決されない場合、クライアントを失うことになります。

score 5 · Accepted Answer

10 番は明らかに最悪の問題であり、少なくとも他のすべての問題の根源です。いくらかの創造性とプロジェクトを遂行する能力を備えた人を見つけて、最初からやり直すことを含め、何でも自由に実行できるようにします。

score 5 · Accepted Answer

あなたが本当に良い給料をもらっていることを願っています。いずれにせよ、私の計画は、次の順序でこれらの手順のようなものになります。

0) チーム全体で特徴や機能を追加するのをやめる。次の手順を手順 5 まで行っている間、バグに対処できるようにしてから、バグ修正を停止して機能開発を再開します。

1) 私が「人員配置の逆法則」と呼んでいるものを適用します。弱いチームメンバーは、より優れたより速いチームメンバーの速度を落とします。一般に、遅れたソフトウェアプロジェクトでは、人員を追加するのではなく、削除する必要があります。そのため、個々の貢献者としてのチームメンバーの質を評価する必要があります。おそらく何人かはいるので、チームから弱いスタッフを排除します。これを行うには、コードをレビューしてバグ修正を調べ、誰がコードを悪化させているのか改善しているのかを突き止め、チームのためにそれらを切り刻むことによって行うのが最善です。今は指導する時ではありません。最適な時期に状況を「修正」するために、最高の人材が必要になります。彼らを解雇したり、再割り当てしたりできない場合は、残りの全員にコーヒーか何かを飲ませてください。

2) コード自体を評価します。適切に構築されていない、または適切に抽象化されていないコードの領域を特定します。市外局番がうまく構築されていないか、および/または本来の機能が明らかに脆い場合は、書き直してください。この時点では苦痛に感じますが、長い目で見れば時間の節約になります。繰り返されるバグや修正の履歴は、回収できないコードを特定するのに役立ちます。コード領域またはモジュールが基本的に適切に構築されているが、インターフェイスレベルで適切に抽象化されていない場合、それはリファクタリングに適しているはずです。これはかなりの時間を節約し、便利なコードです。書き換え領域、リファクタリング領域、および適切な領域のリストを保持します。

3) 特徴や機能において、最終的に望む場所への堅牢で完全なソリューションをもたらすと思われる新しい合理的なアーキテクチャを定義します。アーキテクチャは、クリーンな状態から始めると最適ではないかもしれませんが、実際には、現在持っているものと、なりたい場所を一致させることができます。

4) 利害関係者と協力して、最初のリリースを受け入れられるようにするものを決定し、「後の」リリースに向けてできるだけ多くの機能を提供するようにします。何もカットできないかもしれませんが、できるなら今がその時です。

5) バックグラウンドでのバグ修正作業を停止し、定義された作業を (残りの) チームに割り当てて、残りの機能の合理的な新しい実装計画を見積もります。彼らはスケジュールを所有する必要があります。スケジュールをロールアップし、かなり控えめにします。これで、実際に実行可能で堅牢なものがいつできるかについて、合理的な予測ができました。

6) 残りの機能を実装し、残りのバグに対処してリリースを強化します。ここでは、ソース管理、単体テストなど、通常の優れたソフトウェア開発プラクティスがすべて守られていると想定しています。

7) できるだけ多くの障壁を取り除き、チームができるだけ早く作業を開始できるようにします。

8）問題を監視し、できる限り手を汚して支援します。チームのすべてのメンバーの生産性を維持しながら、あなたが支援できる範囲でより厄介な問題に取り組むことを申し出てください。

幸運を！

score 3 · Accepted Answer

これはもはや技術的なリーダーシップに関するものではなく、現在はプロジェクト管理に関するものです。

あなたはテクニカルリーダーとして、タイタニック号のデッキチェアを移動するだけです。もし私が事実上のプロジェクトマネージャーだったら、次のようにします。

1) プロジェクトのスポンサーと利害関係者を特定します - 公式のものと実際のものの両方。

2) 彼らのところに行き、プロジェクトを 1 週間「休止」するよう依頼します。

3) 彼らが同意しない場合は、このプロジェクトから離れてください。

4) 彼らが同意する場合は、プロジェクトのタイムアウトを 1 週間呼び出します。すべてが停止します。

5) 1 週間かけてプロジェクトの重要人物と話し合い、実際のプロジェクトの状態を把握します。

6) これらの議論に従事している間に、プロジェクトの復旧計画の策定を開始し、範囲、スケジュール、予算、および人員の間で可能なトレードオフを強調します。

7) 週の終わりに、考えられるプロジェクトシナリオのどれが実行可能か (もしあれば) を決定します。

8) これらのシナリオの最良のものをプロジェクトのスポンサーと利害関係者に持ち帰り、交渉を開始します。

9) 前進する方法が合意されたら、プロジェクトを再起動して祈る - おそらくこの順序ではない.

score 2 · Accepted Answer

常識はすでにマキシムによって指摘されています（死の行進をやめてください）。しかし、理由が不明なため、継続したい場合は、同様の状況での私の経験を紹介させてください-おそらく役立つかもしれません.

それは、良いコンピューターの仕事がなかなか見つからない眠そうな旧市街での私の最初の仕事でした。私が雇われたのは、私が十分に熱心で、何もないよりはマシかもしれないと経営陣が考えたからです (私は、私に PC を提供する費用を節約するために自分のコンプを持ち込むことを提案し、経験のためだけに働くことを提案しました)。

このプロジェクトは、死の行進の状況のために作成者によって放棄され、コード内のすべてのコメントを削除し、その他の難読化を実行した後に姿を消しました。誰もwin32 / MFCのものを知りませんでした。

古き良き紙と鉛筆でコードを勉強し始めただけで（たくさんの修正と修正）、20日以内に、変数を含むコード全体と、何がどこで起こっているかを知ることができました。

この知識を武器に、私はこれまで誰も実現できなかった重要な作品を作ることができました。もちろん、これは大海の一滴に過ぎませんでしたが、経営陣はクライアントの信頼を買うことができました。

クライアントが納得し、時間を稼ぐことができるようになると、プレッシャーが取り除かれました。これにより、チームに希望が戻ってきて、私たちは永久に打ちのめし始めました。6 か月後、私はプロジェクトリーダーに昇進し、9 か月後には修正プログラムが出荷されました (多くの進行状況のデモと、その間に目に見えてますます満足しているクライアント)。

おわかりのように、成功の要素は直接複製することはできません。しかし、最初にプロジェクトに希望を吹き込む必要があることを要約します。進捗状況を示し、同僚、経営陣、クライアントの信頼を勝ち取ります。それが整ったら、技術的なものも修正する必要があります - 方程式のこの部分を置き換えるものは何もありません.

それがありそうにないと思われる場合、そのすべてのハードワーク（ああ、そうです-想像もしなかったようなたくさんの仕事-なぜそれが死の行進と呼ばれると思いますか）は無駄であり、始める前からやめたほうがよいでしょう.

私には選択の余地がなく、熱血で、必死に仕事が必要でした。何かが魔法のように機能する可能性のある技術的な詳細と、すべてが所定の位置に収まりました。私は本当にその作品で多くの善意と自尊心を獲得しましたが、長い目で見れば、それは私が大騒ぎで語ることができる単なる物語であり、知っている少数の人々を除いてそれ以上のものはありません.

物事はあなたにとって異なるかもしれませんが、それはあなたが決めることです.

幸運を

score 1 · Accepted Answer

要約には14項目があります。あなたはそれらすべてを行うことはできません。それで、最初のステップは何ですか？

これがあなたが最初にしなければならないことです-一つのことを改善してください。

基本的な品質の問題があります。（＃2-5）
アーキテクチャとコンポーネントの問題があります。（＃6、7）
スケジュールに問題があります。（＃1、8、9）

品質に取り組むことができます。正式な単体テストでは、TDDに向かうことが役立ちます。アーキテクチャの問題によりテストが遅くなるため、これは難しい場合があります。

あなたは建築に取り組むことができます。これは、おそらく成果物に見えない手直しを伴うため、より難しいかもしれません。ただし、品質の問題は修正される可能性があります。または、基本的なテストの問題によって悪化する可能性があります。

あなたはスケジュールに取り組むことができます。他の修正（つまり、品質またはアーキテクチャ）がないと、スケジュールの問題を修正しても何の牽引力も得られない可能性があります。

人々の態度の全体的な改善は、1つの成功（成功）からできるだけ早く始めることから来ると思います。最もぶら下がっている果物は何ですか？

1つの長年のバグ？そのバグを見つけて修正するための1つのユニットテストスイート？
1つの主要なアーキテクチャ上の特徴？誰もが自分のキューブに投稿できる図は役に立ちますか？プレゼンテーションは物事を明確にするのはどうですか？
1つの新しいユースケース？実際に機能する1つの新機能は？

score 1 · Accepted Answer

これはこの主題に関する良い本です：

大惨事の解きほぐし：ソフトウェアプロジェクトを軌道に戻す

score 1 · Accepted Answer

あなたが本当にそれを軌道に乗せなければならなかった場合（ベイリングがオプションでない場合）

それは管理の失敗だと受け入れることから始めましょう。次に、厳密ではあるが軽いプロセスの実装に進みたいと思うかもしれません。

GURUなしで成功裏に実装するのが最も簡単なので、何らかの形のアジャイルをお勧めしますが、ペアリング、無慈悲なリファクタリング、レビュー、スパイキング機能、可視性、TDD、1週間のサイクル、 1 日 8 時間労働 (お気づきのように、8 時間を超えると生産性が低下する傾向があります)...

何も切り取らないでください。アジャイルの一部は他の部分に依存しています。ペアリング、リファクタリング、およびテストがなければ、事前の設計を排除することはできません (アジャイルの最大の失敗の 1 つ)。

その管理面も忘れてはいけません。開始する 1 週間のイテレーション (毎週デモ)。一定の適応。問題に対処するために毎日非常に短いスタンドアップ。(最大 15 分に留める、テーブルを長くするなど) バーンダウンチャート、クライアントを含むコアチーム。

毎週 15 分間のミーティングと 2 週間のイテレーションだけでアジャイルと呼ぶことはできませんが、正しく行えばチャンスが得られる可能性があります。優れたアジャイルコンサルタントを迎えて、作業を開始するためのトレーニングを受けることができます。

また、何が機能し、何が機能しないかを常に評価します。うまくいかないことを修正する準備をしてください。その週の開発の成功と失敗を分析するための毎週のミーティング。

全体的には機能し、不安定なチームを一列に並べることができますが、簡単ではありません。最も素晴らしい点は、現在の開発に多大な時間を費やすことなく実装できることです。あなたはただ成長し続けますが、あなたはそれをより良くします。

score 1 · Accepted Answer

できれば逃げる。

そうでない場合は、コーディングや欠陥の修正など、プロジェクトを不安定にするすべての活動を停止する必要があります。

現在地を評価する

要件をより小さな「マイルストーン」に分割する

実用的な本を読んでください (Mcconnell の「ソフトウェアプロジェクトサバイバルガイド」が思い浮かびます。

すべての問題とリスクを特定します。それらすべてを関係者全員に伝えます。

作品を一つ一つ丁寧に作業します。

改善やマイルストーンの達成を祝いましょう。

幸運を。あなたのシナリオはかなり悪いように聞こえます。それは救済できないかもしれません - そして状況を改善するために変化しなければなりません。

score 1 · Accepted Answer

まず、失敗する可能性があることを覚悟してください。それを受け入れることができない場合は、挑戦しないでください。そして、それにはスケープゴートであることも含まれます（実際に起こります）。経営陣はそのような観点からそれを見ません (つまり、彼らは意図的/意識的に「あなたを設定する」わけではありません)。しかし、それは企業環境の現実です。あなたが責任を負う場合（多くの場合、そうでない人よりも多くの給料がかかります）、物事がうまくいかない場合、あなたの頭はブロックに向けられます. 長期的にもそれに固執する準備ができている必要があります。私はかつて、衰退したプロジェクトを修正するために8か月間クライアントサイトに配置されました. ご覧のとおり、ここにある他のブログ投稿者の 1 人は、リリースバージョンの準備が整うまでに 9 か月を費やしました。

さて、あなたの努力にもかかわらず、すべて洋ナシの形になる可能性に問題がないと仮定すると、これは私が提案することです:

バグ追跡システムはあなたの一番の親友になるでしょう。複雑なシステムを全体として理解することは期待できないので、「チャンキング」すると役立ちます。また、バグ追跡システムを使用すると、問題をまとめて、一緒に作業している他の人に配布できます。
対処すべき技術的課題と政治的課題の両方があります。あなたはコーダーであり、これを行う方法を知っているので、技術的なことは一般的にそれほど悪くはありません。政治的なものははるかにトリッキーで、絶望的にコースを外れてしまった船の舵を取り、バミューダトライアングルにいます。最大の課題は、多くの場合、クライアントの間の否定的な感情の流れを食い止めることです (例: クライアント:「これらのカウボーイは自分たちが何をしているのかわからない」、「彼らは私にこれを約束したが、実現しなかった」、「私には自信がない」これらの人でこれ以上」）。
手始めに、顧客に謝罪し、プロジェクトを立て直すために何をしようとしているのかを具体的な言葉で伝えます。私はプロジェクトの歴史を見てきました.個人的には、このシステムにかなりのお金を払っていたら、私も腹を立てるでしょう.私が取り組むつもりの最初のことは...」<-ビンゴ、あなたはちょうど取ったプロジェクトの責任は、後戻りができないことを意味します。すべてかゼロかです。
他の数人がここでそれを言っていますが、私も同意します。新しい機能の追加を停止します。彼らが言及していないのは、クライアントを満足させるためにこれを行う必要があるかもしれないということです (この課題には技術的および政治的な側面があることを思い出してください)。
ビジネスドメインをできる限り理解してください。手に入れることができる要件ドキュメントをすべて読んでください。最初に何が議論されていたのかわからないため、遅れてプロジェクトに参加することで、あなたは大きな不利な立場に置かれます。悪魔は細部に宿る。これは、私が救済できなかった後期プロジェクトで私を沈めたものであり、誰もが緊張していて、マイナーな要件を逃しました。当時、それは大したことではなく、簡単に修正できたはずでしたが、政治的に言えば、ラクダを壊したのはわらでした. 役立つかもしれない 1 つの戦術は、クライアントのサイトに数週間出かけることです。
時は金なりであることを理解してください。技術的な問題だけではありません。クライアントは、正しくないもの、または配信されていないものに対して支払いました。あなたの会社はリソースを使い果たしました。プロジェクトの予算をすべて使い果たした可能性があります。ビジネスは現在、お金を失っています。そして、ここで再び新機能の問題が発生します。はい、人々はそれらを追加しないで安定化すると言っています。しかし、新しい機能を追加することは政治的に有益な戦術になる可能性があります.仕様外の仕事のために新しいお金が入ってくるので、経営陣は喜んでいます.
私はあなたやあなたのコーディングクルーがとんでもない時間をかけて配信することをお勧めしません. 通常午後 5 時に出発する場合は、代わりに午後 6 時 30 分または午後 7 時に出発します。あなたとあなたのコーディングボーイは、何週間も続けて 1 時間か 2 時間、週末にはおそらく 4 時間から 5 時間の余分な作業を一貫して維持できます。毎晩午後 9 時または午後 10 時まで働くと、約 2 週間で燃え尽きてしまいます (それ以上かかる場合もあります)。その時点を過ぎると、プロジェクトでのあなたの余分な時間は、良いことよりも害を及ぼしています。万が一、上司がこれに異議を唱えた場合は、選択してください。彼らが要求することを実行する (つまり、より多くの時間働く) か、「私はこのプロジェクトに取り組むためにすでに余分な時間を費やしています - 私は長い間ここにいるので、もしそれが私の死であるなら、私はこのプロジェクトを終わらせるつもりです.しかし、それが私が喜んで投入できる時間の限界です。しかし、結果に備えてください（技術的なものと同じくらい政治的な状況を思い出してください）。
「やめて仕様を書いて、やめてこれを…」と言っている人がここにいます-ごめんなさい、私はここであなたに同意することはできません、それは非現実的です。プロジェクトはすでに停滞しており、経営陣やクライアントがここで最後に望んでいるのは、「すべてを停止しなければならない...」ということです。私は以前にこれを試したことがあり、クライアントと経営陣に「停止して詳細なシステムテスト計画を作成するまで、バグは発生し続けるでしょう。2 週間かかるでしょう」と言いました。クライアントは望んでいませんでした。これを支払うために、経営陣はコストを負担するつもりはありませんでした. たまたま、バグが発生し続けました。
「ジャグリング」を学ぶ - プログラマーがあなたを待っていないように、事前にタスクを計画しておく必要があります。これは通常、自分でコーディングすることが少なくなることを意味します。一般に、コーディングを開始する前にプロジェクトのスケジュールを立てることで、これを達成するのが最善です。プログラマーは、現在取り組んでいることを終えた後、次に何をしているのかを知っておくべきであり、「次に何をするのですか?」と尋ねに来るべきではありません。彼らはすでに知っているはずです。
特に、特定が困難な問題がソフトウェアに繰り返し発生する場合は、組み込みの回復ユーティリティを使用してください。例えば; バグを追跡して修正するのに 12 時間かかる場合があります。差し当たり問題を修正するためにユーティリティ (「ハック」と読みます) を入れるのに 2 時間かかる場合があります。時間と勢いはエッセンシャルであり、残念ながら応急処置が必要になる場合があります.
クライアントの気分をよく観察してください。彼らは、あなたが「彼らの側にいる」ことを知る必要があります (例: クライアント:「製品は受け入れられません」、あなた:「同意します。もし私があなたの立場だったら、私たちのロバを蹴ります。私が言えることは、私がそれに賛成していることだけです。すべてが機能するまで休むことはありません」）。クライアントがあなたのサイトに戻ってきたとき、彼らは実際にあなたを助け始めます. たとえば、経営陣からの圧力からあなたを守ってくれるかもしれません。
例によってあなたの部下をリードしてください。「私はプロジェクトに取り組むために少し戻ってきます。あなたも戻ってきてくれるなら助けていただければ幸いです」と「私たちの混乱ではないことはわかっていますが、まだ掃除するつもりです」とにかく、クライアントに良質のソフトウェアを入手してもらいたい」. プログラマーは一般的に、自分をこのような状況に陥らせた会社についてはあまり気にしませんが、それが自分の会社またはクライアントの場合は気にする場合があります (「可能性があります」)。

私がここで見た提案の多くは、かなり高度な力を前提としています (たとえば、「プロジェクトを停止して適切に再起動する」または「新しい機能にノーと言う」など)。あなたは伝統的に真のマネージャーよりも変化に影響を与える力が少ないでしょう。これは「あきらめる/試さない」という意味ではありません。創造的になり、通常はしないことを行う必要があることを意味します (つまり、「ソフト」スキルまたは対人スキルを使用します)。

ここにいる多くの人がプロジェクトを保釈し、逃げろと言っている。私はこれまでに 3 つのどうしようもなく遅れたプロジェクトに取り組んできました。2件は直せましたが、1件は直せませんでした。個人的には、遅れたプロジェクトを引き受けることは気にしません。結局のところ、起こりうる最悪の事態はあなたが解雇されることです:)

score 1 · Accepted Answer

厳しい状況では、顧客の信頼はゼロであり、基本的にその状況では何があっても成功することはできません.

すべての意図と目的のために、プロジェクトには再起動が必要です。残念なことに、既存のショップは通常、最初からやり直してすべてを再評価する機会を得ることができません。

言いたくないのですが、開発を中断して、何がうまくいかなかったのかを解明するために 1 か月を費やす必要があります...

結果は、実現可能な 6 か月から 1 年間の納品の計画である必要があります。これにより、サードパーティのコンポーネントに関する実際の貿易調査と、必須アイテムに焦点を当てることができます。また、コードベースを破棄することもオプションである必要があります。新しいソース管理プロジェクトを開始し、特定のモジュールポートピースに到達すると、意味がありゴミを置き去りにします。

アジャイルは素晴らしいものであり、実際の計画が整ったら有効なアプローチです。しかし、それはあなたの顧客との壊れた関係を修復するつもりはありません...またはすでにそこにあるすべてのジャンク.

score 1 · Accepted Answer

あなたがスケープゴートでないことを確認してください
カットスコープクリープ
トリム機能の「要件」
より速い開発サイクルを実装する (おそらくアジャイル/スクラム/XP など)

score 1 · Accepted Answer

あなたの経験を通して読んだ後の主な学習の要約は次のとおりです。

マキシム
1：これが「死の行進」ではないことを確認してください

Ellie
2: 提供されたものが機能することを確認する 3: コードベースをアーキテクチャにリファクタリングおよび Realgin する / ベストプラクティス 4: 本当の問題は何かを調べる: チームは技術的に提供する能力があるか?

Kendall
5: テクニカルリーダーシップの利用可能性を確保する

Bill K
6: アジャイルプロセスを実装する (TDD でない場合は少なくとも自動化されたユニットテスト、進捗状況を可視化する短い反復) 7: 顧客の同意を得る 8: 機能しないものを捨てる準備をする (希望的観測はさておき)

ウォーレン
9: 残っているチームメンバーに最初からやり直す機会を与えてください。

ティム
10: チームをやる気にさせ、改善が目に見えるようになったら報酬を与える

jsl4980
11: あなたのチーム (ほとんどのインプレッション) と顧客からのスケジュール通りの賛同が必要です [これによりさらに疑問が生じます。チームがあなたのスケジュールを守るのに十分な能力があるかどうかを顧客が尋ねたらどうしますか? チームが提案しているタイムラインが彼らの理解不足を示しているだけであることをあなた自身が知っている場合はどうなりますか]

Ather
12: チームはコミットしていますか?
13: 正式に QA を行っていますか?

パトリック
14: まだ開発されていないモジュールのアーキテクチャ/設計のベストプラクティスに最初からやり直し、再設計し、再準拠します。

score 0 · Accepted Answer

何をするにしても、段階的に実行してください。

まず、それはアドイン機能ではなく、アプリの修正です。新しいものを追加しないでください。リファクタリングするだけです。誰かがあなたにシステムに導入するように頼む新しいものにはノーと言ってください。

アプリ全体を改善しようとしないでください。チームを取り上げ、特に単体テストを使用して、できる限りのベストプラクティスを使用して、一度に1つの側面に焦点を合わせます。

テスト駆動開発のみを使用してください。その場合、動作のどの部分が理解できないかがすぐにわかります（何をテストするかわからない場合は、テストをコーディングできません。

だからここにロードマップがあります：

変更する必要のある重要な部分を特定します
この動作を暗示するコードを分離する
コードの残りの部分でこのコードの出現を見つけます
この知識と大規模なTDDを使用してリファクタリング
この特定の部分が機能するまで、統合、テスト、および修正します
手順に戻る

上司に状況を明確にしてください。時間とお金がかかり、苦痛を伴うでしょう。理由、あなたが何をするか、そしてあなたには他の方法がないか、それが再び失敗することを説明してください。

何よりも、初めてきれいにしようとしないでください。できることをリファクタリングしますが、最初に作業する部分のアーキテクチャ全体を変更することを期待しないでください。アプリケーション全体でプロセスを数回繰り返す必要があります。

奇跡はありません。ただ方法と忍耐。

score 0 · Accepted Answer

あなたが最初からプロジェクトに関わっていたのなら、言いたくないのですが、会社はあなた (そしてチーム全体) に取って代わるべきです。

実際のプロジェクト管理プロセスを備えた有能なチームで再分析し、この状況の経験を持つプロジェクトマネージャーが主導する必要があります。

元のコーダーは誰も、それを保存する「新しいプロジェクト」に取り組むべきではありません。彼らは他のプロジェクトに移ることができます (解雇される必要はありません) が、プロジェクトを新鮮に見るためには、全員を入れ替える必要があります。

そしてもちろん、経営陣は、プロジェクトが予想よりも大幅に遅れるという事実を理解し、それに乗り出す必要があります。経営陣がこれに同意しない場合 (チームを交代し、経験豊富なリーダーシップを見つけ、一歩下がってやり直す)、@マキシムは正しいです。そこから出てください。

score 0 · Accepted Answer

1) 最初に評価するのは、チームのメンバーがプロジェクトにコミットしているかどうかです。そうでなければ、他のことをしても意味がありません。献身的で献身的なチームを編成しない限り、災害を防ぐことはできません。2) チームに QA があることを確認します。3) 顧客への反復および増分リリースの合理的な計画を考え出す。私たちが混乱しているため、顧客がすぐにすべてを手に入れる方法はありません. お客様の優先順位に基づいて、機能の小さな増分を頻繁にお客様に提供します。これにより、顧客は何かが起こっているのを見ているので、少し神経質になりません。

score 0 · Accepted Answer

そこに行って、次の手順に従いました：

安定させる

実際のストーリーを収集します: コードベースの良し悪し、開発者の良し悪し、本当にやらなければならないこと (最低限)、誰がいつやらなければならないか。
残業を減らす（疲れている人は良くも悪くも仕事がうまくいかない）
悪いものを取り除き、新しい/良いものを入力してください - 交換の側で間違いを犯してください (多くは燃え尽きてしまい、強制的な変更さえ感謝する可能性があります)
悪い/不要なコードへのアクセスを削除します (価値の 80% を提供するコードベースの 20% に焦点を当てます)
適切なコードのみが組み込まれるように、ベースコードのプラクティスを導入します (ベースをこれ以上損傷しないでください)。

コントロール

アプリコンポーネントに重点を置いたチームを実装する (可能な限り切り離す)
コード管理、リリース管理、リスク管理、QA などを導入する (成功できるように環境を構築する)
あなたのクライアント/スポンサーに良い面をつけてください - たとえそれが多少安定した非常に小さなリリースであっても、勝利を収めてください - そして変更管理を行います (何が要求されるかを制御します)

前進する

計画を立てる (計画は不可欠であり、Ike によれば計画は役に立たない - 欠けているものを見つけて目標を設定するために計画を立てる必要がありますが、将来を語ることを期待してはいけません) - 継続的な計画が必要です
従業員を積極的に管理する - 良い人が良い製品を作る - 最高の人材を確保し、維持する
時間の経過に伴うリファクタリング - 進行に合わせてコードをクリーンアップします。一度にすべてを修正する余裕はないかもしれません。時間をかけて修正し、よりクリーンなコードベースを提供します。
勇敢に前進する - 時間外に配達にもっと積極的になるチームをテストする (ただし、ストレスを与えないでください)

score 0 · Accepted Answer

アジャイルリファクタリング。顧客が何を望んでいるのかを特定して優先順位を付け、既存のコードから短いスプリントで最も重要なものを作成します。頑張ってください:)

project-management - 失敗したプロジェクトを軌道に戻すにはどうすればよいですか?

20 に答える 20

何をするにしても、段階的に実行してください。

だからここにロードマップがあります：

Related

Reference