失敗プロジェクトが教えてくれるクラウド時代のヒント

この半年ちょっと、私は失敗プロジェクトに2つ関わった。いや、まだ関わっている。
2つのプロジェクトの見積り規模は、55ksteps。実際に開発した規模は、90ksteps。
当然、プロジェクトは赤字。見積り、契約の甘さがここまでの悲劇を招いた。

こんなヘボプロジェクトでも、成果はある。いや、こんなプロジェクトだからこそ成果がある。
一つは、途中から必要最低限のことしかやらなかったことだ。いや、できなかったことだ。
これによって、本当に必要なことが分かった。
開発中、誰も分からないような細々とした設計書を書くのは、アホらしいとおもった。
設計書を書かないと、コーディングする人が分からないという。
逆に言えば、コーディングする人は、プログラムのロジックの責任を設計者になすりつけている。
何も考えないでできる単純作業しかできないコーダーは要らない。
納期の長い10人を超えるプロジェクトなら、設計書をきっちり書いてレビューすることが必要だが、納期が半年未満のプロジェクトならお客さまの声を直接聞いて、ソースに反映したほうが、開発側もお客さまも楽できる。

もちろんそのためには、ビジネスのゴールとスコープを双方で合意していることが重要だ。
また、アーキテクチャ設計書を策定していることも重要だである。

もう一つは、大きな失敗をしたお陰で、従来の開発の考え方を上層部が変えてもよいのではないかと言ってくれたことだ。
組織が大きな失敗をすると、改善案が通りやすい。
個人的には、チャンスだと思う。

ということで、今日は改善策をまとめるための仕事をしにいきます。
少しでも組織が変わるきっかけになればいいなぁ。