久々に釣られてみる。通して読んでみての違和感。 ITベンダの元「中の人」として、確かに何度か「詳細な見積根拠」を求められたことがある。お断りしたが。詳細ではない、各工程ごとや各機能ブロックごとといった単位での見積根拠までは提示したことはある。 違和感の理由は契約形態について述べられていないこと。つまり、営利企業であるITベンダは、当然契約形態に合わせて利益を乗せた額で提案をしている。「IT部門の無能と無用」に帰結したい文章なので、契約形態と見積根拠の提示の関係について及ばなかったのだろう。 コンペであるにしても、機能要件・非機能要件を充足し、受注した際の想定利益を考慮して見積額を作成する。その時、受注した際の「想定」利益にはいくつもの考えがある。例えば、初期構築プロジェクトを受注すると自動的にエンハンス工程も受注したことになるような大規模システムの場合、まずは初期構築プロジェクトを受注しな
プロジェクト・マネジメントのアンチパターンを徹底解説 プロジェクト・マネジメントにはセオリーがある。セオリーを知らずに，あるいは軽視して，失敗するプロマネは少なくない。現場でたたき上げたベテランの凄腕PMが，現場でプロマネがやってはいけないことを解説する。 関連サイト： ■メール編 ■やる気編 ■要件定義編 ■会議編 ■報連相編 ■協力会社対応編 ■品格編 ■課題管理編 ■変更管理編 ■コミュニケーション編 ■外注管理編 ■姿勢・資質編 ■計画＆進捗管理編 ■品質編 ■姿勢編 理由無き要求は機能化してはいけない プロジェクト事務局を軽視してはいけない 過去の成功体験にとらわれてはいけない 自己研鑽を怠ってはならない 目的を忘れてはいけない ■プロジェクト完了編 完了条件をあいまいにしてはいけない 完了報告会を省いてはいけない 成功・失敗要因を不明確なままにしてはいけない フィードバックを忘
ソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」。第22回は、シーケンス図を使用したモデリングによってECサイトの登場人物と処理の流れを示し、開発対象を洗い出す工程について説明する。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
