タグ別アーカイブ: WBS

解:バグを隠しているのではないか

虚偽報告をされてしまったら「運が悪かった!」のでしょうか?

違います。これも発見できます。
昔の話で今ほど業界は経験を積んでいなかった時代であり、報告内容などが性善説に立ったものだったのです。まず、進捗が可もなく不可もなく理想通りに進んでいる段階で怪しいです。人が動いて作っているものですからそんな馬鹿なはずがないのです。必ず苦労したり失敗したり、残業がかさんだり進んだり遅れたりするのです。

  • 課題管理
  • 品質管理
  • モジュール単位進捗管理
  • WBSに基づく進捗管理
  • 工程完了審査
  • 抜き取りの現物確認
  • 中間検査

今であればこれらのことをすることでこのような事態は避けられます。
このような詳細な報告を受けている場合で虚偽報告をしようとした場合、かなり大変です、必ずぼろが出ます。

ぼろを発見する
課題がないということはありません。課題があるということはそれについて人が動いているはずでそのモジュールなり機能のところで、進捗が動くはずです。当然品質にも影響があるはずでそれらの関連性が合理的でないのであれば虚偽報告である可能性があります。早急に現物確認をします。
現物確認は疑っているからするのではなく、PMの責任として、成果物を自分のものとして内容等を把握するために絶対に必要ですから、怪しくなくても時々行うべきです。
進捗報告の粒度もある程度負担にならない程度に詳細にもらうべきです。自動的に集計が取れるものでも良いかもしれません。
テスト要員と開発要員を分けることも肝要です。

五感を駆使して、異常を発見して早めに手を打てるようにしましょう。

(ヘ)タスク積み上げ(WBS積み上げ)

作業を細かく分解してそれぞれ単純に何をするかイメージがわくレベルにして、そのするのに必要な工数を積算していきます。
ここで重要なのは「実際に何をするかイメージできるレベルまで作業を分解する」ということです。
この方法は開発外作業(研修教育など)・構築作業などの見積もりで使います。根気のいる作業ですが地道に行っていきます。

WBSを作るという作業は例の変な表を作ることではないことを知っておいてください。「作業を分割してイメージがわくレベルにすること」です。
細かく分解すればするほど工数が大きくなる場合があります。これは作業の分割単位と見積もり単位があっていない場合におきます。

単位が「月」であった場合最少は1M(月)になってしまいます。1W(週間)でできるタスクに分解した場合に最少の1を入れてしまうと3W(週間)分120H(時間)のずれが生じることになります。
作業単位が「D(日)」単位で終わるようなものであればH(時間)にすべきです。一つ下の単位を設定して見積もってもらいます。
単位をM(月)のままで0.1とかやめてください。0.1M(月)は2D(日)です(160時間前提)当該作業が2日間=16時間かかるのかの考慮をするのが嫌になり、妥協することがあるからです。
見積もり精度、分解粒度に合わせて単位を適切に設定してください。
見積もり妥当性を見る場合は、単位に応じた見積もり精度を前提にレビューすることになります。(つまり細かくすればよいものではないということ、余計な突っ込みを受けます。)
部分見積もりの妥当性が無ければそれ以降も見積もり検証をする意味がないと判断され、再見積もりになりますから注意が必要です。