新規の開発手順を作成中です。まだ50手順弱なので100手順にしようかなと。
>> 要件定義 >> 機能要件 >> 顧客要望まとめ >> 業務分析 >> 機能抽出 >> システム概要設計 >> リスク抽出 >> リスク対策 >> 見積 >> 顧客スケジュール >> 期間見積 >> 配員計画 >> 金額見積 >> 交渉 >> 設計工程 >> システム設計 >> ネットワーク設計 >> オブジェクト指向設計 >> データ構造設計 >> ユーザーインターフェース設計 >> 画面確認 >> 実装工程 >> 実装計画 >> タスク抽出 >> 内部設計、詳細設計 >> 実装 >> 単体試験 >> 結合試験 >> 試験工程 >> 試験計画 >> 機能試験 >> 負荷試験 >> ユーザー機能試験 >> 修正 >> 不具合表 >> 導入 >> 新規導入 >> 移行計画 >> 運用マニュアル >> 運用試験 >> 試験運用 >> 運用開始 >> 保守 >> ユーザーサポート >> 初期不良対処 >> 変更要件
これありがたい（´・ω・）ｽ
チェック項目として流れは必須ですものね。
人的ソースも期待ｗ
インデントが消えていたので、直したのですが、実は「チェック項目」というよりも、順序/前後関係を重視したフローだったりします（プロジェクト以前の時に、チェック項目として使えますが）。
なので、今後の作成予定としては、
・フローを100手順で表す。
・前後関係を明記する（遷移図、PERT、マトリクスあたり）
PMBOK みたいにツリーでもいいけど、合流が表せないので無理かなと。
・工程ごとに偏りを減らす（要件定義偏重になったり、実装偏重になったりしない）
な感じで。
そうそう、勿論、自己言及ができる計画でないといけない。これ重要ッ!!!
で、この話は、先週の土曜日の.NETラボの勉強会で１時間ほど突っ走ってみました。
アイデアレベルだったけど、１時間喋りっぱなしでも大丈夫そうです。
# 技術系の話を期待していた方には、えらい迷惑だったろうけど。
今度は、専門用語と根拠を付け加えて、100の手順に手直ししていきます。
典型的なウォーターフォールでSIerらしいですね
この頃は、PMBOK や SWEBOK を勉強していた頃で、じゃあテンプレート的に100項目出してみれば「抜け」が減るんじゃないかと試しに思っていたときでした。
結果的に、チェックする項目が多いとチェックするだけで疲れてしまう、かつ却って抜けが多くなるので、今だとこんな感じ↓
オーケストラに学ぶプロジェクトマネジメント | Moonmile Solutions Blog
http://www.moonmile.net/blog/archives/8594
に、納期が動かない開発でタイムマネジメントをベースに割り振る感じでやってます。