  |
無理矢理やったあげく品質最悪になったってことは、品質を諦めるっていう選択をしたってことかと。それを認識していたかはともかく
進行中のプロジェクトなので、今のままだとなし崩し的に品質を諦める選択になりますね。
個人的経験では、増員を見越した行動として推奨できるのは、戦略的にタスクを後回しにして後続作業のない単純作業を残しておくこと
ちょっと考えたのだが、私のプロジェクトでそんなタスクがなかった。というか元からそういうタスクは後の方の工程にあって、そんなに後回しにできない。
ひとつひとつの開発自体は小さくて大して難しいタスクはないんだけど、案件が多い。
っていうけどさ。 じゃぁ遅延したとき、どうするのが正解なのよ？ 日程延ばすか、機能を落とすか、品質を諦めるかなんだろうけど、どれもムリっていわれるじゃん。 じゃぁ、増員し...
日程延ばすか、機能を落とすか、品質を諦めるか、が正解だよ。わかってんじゃん 増員が効果を上げるには、いざとなったら人増やしてなんとかできるように、あらかじめ手を打ってお...
日程延ばすか、機能を落とすか、品質を諦めるか、が正解だよ。わかってんじゃん これをYesといってくれる上司やお客様がなかなかいないのです。このままいくと品質リスクになって...
無理矢理やったあげく品質最悪になったってことは、品質を諦めるっていう選択をしたってことかと。それを認識していたかはともかく 増員のために手順書作れ、っていうのは成功例を...
無理矢理やったあげく品質最悪になったってことは、品質を諦めるっていう選択をしたってことかと。それを認識していたかはともかく 進行中のプロジェクトなので、今のままだとな...
設計レベルこそ増員で解決しない問題の典型例では… そういうときは設計できる人が設計に集中できるようにするのがセオリーかと あと、後続作業のない単純作業は元からあるものでは...
いやその法則を正しいとして他に方法が無いって言うなら遅れるしかないだろ。
8
