突然、会社を辞める人がいます。今、彼の仕事を完了する必要があり、あなたはそれを割り当てられています。彼が何をしていたのかわからない(90%完了したのか9%だった)、残り物をどのように管理しますか?
- 最初から始めましょうか?90%完了した場合はどうなりますか?
- 彼が何をしたかを理解しようとしますか?それがナンセンスだったらどうだろう?
突然、会社を辞める人がいます。今、彼の仕事を完了する必要があり、あなたはそれを割り当てられています。彼が何をしていたのかわからない(90%完了したのか9%だった)、残り物をどのように管理しますか?
回答:
何をすべきかを理解するためには、自分が何を持っているか、そしてそれがどれだけ良い形であるかを知る必要があります。
そのため、すべてのソースをざっと見て、何があるかを確認することから始めます。はっきりしている場合、不足しているものを終了するのが最も簡単です。単体テストを実行して、何が機能し、何が機能しないかを調べます。
はっきりしない場合は、新しい単体テストで何が機能するかを考え始めてください。これが不可能な場合は、チームリーダーに問題があり、解決できない可能性があることを伝えます。その後、彼は、残っている作業をとにかく救うべきか、それともあまりにもひどいので、やり直す必要があるかを決定できます。
他の人が書いたものに加えて、私はあなたが男に直接接触していた人と話をすることをお勧めします。あなたの説明から、彼は一人で働いていたと理解していますが、それでも彼は誰かに報告していたに違いありませんか?そして、彼が作成したものをテストしたQA担当者がいるかもしれません...これらの人は、(通常)少なくとも去る前に彼が彼のプロジェクトでどこまで進んだかについて大まかな考えを持っているべきです。もちろん、彼から提供された情報/製品が完全に信頼できないことが判明し、レイオフに貢献していなかった。
これについて上司と話し合い、残りのコードの初期調査/テストに時間枠を割り当て、仕様と要件を理解します。これは、数人の月の時間スケールでのプロジェクトではおおよそ1日、1人以上の年の作業のプロジェクトでは最大で1週間などです。
この最初の調査の後、大まかな見積もりが必要です。
その後、マネージャーと再度座って決定を下すことができます。
私の経験では、これは珍しい状況ではありません。残念ながら、ここには本当に2つの問題があります。
1)このプロジェクトの残り2)最初にこの混乱に陥った理由
(1)では、プロジェクトのサイズ/複雑さを考慮する必要があります。1週間の作業である場合、おそらく最初からやり直す必要があります。1年分の作業であれば、既存のコードから何を回収できるかを確認する必要があるかもしれません。
いずれにしても、これらの手順をすぐに実行する必要があります。
a)マネージャーに大きな問題があることを伝えます
b)プロジェクトの仕様を取得し、達成する必要があるものを完全に理解します。または、仕様がない場合はプロジェクトのスポンサーに相談します。
c)マネージャー/顧客などと話をして、プロジェクトの状態が何かを知っている/考えているかどうかを確認します。
それが済んだら、コードの調査/戦略の策定を開始することができます。
(ユニットテストがあなたを大いに助けるとは思わない-彼らは、書かれた関数が実際に動作するかどうかをあなたに伝えるかもしれないが、どの関数がそこにあるべきかを教えてくれない。
次に私がしたくないのは、存在するコードのアーキテクチャの概要と、これが仕様で定義されている問題にどのように対応するかを取得することです。次に、これらの各メインコンポーネントのサブコンポーネントを調べ、全体像にどのように適合するかを確認します。これを行うと、(大体)不足しているコンポーネントがわかります。
何が存在するかがわかったら、既存のコードを調べて、それが意図したとおりに動作するかどうかを確認する必要があります。
これをすべて完了すると、残りの作業量を見積もることができます。
パート(2)に関しては、あなたの会社は雇用ポリシー/スタッフの保持ポリシーを検討し、プログラマーに進捗の説明責任を持たせる方法を見つける必要があるかもしれません。
最後に、急いで辞めた場合に会社にこれが起こらないようにする方法も検討する必要があります。
何が機能して何が機能しないかを確認するには、ソフトウェアを試して実行する必要があります。
次に、残っているドキュメントを検討する必要があります。書面による要件はありますか?特定のタスクがありますか?タスクは何らかの方法で追跡されていますか?誰もがそれをテストしてきました-もしそうなら、彼らは何がされて何がそうでないかを知るでしょう。
行動計画は次のようになると思います。
どの要件が完了したかをマークします(テスターのようにシステムをすばやく実行します)
コードを見てください-それを理解できますか?よく書かれていますか?
明らかに、それが90%完了し、コードが適切に記述されていれば、それを終了するだけです。
おめでとう、これはあなたの上司に輝いて本当にポジティブな印象を与えるチャンスです。ここにあるのは、貴重な機会です。それで、あなたは何をする必要がありますか?
まず、コードを取得します。彼はすべてをチェックインしていなかったかもしれません(私たちにこれをした人はチェックインしませんでした)。
次に問題をトリアージします。要件を確認し、どの部分にコードが記述されているように見え、どの部分に記述されていないかを書き留めます。これは、完了していないものの大まかなリストです。次のステップに進むにつれて成長します。次に、コードを調べて評価し、実行して、コードが書かれていても現在何が機能していて何が機能していないかを確認します。動作していない部品をリストに追加します。ユニットテストを探してください(あなたがそれらを見つけたら驚かされるでしょう、彼らが失敗していることを知っているので締め切りの直前に救済する人々はそれらを書かない傾向があります)。少なくとも、あなたはそれがどれほど悪いかについて良い考えを持っています。また、要件を調べて、必要な質問に答えてください。多くの場合、プロジェクトの失敗は、要件が不十分であり、開発者が(無数の理由で)さらに質問することを望まないために発生します。
次に、プロジェクト計画を作成します。要件からの質問のリストから始め(文書に正式に記入してください)、次に作業を完了するために必要なことをリストします。それぞれにかかる時間を見積もってください。現在存在しているものが回収可能かどうかを判断します(そうでない場合は、理由がないことを正当化する準備をします)。
次に、プロジェクトマネージャー(および、2人の異なる場合は上司)とミーティングを行い、悪いニュースを伝えます。(誰かが突然去って、中断したところから取り直さなければならない場合、ほとんど常に悪いニュースです。優秀な開発者は、人々を急いで放置しません。健康上の問題のために誰かが去った場合は例外かもしれません。)あなたの議論では、あなたが必要な答えを得るかもしれず、あなたとPMはプロジェクト計画を少しやり直すかもしれません。
PMとその他の重要な利害関係者(PMが誰を特定するか)、回答が必要な質問のコピー、および実行したプロジェクト計画を送信して、会議をフォローアップします。
これで、実際のコーディングを開始するために必要なものが揃ったので、作業を始めましょう。
それまでの間、あなたはおそらくこのプロジェクトを救うために何か他のものを引き離されたでしょう。他の人がピックアップできるように、またはプロジェクトの完了後に自分がピックアップできるように、作業が適切に行われていることを確認してください。つまり、同じ種類のこと、何が行われ、何が行われないかを言う文書、およびすべてのソースコードのチェックイン(行われない場合はトランクに必要ではありませんが、他の誰かがアクセスできる場所) 。
既存の仕事から引き離されていない場合は、上司と仕事時間にどれだけの時間を費やすかを上司に相談する必要があります。これは、残業が必要になる可能性がある時期の1つであり、高く評価されます。実際の締め切りに近ければ近いほど、経営陣は必死になり、締め切りが迫っていれば、残業手当や大きなボーナスを手に入れることができるかもしれません。この作業によって他の作業が大幅に遅れる場合、そのプロジェクトの利害関係者がそれを認識していることを確認する必要があります。
プロジェクトの回収に成功したら、次のパフォーマンスレビューでそれについて自慢してください。