第3者の視点から開発手法を見る
- 2016/1/30
- ソフトウェア開発
- プロジェクトの振り返り
- コメントを書く
外野からプロジェクトの進め方を見ると、欠点がよくわかります。
私は現在、派遣会社の正社員で、その会社から顧客企業に派遣されてシステム開発を行っています。
その立場で言うと、かなり無理なプロジェクトの進め方を行っている企業が多いです。
一人3役
前のプロジェクトでは、納期が短く、タイトなスケジュールを組まれていました。
ミーティングで、リーダーからは「スケジュールが厳しいですがなんとか頑張って下さい」と言われたので、スケジュールを見たのですが。
3つの画面の開発の着手日と完成日が全く同じという無理難題なスケジュールを組まれていました。
これ、無理だって自分でわからないのかなと、失笑していました。
遅れていますよ?
これは、現在参画しているプロジェクトの話なのですが、「あなたの担当している機能遅れていますよ」と指摘されたのですが、「じゃぁ、この部分の仕様は決まりましたか?」と聞くと、「ここはまだ決まっていません」と言われます。
今週の金曜日に納品なのですが、データベースの仕様も、画面の仕様も決まっておらず。
私が設計しなければならない羽目になりました。
「こちらから、画面を作り、お客さんに提案しましょう」
と言われましたが、それ先月やって提案したら、ボツ食らってお客さんからその場で「こういう画面デザインにしてくれ」と言われて、せっせと仕様書を作ったのが無駄な時間になってしまったのです。
なんで同じ失敗をしようとするのか、理解に苦しみます。
振り返りが必要
大抵の会社の正社員は、プロジェクトごとに同じ失敗を繰り返します。
これは、プロジェクト終了時点で「振り返り」を行っていないからです。
忙しい→プロジェクトがぐちゃぐちゃになった→なんとか終わった
の繰り返しなのです。
プロジェクト終了時点だけでなく、期間を決めて「プロジェクトの振り返り」が必要です。
プロジェクトの良かったこと。
プロジェクトの悪かったこと。
これらを洗い出し、プロジェクト進行の共通規約を作るのです。
ここで作った共通規約どおりにプロジェクトを進め、随時振り返りを行い、規約を改定し続ければ、プロジェクトが火を噴くのを未然に防げるのではないのでしょうか?
コメント
この記事へのトラックバックはありません。
この記事へのコメントはありません。