前提として、プロジェクトのスコープやゴールは一応定まってるものとする。揺れてたら揺れてるのを押さえるのが先。その辺は前捌き編(発表未定)にて。
1)プロジェクトの重要目的、ゴールを絞って押さえる。なんとなく作業してはいかんよいかんよ。ポイントは絞って要点化することね。
2)形式手続きは一旦全部忘れて要点化したゴールへの最短ルートを見通す。なるべくショートカットルートを描いてみる。いろいろな意味で余力を作りだすのが目的。項目を全部書き出さないのが混乱しないポイント。シンプルにシンプルに。
3)その他必要な作業やタスクを並べて積み上げる。優先順位は当然のごとく必須。
4)ついでに、「これも出来たらいいよね~」ということを積み上げておく。
5)2をざくざく進めて、プロジェクトの主要目的を押さえてしまう。
6)5)で心の平穏を得た後、3~4を積み上げてアップサイドを取っていく。
ってな感じ。特別なことじゃなくて基本だけれども、1~2ってのは結構忘れさられる。特に始まっちゃったあととか。煮詰まってくると何がなんだか分からなくなるものなので。 この進め方がどうやっても取れない、積み上げ重視の場合もありますけどね。でも概ね何がしか構図とか構造とかはあるものなので(だってプロジェクトだもん)、そこを突くと。
落ちはもちろん、概要編の続きが待てど暮らせど来ないことである。
そして書いてみて思うですが、秘訣とかそんなものは欠片も無いですね。ざっくりと丁寧の切り分け感覚と予測力くらいかな。でもそれも文字通りのもの。
前提として、プロジェクトのスコープやゴールは一応定まってるものとする。揺れてたら揺れてるのを押さえるのが先。その辺は前捌き編(発表未定)にて。...
これはいい分析だ。IT系における開発作業は究極の家内制手工業的非定型業務な気がする訳で、これを如何に定型化もしくはルール化するかがマネージメントを行う上でのポイントとなってくると思う。...
PMBOKって、プロセス定義もあるんですが、静的でストラクチャラルな体系化なんですよね。「こういうことも考えた方がいいよ」みたいな受け取り方でいいんだと思います。で、いちおう非定型プロジェクトにも応用できるんですけど、最低でもゴールは決まって...
これ、ノウハウ記述化しづらいんですよね~。筆者の整理力と頭脳力が足りないのもあるでしょうけど。でもなんていうか、いろいろと書けば書くほど本質から外れる。それこそ、コーディング規約のごとく。...