雑種のポメラニアン

フリープログラマーの日記とか人生観とか綴るよ

グループタスク管理をする時に、私が前提としている事について

至高のグループタスク管理から引用>

私が「タスク管理=スケジュール管理」と解釈する事に
強い抵抗を感じるのは、そういう解釈をすると
「スケジュールを守る>タスクをこなす」
という意識になってしまうからです。
あくまでも予定は予定であって
タスクをこなすのとは意味が違うはずなんです。

私のこの考え方の前提は
・スケジュールを立てる段階ですべてのタスクを列挙する事は不可能。
・スケジュールをこなしている段階で仕様が変わる・増える事がある。
 ウェブアプリケーションではこの傾向が明らかに顕著。
・最終的に納品物でお客さんが利益を上げる事の方が
 スケジュールを守るより大事。

納期の遅れと利益は相関関係はありますが
結果的に納品物が利益に繋がらなければ
納期自体に意味がないと考えます。

だから
1.利益の得られるシステムの考案・依頼
2.納品物のリリース(今現在世間一般で言われてる納期)
3.納品物の世間への認知(マーケティング、大きな仕様的・技術的な欠陥がないか早めに対処すること)
4.世間への拡大が見込めるか経営的判断
5.拡大の可能性があるなら1〜4を繰り返す。
  ないなら現状維持かサービス停止・統廃合など。
というのが私の考える商品のライフサイクルです。

世間一般でのシステム開発・納品プロセスは
世間一般の納期(つまり2)しか考えられてなくて
人気の出る案(つまり1)は大前提として達成されているという思い上がりに近い勘違いがされている。
マーケティグ(つまり3)はサーバーを公開すれば自動的に人が集まると誤解されてるか、もしくは著しく軽視されている。
経営的判断(つまり4)を怠って、うまくいかないのは情シスか開発業者に責任を押し付けて、見込みのない継続をしたり、見込みのある将来を潰したりしているように私には見えます。

要するに「安易な、納期絶対論・無駄な高機能・無駄な高品質」に対して反感に近い疑問を感じてます。
これには議論の余地がありますが、納期と、高機能が有限である以上は
納期と高機能と高品質は「トレードオフ」の関係が生じるはずです。

話がとりとめなくなりましたが
私の今までのキャリアからは
納品物によるお客様の効率的な利益の確保を考えないで
「仕様絶対・納期絶対・品質絶対」を主張する事には
意味がないと判断せざるを得ないのです。