2015-11-15

http://anond.hatelabo.jp/20151115221039

無理矢理やったあげく品質最悪になったってことは、品質を諦めるっていう選択をしたってことかと。それを認識していたかはともかく

進行中のプロジェクトなので、今のままだとなし崩し的に品質を諦める選択になりますね。

しかもメンバの疲弊もおまけ付き

個人的経験では、増員を見越した行動として推奨できるのは、戦略的タスクを後回しにして後続作業のない単純作業を残しておくこと

ちょっと考えたのだが、私のプロジェクトでそんなタスクがなかった。というか元からそういうタスクは後の方の工程にあって、そんなに後回しにできない。

ひとつひとつの開発自体は小さくて大して難しいタスクはないんだけど、案件が多い。

設計できるレベルタスクボトルネックがあるんだけど、

コーディング/テストするスキルレベルの人員しか増員は見込めないって話で進んでる。

記事への反応 -
  • っていうけどさ。 じゃぁ遅延したとき、どうするのが正解なのよ? 日程延ばすか、機能を落とすか、品質を諦めるかなんだろうけど、どれもムリっていわれるじゃん。 じゃぁ、増員し...

    • 日程延ばすか、機能を落とすか、品質を諦めるか、が正解だよ。わかってんじゃん 増員が効果を上げるには、いざとなったら人増やしてなんとかできるように、あらかじめ手を打ってお...

      • 日程延ばすか、機能を落とすか、品質を諦めるか、が正解だよ。わかってんじゃん これをYesといってくれる上司やお客様がなかなかいないのです。このままいくと品質リスクになって...

        • 無理矢理やったあげく品質最悪になったってことは、品質を諦めるっていう選択をしたってことかと。それを認識していたかはともかく 増員のために手順書作れ、っていうのは成功例を...

          • 無理矢理やったあげく品質最悪になったってことは、品質を諦めるっていう選択をしたってことかと。それを認識していたかはともかく 進行中のプロジェクトなので、今のままだとな...

            • 設計レベルこそ増員で解決しない問題の典型例では… そういうときは設計できる人が設計に集中できるようにするのがセオリーかと あと、後続作業のない単純作業は元からあるものでは...

    • いやその法則を正しいとして他に方法が無いって言うなら遅れるしかないだろ。

記事への反応(ブックマークコメント)

ログイン ユーザー登録
ようこそ ゲスト さん