タスクの優先順位付けの大まかな流れ
100個のタスクを上から順に優先順位をつけたところで意味がない
優先順位の方法論を確立できると良い
タスクがバーっとある状態で、こういう手順で整理していくと良い、という手順を作る
例えば、
step1: 課題を可視化する
評価軸の整理をする
共通のpropertyを設定し、個々のタスクでそれを設定する
e.g.
タスク名
実装コスト
小中大ぐらいのざっくりしたもので
インパクト(とは)
小中大
緊急度(とは)
小中大
タスクの依存関係
適当なカテゴリ
e.g. UI改善、リファクタ、..
適当にグルーピングしたいなら有用だが、別にイランかも
step2: タスクのマッピング
様々な軸でプロットして見る
e.g.
タスク種別：バグ / 機能改善 / 技術移行 / UI改善
インパクト：大 / 中 / 小（主観でも可）
実装コスト：大 / 中 / 小（見積もり）
依存関係：あり / なし
今すぐできない理由なども
e.g. 〇〇に対する理解が足りない
e.g. そもそも必要なのか謎
検証必要：Yes / No
完了目標：短期 / 中期 / 長期
step3: 短期/中期/長期プランの分離
上記の中から重要なタスクをピックアップする
それ以外は関連タスクとして視界から消す
ノイズになりそうなタスクは思い切って視界から消す
いつやるべきかをざっくり分類する
プランを3つほど考えて、相談
step4: 着手案の具体化
中長期を視野に入れながら、短期を詳細に組み立てる
スケジュール作成の準備
めちゃくちゃ前提の話mrsekut.icon
開発時に使う用語の定義
プロジェクトの成果物や完了の基準を確認
ゴールを決める
何を作るのか、どこまでやるのか、どういう成果物ができれば完了なのか
曖昧な部分があったとしても「何が曖昧なのか」を言語化しておく
タスクごとの前提条件を見る
何を知っていれば始められるか
このタスクに着手するまでに何が終わっている必要があるのか
e.g. クライアントからの原稿がないと制作が始められない
→早めに連絡して用意してもらう
関係のパターン
前の作業が終わらないと，次の作業に着手できない関係
作業を同時に開始できる関係
必ずしも同時に開始しなくてもよい
作業の終了が同時になる関係
必ず同時に終了しなければならない
互いの作業は完全に独立し、並行作業できる関係
作業同士が無関係
作業の順序や作業同士の依存関係定義する
不確実性の大きいタスクを最初にやったほうがいい
スケジュール不安の大きいプロジェクトでは、不確実性でソートして、不確実性の高いものからやっていくと、コントロールしやすい
タスクの担当者を決める
大まかなテストの流れもここで決めることになるのか？
洗い出しが終わってからやるもんだねmrsekut.icon
スケジュールの確認
クライアント、上司に見せて現実的なスケジュールに修正する
実施
後半のスケジュールを常に意識しながらプロジェクトを進める
厳しい、となったらはやめに方向天下んする