タグ

開発と見積に関するsakenのブックマーク (2)

  • 【書評】『なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術』(細川義洋・著) - やまもといちろうBLOG(ブログ)

    書評】『なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術』(細川義洋・著) 読んでいて、実用書なのに涙が止まらないに巡り会えたので謹んでお奨めさせていただきます。 その名も、『なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術』。何がヤバイって、いちいち掲載されている項目がヤバイ。いきなり「何度も要件を追加してくるユーザ」ですよ。まるで弊社の某顧客ではないですか。 大項目からして「設計」から「プログラミング」、「テスト」とか進む先々にびっしりと地雷が敷き詰められているんだろうなあと悪い汗をかかずにはいられない世界が広がり、最後にはお決まりの「契約」。いやー、読んでいてぞくぞくしますね。特に「仮発注書だけで作業に着手してしまったら?」とか、なんか見透かされているようですよ。まあ、業界的には往々にして起きがちなことを一般論として書い

    【書評】『なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術』(細川義洋・著) - やまもといちろうBLOG(ブログ)
  • 見積もりと設計の間の高い高い壁 - novtan別館

    この元増田は他の業界のものも含めて設計をお願いしたことって多分無いと思うんだよ。 家の場合だったら、普通は設計図と各パーツの詳細見積りで初めて契約だろうが。 見積りの根拠出してくれっていったら、金くれって言われたよ その設計図は増田が事細かに出した要望を元に一から作ったものなの?って話。 つまり、出来合いのものを適当に組み合わせたものには設計料は掛からないし、そうじゃないものには設計料が掛かるってだけの話ですね。 当然だけど、システムの設計もただではない。大まかな流れを示すと以下な感じ。ちょっと適当。 ・発注元に(ちゃんとした)システム部がある場合 要求仕様を作成し、それに基づいた提案をシステム会社に依頼する。この時点で要件がある程度はっきりしている場合、概要設計を元にした詳細見積もりが可能。出来合いのものを流用できるような要件であれば精度は高く、そうでなければ概算部分が生じる(要件定義フ

    見積もりと設計の間の高い高い壁 - novtan別館
  • 1