2009年01月13日

デスマーチ可能性診断

システム開発プロジェクトデスマーチ可能性診断ってのがあったので鬱に罹ったプロジェクトを判定しました。

結果は
あなたの診断結果は22点です。

もうどうしようも無いところまで来ています。人・モノ・カネのすべてが不足している可能性が高いです。
いまの時点で顧客、上層部と相談し手を打たないと納期遅延、低品質、赤字化は必須です。


やはりデスマる運命だったのでしょう!中小ITの開発ですから期待は出来ないとはいえ22点って赤点ですよね。
あなたがあてはまると選択したもの。

・正しい仕様を知っている人がごく一部の人だけ
顧客との接点を増やし、またスタンドアップミーティングを繰り返して情報共有を促進し認識相違を減らしましょう。

・火がついても仕様を確定していない
仕様が確定していないにに予算と納期が決まっているケースは典型的なデスマーチ。火が付いたならゴールへ向かう道筋を作ること。

・顧客側も縦割りで取りまとめ担当者不在。矛盾した要求が複数の担当者から出てくる。
議事録を取った上で押印を得ましょう。また顧客にはっきり意思決定者を立てるよう依頼しましょう。

・開発側がお客さまの業務を理解していない
業界特性がある場合はなるべく事前に理解する必要があります。

・客のいいなり
お客様の言いなりになることは最終的にかえってお客様の不幸になる場合が多々あります。専門家としての意見を主張する必要がある場合があると認識しましょう。

・開発も利用者の事に対して無頓着
最終的に使われてこそのシステムであることを認識すべきです。作ったものにプライドを持てるものを作りましょう。

・相手からわからないと言われるとそこで終了してしまう。
知っている人を紹介してもらうように動いてください。特に複数の部署が関連するような案件では必須です。

・案件スタート時点で既に納期が決まっている(のに仕様が決まっていない)
即時に仕様をつめるか、イテレーションにして、動作するものを見せながら仕様を詰めましょう。

・上層部の意志決定が遅い
どうしようも無いですが、意思決定が遅れたことによって発生しうる会社への損失について明示して判断を仰ぎましょう。

・人使いがへた
どのような形にするべきかチームで話し合って上層部にかけあいましょう。それで駄目ならゲリラ的にやってしまいましょう。

・人の投入が遅すぎる 欲しい時に人を入れてくれない
どうしようも無いですが、投入が遅れたことによって発生しうる会社への損失について明示して判断を仰ぎましょう。

・会議が長くて中身がない
スタンドアップミーティングの導入や、事前のアジェンダ配布など会議のやり方を工夫しましょう

・過去に契約等で揉めたことがある
そんな客と付き合っちゃいけません。または成果を保証する契約をせず準委任契約をするなど逃げ道を用意しましょう

・顧客もどんなものが出来るか正確に把握していない
Scrumやプロトタイピングなどを使って初期の段階から動作するソフトウェアを見せましょう

・客の中でも責任者がよくわからない。客が本気で案件に携わらない
・納期とコストだけしか気にしない
・決定権を持つ人がシステムを知らない
・人張り付けでも無いのに、先に費用だけ決まった契約をしている
・契約時点で成果物の中身が明確になっていない
・営業が開発業務を知らない
 あなたも営業活動について行きましょう。またダメなものはダメといいましょう。

・コスト意識がない
プロジェクトの締め切りが遅れても、赤字になっても、開発チームにあまり影響が無いので反省しない
posted by 竜之介 at 14:11| 千葉 晴れ| Comment(0) | TrackBack(0) | SE系 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

この記事へのトラックバックURL
http://blog.seesaa.jp/tb/112548269

この記事へのトラックバック