見積りに合わせていくように動く
見積った工数に合わせにいく
この視点は実はめっちゃ大事かもしれないmrsekut.icon
転換がある
今まで工数見積ムズすぎやろ、と思っていて、
遅れることの原因を工数見積に追求していたが、
そうではなく、その後の振る舞いも込みで考える必要がある
結局、リリース間近の線引が大事とかの期待値調整と似ている
見積もりが正解なのではなく、見積もりを正解にしていく
見積りやスケジュールというのは単なる締切としての意味合いしかない
「実装していったら間に合わなかった」ではなく、
「要件に対して、間に合うような方針を選択してやっていく」というだけの話である
経営的に達成すべきことは要件の達成であって、
それを達成するための手段・方針は未定義なため、そこに自由度がある
最初に引いたその工数に収まる最大の質の手段で達成すればいい
そう考えると、スケジュールの存在価値は「時間配分」が大きいと言えそう
スケジュールは時間配分のために行う(?)
「遅れそうなら頑張る」といったものではなく、要件に対する時間をかける配分・割合
分母が決まっている中で、どう配分するのが最も成果につながるか
例えば、満たすべき要件がA~Cの3つあるとして、
これらを等間隔に時間配分するか、Aを少し多めに取るか、みたいな判断になる
各機能について要件を満たす最も簡単な解決策を達成するための時間を確保し、
あとは、優先度や、進め方で変える
アジャイルみたいに、段階的に作るのか、
最初からちょっと大きめに時間を取っておくか、
12日間あって、各要件の最小の時間が2日ずつだったときに、
優先度の高いものからサイクル回すなら、
A2→B2→C2の繰り返しでもいいし
Aが優先度高いのであれば、
A8→B2→C2とするとか
先に、デザインとかの成果物の形を決めるフローがおかしい?
デザインというのは表面上の具体であって、ロジック部分については一部保留される
デザイナが作ったFigmaというゴールを目指すことを優先するから、「遅れた」みたいなことが起きる
いやそんなことはないかmrsekut.icon
デザインもロジックも全部一人で考えると想定すればわかりやすい
デザインを考える時点で、方針も考えればいいだけ
じゃあ、工数見積りって何を回答すればいいんだ?
「最小の時間 $ \le 見積時間」というのはそうだとして、
上限はどういう風に決めればよいのか
予算を出すのに工数は必須ではないという視点も大事