チームを汎用タスク テンプレートに強制せずに、プロジェクト、作業項目、所有者、依存関係、承認、ビュー、レポートをモデル化します。
ワークフローが標準のボードやスプレッドシートに適合しない配信チーム、代理店、運用グループ、および専門会社。
- 作業モデルプロジェクトが実際にどのように進むかを反映します
- 明確な次のアクションを含む役割固有のビュー
- 会議ではなく記録に基づいた信頼性の高いステータス
階層がポートフォリオ、プロジェクト、フェーズであるかどうかを決定する成果物、タスク、または別のドメイン固有のモデル。すべてをタスクと呼ぶことは避けてください。各レベルには目的、所有者、日付、存在理由が必要です。
準備完了、進行中、ブロック中、レビュー中、承認済み、完了などの意味のある変更を表す状態を使用します。誰が作業を移行できるか、どのような情報が必要か、どの移行が不可能かを定義します。ステータスが多すぎると、レポートにノイズが発生します。
別の項目が完了するまで開始できない作業を表します。ブロッカーに所有者、理由、次のレビュー日を持たせます。説明責任のない赤いラベルは、遅れを飾り立てるだけです。
貢献者には次の仕事が必要です。プロジェクト リーダーには、リスク、未割り当ての項目、今後のマイルストーンが必要です。クライアントは承認と簡素化されたステータスを必要とする場合があります。同じレコードからビューを構築することで、チームが並行トラッカーを維持しないようにします。
現在のステータスだけでなく、作業がいつ開始および終了するかを追跡します。これにより、サイクル タイム、待機時間、スループット、およびコミットメントの欠落がサポートされます。アクティビティ履歴により、プロジェクトがメモリに依存せずに移行した理由も説明されます。
実際のプロジェクトと並行してツールを実行し、ユーザーがメールやスプレッドシートに戻る瞬間をすべて記録します。まず作業モデルと不足しているアクションを修正します。自動化は、手動ワークフローが信頼できるようになってから追加してください。
プロジェクト、作業項目、所有者、状態、日付、コメント、ファイル、依存関係、アクティビティ イベントから始めます。
責任、権限、またはレポートを変更する状態は最小限に抑えてください。多くの場合、最初のワークフローでは 5 ～ 7 で十分です。
通常は使用しません。ステータス、要求された情報、承認に焦点を当てた、よりシンプルなビューを通じて同じレコードを使用できます。
サイクル タイム、待機時間、スループット、ブロックされた経過時間、予定通りのマイルストーン、およびレビュー後に再開された作業は、生のタスク数よりも実用的です。