人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

プロジェクトマネジメントについて

ソフトウェアをチームで作っているのですが、
ソフトウェアだからといって、仕様をぎりぎりまで変更しようとするケースがあります。
問題は、その仕様変更が下流工程の作業時間を一切無視したケースがあり、プロジェクトが
混乱していきます。

仕様凍結という言葉がハードの世界にはあるようなのですが、ソフトウェアでは、
それほど浸透していないように思います。
(私の周りだけかもしれません。)

仕様凍結の重要性をわかってもらうようにするにはどのようにしたらよいでしょうか?

「その思いついたアイディアは、次のリリースで取り込もうよ。今回のリリースは、仕様凍結したんだから」が通じるチームになりたいのです。

●質問者: know94space
●カテゴリ:ビジネス・経営 コンピュータ
✍キーワード:アイディア ソフトウェア ハード プロジェクト マネジメント
○ 状態 :終了
└ 回答数 : 4/4件

▽最新の回答へ

1 ● F57PB
●18ポイント

http://www.objectclub.jp/community/XP-jp/

- XP_jp_TOP

まさにXP(エクストリーム・プログラミング)の計画ゲームがそれにあたると思います。


つまり、システムに盛り込む機能(仕様変更含む)を、いつ取り込むかをユーザと一緒に考えるわけですね。


で、ユーザにわかってもらうには、

・今取り込むことによるメリット・デメリット

・次回リリースに取り込むことによるメリット・デメリット

を説明するしかないと思います。


おそらく、今取り込むことによるデメリットが大きいと思いますが、

それでもなお、ユーザが「やれ」と言うならやらざるを得ないでしょうね。。。


ちなみに、仕様凍結はよく聞く単語です。

ただ、最近は上述のXPに代表される開発手法によって、(早期段階で)仕様凍結しないことが良いとされています。(私もそう思っています)


物を作る以上、仕様凍結は必ず必要ですが、問題は凍結するタイミングだろうと思います。


2 ● karla
●18ポイント

http://itpro.nikkeibp.co.jp/as/pm/feature/index.html

IT Pro Special:プロジェクト管理特集

ぎりぎりまでの仕様変更をする事でのデメリットを数値で出してみてはいかがでしょうか?

戻り作業や仕様再確認などで無駄な時間が出ていると思います。

それらはコストとして跳ね返り、現場レベルでOKでも経営者、マネージャーから見れば問題視するでしょう。

具体的な数字などで見せられると結構納得してくれたりします。


また、know94spaceさんが発言力のあるポジションなら、「それは次リリースで」と強い姿勢を取ってはいかがでしょうか?

◎質問者からの返答

仕様を変えたがる人は、

仕様凍結をしないことで

「デッドラインギリギリまで極限の品質を

得られる」というように考えているように

思えます。

自分のやっていることが正しいと感じている

勘違いを崩すことができません。


3 ● andi
●17ポイント

http://a/

お客様にはスケジュールとコストの確認はされていますか?


お客様(特に現場担当者など契約に直接関わらない方)は予算やスケジュールなどを意識せず、自分の望む仕様を実現して欲しいと要求を出すのは当然です。


しかし開発側にも当然、守らなければならないスケジュール、予算がありますので、どの程度の仕様変更をした場合に、スケジュールと見積りにどの程度の影響があるのかをきちんと説明して、お客様(に判断して貰う必要があります。


出来れば契約(見積り)時点で事細かに見積り内容を説明した資料があればベストですが、一般的にはある程度曖昧な表現になっていると思いますので、その点でもめる可能性はありますが、代替案(そちらを実現する代わりにこちらの機能は遅らせたいとか)を出すなりしてお客様と調整してみては如何でしょうか。

◎質問者からの返答

今回の状況では、受託開発ではなくパッケージソフトのようなものを作っています。

お客様は存在しません。何でも盛り込もうとしてしまうのです。

仕様凍結という言葉は、結局ウォーターフォール型の考えなのはわかるのですが、

仕様変更による下流工程の作業をまったく考えない場合に困るのです。

質問は、仕様凍結という言葉が根付いていない環境で、どのようにその言葉を認識させるか?

ということになっております。


4 ● Lucrezia
●17ポイント

http://www.google.com/

Google

お初に御目文字いたします。Lucreziaと申します。

お気持ちはわかりますし基本的には「強権を発動してでも」ってのをあたくしもやったりするのですが。

あえてここで逆のお話をさせていただいてもよろしくってかしら?


コーディングをする際に。或いはその手前にある設計の際に。「仕様変更に耐えうる設計やコーディング」をなさっていてかしら?

もっと平たく書くのであれば。

正しく設計されたオブジェクト指向プログラミングであれば、結構な仕様変更にまでは耐えられると思いますわ?


もちろん「オブジェクト指向で設計してなお”根本的に無理な”」変更っていうのもあると思いますの。

でも、ここであえて「逆境を自らを鍛えるために」っていう風な、ちょっと古風でたくましい殿方を気取ってみるっていう視点がほんの少しあってもよろしいんじゃなくってかしら?


状況は変わらなくても、もしかしたら少し精神的に余裕が出るかもしれなくってよ?

◎質問者からの返答

仕様変更ウェルカムです。

ただ、作業時間を逆算して仕様凍結をしないといけないのに、

見かけ上の品質があがるからという理由で

逆算の計算に

・徹夜をする。

・休日にやる。

といった間違ったやり方を前提に

逆算され始めるのが困るのです。

関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ