FrontPage

基本

管理とは何か → 制御すること → 制御出来ない物は管理出来ないので、対象にしない
(ちなみに manage の語源はイタリア語の「手で扱う,馬をならす」の意だそう)

プロジェクトに関して制御出来る物は

  • 予算
  • 期間
  • 品質(最優先するべき)

例)
うまければ、多少高く、時間がかかってもゆるせるが、いくら早くて安くてもまずいと許せないし、良い物も悪い物も品質に関しては記憶に長く残る

報告事項は制御に使う情報のみで加工が必要ない状態で上がってくるようにする。なぜならば、報告自体に誤差が含まれているので、加工すると誤差が拡大してしまうため。
また、報告は「信じてはいけない」。参考程度。実際のプロダクトをプロジェクト責任者(以下、自分)が確かめるか、誰かに確かめさせる(でも、最終的には自分で確かめる)。
ということは、一度に作ろうとするのは確かめられる範囲にする必要がある。計画も自分の手の内に収まるように、自分で立てる。

かつ、繰り返し素早く確かめられるような作り方をする。

確かめるのは「プロダクト」。(例えば開発者が)自分の作業が終わっているといっても、プロダクトとしてちゃんと動いてるのを確認するまでは信じてはいけない。というか信じてはいけない。

コミットメントは「神に誓う」「天地神明に誓う」という意味。イメージするのであれば、プロジェクトで発生した億単位の損害を個人で背負わなければならないという約束が全員で出来ない計画であれば、その計画はリスク高し。

きな臭いプロジェクトマネジメント

悪い例

  1. 下から上がってきた見積もりデータを取得
  2. そのデータを基に計画をたてる
  3. 「現場がそういっているから出来るはずです」
  4. 計画を全うするまでリリース出来ない

PM が制御出来ない。

良い例

  1. 仕様から計画を立てる
  2. 過去の実績や下から上がってくるデータを根拠とする
  3. 「(一旦)この計画で終わらせます」
  4. 計画途中でもリリース出来る

PM が制御出来る。

迷った時の言葉

「売れるかもしれないプロダクトを作り続ける」
のか
「売れないかもしれないプロダクトをリリースするのか」

バージョン

Ver.A

  • どんなゲームなのかを把握できる
  • 素材は仮
  • バグあり

Ver.B

  • 全仕様が入っている
  • 素材は仮
  • バグあり

Ver.C

  • 全素材が入っている(差し替えは可能)
  • バグあり

Release

  • 公開可能
  • 全素材が入っている(差し替えは不可)
  • バグなし

優先度の基準

「高」

  • ゲームが進められない致命的な状態
  • アプリが固まる
  • アプリが落ちる
  • 課金周りの間違い(価格が間違っている、課金の過不足がある)

「中」

  • ゲームは進むが仕様的に違う
  • マスターの間違い
  • 画像やモデルの間違い
  • 文言の間違い

「低」

  • 対処しなくてもアプリ的には問題ない改善項目

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2013-06-03 (月) 14:20:23 (2149d)