ソフトウェア開発の見積もり入門
2022/03/29 06:44
pmint
PMBOKの紹介から始まるような小ざかしい説明ではなかった。シンプルで正しい。ただ、問題は分割するもの。それで部分的には見積り可能になるはず。
2022/03/29 07:55
toruhjp
おおむね同意。誠実だと思う。ただ「バッファ」なる呼称によって説明に苦労することもあるため、「想定外のニーズやトラブルに対応するための品質向上期間を〇〇日確保したいです」と伝える手もあるよ!
2022/03/29 08:23
remonoil
いくら説明しても四捨五入したかのように数字だけになるの
2022/03/29 08:57
hasiduki
知見能力が足りない開発者の訓練課程をバッファと称して見積もりに追加して何が悪い!!!!
2022/03/29 08:58
lorenz_sys
自分も概ね同意だが見積の前提事項を顧客に対し明示しそれについてコンセンサスを得ておくことを追加で提唱しておく。前提が崩れたら見積は成立しなくなることは当然だけどお客さんはそういうことすらご存じない。
2022/03/29 09:16
kagerou_ts
「『見積もりが当たることが前提』として捉えている人」営業・上流の人かな? ウォーターフォールだと見積もった後のスケジュール動かせなくなるから思ってる量の三倍バッファとるといいよ
2022/03/29 09:21
tetsu040e
根拠を明確にして合意を得る、これが一番重要だと思う。
2022/03/29 09:27
ppppchan
「見積もりの精度は経験の量に比例する」これは真面目な人が陥りやすい罠で、実際にはタスクの優先順位に大きく依存する。タスクの構造はスタックではなくてプライオリティキューで考えるべき。
2022/03/29 09:31
daira4000
入門とはいえ経験による山勘としか書かれてないのはどうなんだ
2022/03/29 09:37
moromoro
社内レビューも入ってると良いね id:hasiduki氏の言はもちろん契約形態/社内案件とか前提条件次第だけど、客目線なら知見がある人/訓練終えた人をアサインせずにバッファと称するならその期間は無料にしてねってなるよ
2022/03/29 09:37
htnmiki
ここに受発注両者の信頼関係と発注側の理解度も影響するので両者納得への道は長い……
2022/03/29 09:58
mouki0911
本当にもっとコスト抑えられるだろ圧力をなんとかしてほしい。
2022/03/29 09:58
daishi_n
見積もりの前提条件作るのだってカネかかるし、「正確な見積もり」は設計工程を代替してしまうからアホみたいにコストかかる
2022/03/29 10:00
kootaro
大事な事は見積もりはブレる可能性があることを認識してもらう。特に早い段階の見積もりなんて精度出ない。出来れば▲~〇人月、特に問題なければ□人月って伝え方をしっかりと。でも▲人月で進みがち。
2022/03/29 10:10
saiyu99sp
現実として見積もりとは予言である。開発終盤になると予言の辻褄が合わされる。この時、予言の変更は認められない。マーフィーの法則になりませんかね?
2022/03/29 10:16
kkrsnsn
この、合意が取れていること、がめっちゃ重要
2022/03/29 10:18
circled
早く作ると「ここにxxな機能作れますか?」と聞かれ、追加料金になりますと言うと文句を言わずにお金を払うお客さんしか存在しないなら、適正な見積が存在できる世界線に行けるはず。君は今何回目のループ?
2022/03/29 10:29
juejue
見積もりって難しい 過去に経験がある事ならまだしも未経験の事なんかどうやって見積もればいいんだろうね
2022/03/29 10:31
lets_skeptic
経験豊富であっても、規模が大きくなれば不正確さが増す。期間が長くなれば不正確さが増す。小さい見積ができればいいんだけど、なかなかそうもいかんよね。
2022/03/29 10:44
otihateten3510
見積もりは当たるんだけどね、信用してもらえないんだよね。ベンチャーは魔窟ぞ。
2022/03/29 10:44
chago
あとからよまねば…
2022/03/29 11:06
dustytrombone
自分のとしての見積もりのコツはあまり深く考えずにさっさと数字を出してレビューして言われたとおりに修正していくこと。当てにならないし後でだれも顧みないものに時間をかける気にならない
2022/03/29 11:12
kamocyc
失敗しながら慣れてくしかないんだよな
2022/03/29 11:17
yuu-yuiken
ざっくりで良いからって出した見積もりが正式になっててかつ通るから嫌なんだよな
2022/03/29 11:38
hase0510
バッファじゃなくて、すべてがスムーズに行った場合の最短と、不幸が積み重なりまくった場合の最長を見積もったほうがいいよね。社外向けには伝え方に工夫がいるけど。
2022/03/29 11:40
yaboot
「何をどのくらい保証しなければならないか?」を考えるといいです。
2022/03/29 11:48
n314
バッファは技術系以外の人には説明しないな。もし何のトラブルもなくスムーズに完了した場合に値引きするなら説明してもいいが。あと期間が短いときは特急料金で高くするのか、単価計算で安くするのか、とも絡む。
2022/03/29 11:51
nkzsdy
苦手
2022/03/29 12:01
gayou
ざっくりとした見積は数字だけが一人歩きするので、根拠説明のために、成果物と予想機能一覧を書いて工数を1つ1つ見積もる。内訳が分かるので後の振り返りに役立つ。相手側は合計しか見ないけど。
2022/03/29 12:19
kazokmr
個人としては同意。だけど発注側言う見積りは金額(予算) を指していて、そこのミスマッチを調整することが嫌だった。大昔の話です。