解(solution)
危険の予兆
- 何を作るか開発を始める段階でわかっていない
そもそもわかっていなければ開発に着手してはいけないはずです、見積もりもできないし、PJの終了が見えません。これは大きな損をするに決まっています。契約段階で前提条件を付けて、その前提が崩れたら契約を見直すか、責任を切り離す必要があります。
仕様がわかっていない段階で、条件のない受注は絶対にしない！！
＿ - 仕様が決まっておらずあとから機能が追加
納期を間に合わせるために行き当たりばったりで追加しない。PMとしては仕様変更は契約変更して納期を伸ばすしてもらうべき。それができない場合な受注しない。
「そんなこと言ったら仕事がなくなるわ」とおっしゃる場合は、そのリスクを許容する選択をしたという意味になります。たとえ億を超える赤字も甘んじて受忍すべきとなります。リスクを受容する場合は、リスク分析をして、最悪いくらの赤字になるかを計算し、受注すべきか経営判断を仰ぐ必要があります。
機能追加をする場合は、正しく、工程を後戻りさせ、設計を見直して、やり直し、製造に入ることをします。そうしなければスパゲッティーは必至です。
＿ - 設計がされていない。
設計はしてください。「アジャイルなど設計しないじゃないか」といわれるかもしれませんが、「NaOHのアジャイル考」(たいしたものではない)からすると、アジャイル開発におけるサイクルは、設計プロセスであって、設計成果物を利用して、製造を効率化できるに過ぎないと考えています。つまり、サイクルにおける成果物と、レビュー議事録(意見要望等)を合わせて設計書なのであって、サイクルで機能要件設計が完了した後、サイジング設計、性能設計、その実装、運用含めた総合試験を経てSIN可能となるわけです。
なので記録に残す設計は必ずすること。絶対です。
＿ - バグの出方がテストの進みに対して多い、すぐに直る
経験よりバグが多い、あるいは少ない、中身の質が違うと感じた場合は詳細な検証をしてください。いつもと違う現象には必ず理由があって、原因があります。この原因が問題のないものであればよいですが、致命的なことの予兆である場合がほとんどです。
バグの報告書を見る、設計を見直す、開発者にヒアリングをする、ソースを見る、バグの分析を見るなどを自らします。人にかませてはいけません。自分の経験を生かして心の目で見るのです。
＿
一瞬通常の収束曲線に近いように見えます
ＰＪの規模や性質によってこれらの出方や期間数は違いますが通常が下にある図だとすると
バグが多すぎます。時間がたっていてもいまだにバグが出続けています。修正が追いつきそうで追いついていません
バグの出方が減ってきているが、期間がたっているので、みんな疲れている(バグが出し切れていない)だけかも・・・
統計手法による発見の方法もあります。
バグの種類が決まっていて、それを除くと、バグ数が統計に近似する場合、特定箇所の問題が影響していることが推測され、そこに詳細な調査をすべきことがわかります。これは長くなるので後程
マネージャの仕事としては事前に仕様をきちんと決めてもらう、お客様から必要な費用をもらう、場合によってすべてがだめにならないように期限を延ばしてもらう交渉をお客様とする。
お客様を含めた全員のために、お客様に対して困難な交渉をするのが仕事です。逃げずに立ち向かいましょう。