アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
上書きで更新 / Judge Point (スコア:1)
量産開始時はバグfixされていなければなりませんでした。
フラッシュメモリの発達によって、「とりあえず生産開始しちゃえ。出荷前に書き換えればいいし」
という判断がまかり通りやすい状況になってますね。
(最悪、Webでアップデート出せば‥‥という甘さにまで)
逆に、「バグ500件」と聞かされて、あと○日でなんとか減らせると判断するか、
これはまずい、工程を延ばそうと判断するのかが偉いヒトの役割で。
バグのランク付け・点数化や、工程を次へ進めるチェックポイントでその点数にしきい値を設けるなど
組織的にルール化することで判断を誤らないようにしているのが昨今の会社だと思いますが、
部署によっては偉いヒトのヤマカンや根性論でうやむやにされている例もチラホラ...
Re:上書きで更新 / Judge Point (スコア:1)
今回の例だとたとえ達成できたとしても開発リーダーの甘い見積もりのせいでリスクマージンはゼロだったわけで、誰かひとり病気で休むとか、新しいバグが2~3個出てくるとか、飛行機が台風で半日欠航しただけで頓挫するような状況でした。判断もクソもあるかいや、ってな状況。そこを判断するのが偉い人なはずなんだけど、偉い人(経営的判断ができる事業部長などクラス)には正しい進捗報告が上がっていなかったらしいので責められない。
組織において、嘘つきは裏切り者に等しいと思うんだ。