開発者はいるが、納品全体を引き受ける人がいないという状況のための選択肢です。計画、リスク一覧、顧客との関係を私が引き受け、問題はスプリントの終わりではなく起きた時点でお伝えします。
こんな場合に向いています
- 作れる開発者はいるが、要件を説明できる計画に変える人がいない
- 日本の顧客とベトナムのチームで、本当の差が技術ではなく意思疎通にある
- すでに遅延しており、引き受けて新しい期日を口に出す人が必要
- 毎スプリント同じ問題に当たり、理由を問うのをやめてしまったチーム
こんな場合には向きません
- コードを書く人が必要な場合。私は納品を管理し、実装チケットはもう持ちません
- 状況を転送するだけのマネージャーを求める場合。範囲については押し返すので、それが歓迎されないなら心地よい仕事にはなりません
- 納期と範囲の両方が固定で、どちらも動かせない場合。三か月後ではなく初回でそう申し上げます
- 日本のオフィスに常駐が必要な場合。ハノイを拠点に、定期的な出張で対応します
得られるもの
自社の上層部に説明できる計画
飾りのガントチャートではありません。
- 正直に見積れる大きさまで分解された範囲
- 6週目に効いてくる依存関係を初週に洗い出す
- 緩衝はリスクのある場所に置き、隠さず緩衝と明示する
悪い知らせが早く届く
プロジェクトマネージャーが果たす最も有用な役割です。
- 遅延はレビューの場ではなく、対処できるうちに提起する
- お渡しする報告は、顧客にそのまま見せられる内容だけです
終わった後もあなたと働きたいと思うチーム
一つの期日のためにチームを使い切らない進め方。
- 残業は戦略ではなく、計画が誤っていた合図として扱う
- 決定は実行する人に説明し、反論できる状態にする
進め方
工程 1
やる価値があるか見極める一回の面談
無償、通常1時間以内。
- 納期、範囲、気になっている制約をお話しください
- 力になれるかを率直にお答えし、無理なら代わりに何をするかを申し上げます
工程 2
実態を読む2週間
変える前に、何が事実かを確かめます。
- 現行の計画、バックログ、コード、直近3回のふりかえり
- 管理側とは別に、開発者と個別に話す
- プロジェクトの現在地を文書で評価する
工程 3
修正した計画を文書で
続けるかどうかを判断する地点です。
- 何をいつ出すか、そのために何を落とすか
- まだ計画を壊しうるリスクを順位付けして提示
工程 4
納品を回す
頼れる週次のリズム。
- 計画、レビュー、1on1を固定の周期で
- 週に一度、関係者が読む言語で書面の報告
工程 5
引き継ぎ
私が不要になる状態で終わるべきです。
- 計画、リスク一覧、規約を文書化し、貴社チームが保有する
- 各責任について引き継ぐ担当者を名指しで決める
よくある質問
既存のプロセスに合わせられますか。
多くの場合できます。ウォーターフォール、スクラム、そして日本の顧客案件で実際に多い併用型のいずれも経験しています。ただし納品データが機能していないと示しているのに、機能しているふりをすることはしません。
どれくらいの時間を割いてもらえますか。
案件規模と、私が並行して担当している内容によります。初回でお尋ねください。心地よい数字ではなく実際の数字をお答えします。
引き受けた結果、期日に間に合わないと判断した場合は。
2週目末の評価書で理由と選択肢とともにそう申し上げます。2週間で分かるほうが、3か月後に分かるより格段に安く済みます。
NDAは締結しますか。
します。このサイトのすべての事例で顧客名を伏せているのは、まさにその理由です。
