＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
開発の進捗度について
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2007-03-01 22:04
立て続けにお世話になります。
開発の進捗度についてアドバイスをください。 毎日、終礼にて開発者から作業の進捗度の報告をさせているのですが 根拠に乏しく、正確性に欠けておりフォローができません。 どのように報告させればよいでしょうか？ | ||||
|
投稿日時: 2007-03-01 22:33
管理するタスクの粒度が大きすぎってことはありませんか？
| ||||
|
投稿日時: 2007-03-01 22:37
作業予定も立っていない状況で、例えば「進捗率○％」などという 進捗報告をしてはいないですよね？ #「進捗をどのように把握するか？」は #「予定はどのように立てられていたか？」という問題に帰結すると思っています。 | ||||
|
投稿日時: 2007-03-01 23:29
確かに。 計画をころころ変える癖に、計画を含めた線表を求める顧客がいてツライんですよ 
「状況がよく分からない。ちゃんと進捗を報告してください。」っていうけども、 おたくらが計画変えてばかりだから決めれないんだって。 アジャイル開発ではどうやって進捗報告するべきなんだろう…。 残量、見積もりでこれぐらい、完了したのがこのぐらい、 見積もりと実績の差分がこのぐらい、この見積もり精度からすると 残りこのぐらいの日数が見込まれる…。 という数字しか出せないのですが、納得してくれないのですよね。 | ||||
|
投稿日時: 2007-03-01 23:36
やさしいソフトウェアスケジュール(英語)とかどうでしょう。
日本語で読みたければジョエル・オン・ソフトウェア[amazon.co.jp]の売り上げに貢献してください。 個人的には終礼での進捗報告は管理しにくいですね。 自分は、担当者が一日のキリのいい時間(17:00,19:00?それとも23:00  )に
席に行って実際の成果物を見せてもらいながら、くだけた雰囲気で聞くように心がけています。 進捗管理にはどのぐらいのコードを書いたか、何件のテストを消化したかといった定量的な評価と 作業の難易度がどのぐらいだったかの定性的な評価の双方が必要だと考えています。 定性的に評価するには開発者の言うことを理解できる程度の技術力がないと 過小/過大評価をしてしまってお互いに不幸になりますけどね。 | ||||
|
投稿日時: 2007-03-02 09:57
開発者の進捗率は捏造ではないかと思ったりしています。 開発者の言うことを理解しようにも 難易度が高すぎて管理者には負担が大きいです。 むしろ、管理者側から開発未経験のひとにでも理解できるように 説明するスキルをつけるために 外部研修などを取り入れています。 効果として論理的に進捗を報告、理解できるようになるのではと思っています。 | ||||
|
投稿日時: 2007-03-02 10:18
管理手法によりますが、 未着手 ０％ 着手済 ５０％ 完了 １００％ で評価するやり方があります。 主観を極力排除するためには強引なやり方も必要だと思います。 管理者が知りたいのは、全体の感触で、 あまりに細かい数字じゃないんじゃないですか？ WBS上の項目は細かくした方がいいですが、 例えば、WBS上のとある明細項目で、 ５０％と５１％なんてぶっちゃけどうだっていいんじゃないかと思います。 ５０％と６０％の違いもどうだっていいと思います。 欲しいのはWBS上の大分類項目の進捗率なんじゃないでしょうか？ なので、全員がわかりやすい評価基準を定めようとするのであれば、 先に書いたとおりになります。 | ||||
|
投稿日時: 2007-03-02 10:23
捏造しているかもしれませんが、 プログラミングは 残りの１０％に９０％に時間を使う という法則？ があります。 定型的なプログラミングならよいのですが、 そうでない場合は これにハマル場合もあります。 | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.