見積・提案書に書いておくと不幸を減らせる前提条件
はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません（うろ覚えで書いてたり、大人の事情） これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる
3つの決めつけから見る失敗の要件定義
## 今回発表したイベントについて PeerQuest Inc. （ https://peer-quest.jp/ ）様主催の、#開発PM勉強会（ https://twitter.com/search?q=%23%E9%96%8B%E7%99%BAPM%E5%8B%89%E5%BC%B7%E4%BC%9A&src=typed_query ）の第7回目のイベント、「要件定義どうしている？共有LT」で発表させていただきました。 株式会社Speee プロダクトマネージャー 塚本尚 https://peer-quest.connpass.com/event/229463/ ## 発表した内容について 結局行き着いたのは、（あるある話だとは思いますが）**whyとwhatの定義をしっかりす定義すること** でした。 その過程で多くの失敗をしたので、当時私がやってしまった要件定義時の失敗について発表し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
