締め切りに対する現実的な期待を設定する
私は小さなチームの技術リーダーです。私の皿の主要なタスクの1つは、クライアントとの通信です。私が特に難しいと思うことの1つは、納期に対処することです。納期はクライアントによって義務付けられており、私は頻繁に相談されないためです。
通常、相互作用は次のパターンに従います。クライアントは、追加したい機能である機能Xを考え出します。機能Xは、約6営業日先の次週のアプリリリースで見栄えがします。この時点で、機能リクエストは承認を受ける必要があり、対処する必要のある他の依存関係が頻繁にあります。最終的に、N日後、機能のリクエストが私のチームに伝わります。 （開発者以外のマネージャーによって設定された）元の期限が達成できたとしても、それはもはや不可能です。私のチームは非難されています、 落胆を感じ、全体的に敗北の雰囲気があります、私は落胆と敗北を感じています。
明らかに全体のプロセスが壊れています。残念ながら、私はここでは権力の立場にないので、私にできることはあまりありません。私の現在のアプローチは、クライアントに開始日と締め切り、フィーチャーの範囲などについて穏やかに思い出させることです。これは私が言い訳をしているように感じます。
似たような状況にありますか？何がうまくいかなかったのですか？
あなたは本当にこれについて上司と話し、いくつかの基本ルールを設定する必要があります：
- あなたがそれにコミットしない限り、締め切りは締め切りではありません。
- あなたがそれを与えない限り、見積もりは見積もりではありません、そしてそれは難しい見積もりではなく「見積もり」です。
ロバート・マーティンのクリーンコーダー は、このことを上司に伝える方法について本当に良い章を持っています。営業チームが不可能な約束をしているのはあなたの責任ではありません。
新しい機能を入手したら、それを見積もり、PERTを使用して、確率分布を得ます。 「それは4日で完了するはずですが、8日もかかるかもしれません。」あなたの立場を主張をする。見積もりをセールスマンと決して交渉しないでください、あなたは不可能なことを約束することになります。
これを数回繰り返した後、セールスマンはうまくいけば馬鹿に見えることにうんざりし、行動を調整して、あなたが終わるという約束ではなく、「私は開発チームに確認し、いつそれができるかを見ます」と調整します。速報。
似たような状況にありますか？何がうまくいかなかったのですか？
主に機能するのは、真実を権力に語ることです。
事実を収集します。事実を提示する。自分のペースで学習する（または学習しない）ことを顧客に任せます。
私のチームは非難され、落胆し、全体的に敗北の雰囲気があります。
なぜあなたのチームは非難を認識していますか？顧客があなたを迂回してチームと直接話している場合、あなたは非効率的になり、その理由を理解する必要があります。
あなたのチームは「非難」または非難の無知であるべきです。彼らは単にソフトウェアを構築し、何をしているのか、いつそれをしているのかを顧客に伝える必要があります。
お客様は---最終的に---プロセスを理解するために成長する必要があります。悪い習慣を打破するには、多くの繰り返しが必要です。大いに。
私はこの正確な状況にありました、そしてそれは心地よくありませんでした。しかし、私が行ったアプローチの1つは、現在開発中の作業の記録を細心の注意を払って記録することでした。タスクが発生すると、クライアント、管理者、またはプロジェクトマネージャーに、他の作業が優先されて優先順位が下がるので、他の作業が失敗することを思い出させます（場合によっては、2番目に推測され、締め切りが長くなるようにプッシュし続けます）。
それ以外の場合は、クライアントを処理し、これらの期限に同意しているプロジェクトマネージャー/カスタマーリエゾン/管理/セールスマンである石の壁に、そのノミをたたき続けてみる必要があると思います。私は彼らが何かがするのに5日かかることに同意した場合、彼らは明らかに5日間の開発について話しているという事実をよく叩きました、それはあなたがそれを手に入れてから5日かかることを意味します（彼らが一緒に電話を切って費やしたときではありません）次の2日間は、派手なWordドキュメントを作成しています）。
ただし、あなたが開発リーダーであるため、このような決定は、そもそもあなたと相談しなければ関係ありません。
また、できる限りこれからチームを保護する必要があります。それは難しいですが、クライアント/管理の政治からできるだけ遠ざける必要があります。そうでない場合は、より多くのヘッドハンマリングが必要です。
基本的に、私はそれを楽しんでいませんでした、そして、私がどのように酷使しても、プロセスは完璧になりませんでした。しかし、なんとか改善することに成功しました。
おそらくあなたにできる唯一のことは顧客と話すことです。見たときに何が起こるか、すべてのリスクなどを説明してください。私も似たような状況で、本当に怒っていました。今でも、すべての技術的な見積もりを担当していると、よく耳にします。月曜日までに完了させたいと思っています。私はただ言う-あなたはそれを取得しないでしょう、月曜日までにあなたが正確に何が欲しいのかを議論しましょう、そしてしばしばすべての重要な機能は非常に簡単に実装でき、月曜日は絶対に問題ないようです。他のすべての機能は、その後のリリースで予定されています。
問題は、顧客が機能のビジネス価値をほとんど知っているが、その複雑さを理解していないことです。話し合って明確にしてください。常に。
開始日が機能をリクエストした日付よりも遅いことをクライアントに思い出させるのは良いスタートです。また、クライアントと最初に話し合った人と話し合って機能の詳細を入手し、クライアントにその時点でより良い期限を伝えることができるようにする必要もあります。あなたはすでにクライアントと連絡を取り合っているので、「それで、この期限に同意したのはY部の誰だったのですか？」
彼らがあなたの話を許さないか、彼らが静かにして同意した期限を守るようにあなたに言った場合、あなたは彼らにそれがより良く見えるだろうと思い出させることができます会社全体のためにもしあなたのチームがon-time、そしてそれを達成する方法は、締め切り時にyour入力を取得することです。
情報フローを修正します。
- クライアントと通信することになっている場合は、すべてのプロジェクト関係者（クライアントを含む）に、alwaysと直接やり取りするように強制します。
悲しいことに、権力は他の人から与えられるのではなく、ほとんどが自分で受け取られます。
私の皿の主要なタスクの1つは、クライアントとの通信です。私が特に難しいと思うことの1つは、納期に対処することです。納期はクライアントによって義務付けられており、私は頻繁に相談されないためです。
クライアントとの通信を担当することになっている場合、組織内の担当者とクライアント側の担当者の間でこの情報を伝達できるように、スケジュール（および予算）について相談しないのはなぜですか？この問題を修正することは、あなた、あなたのチーム、そしてあなたのプロジェクトにとって大きな利益になると思います。
クライアントは、追加したい機能である機能Xを考え出します。機能Xは、約6営業日先の次週のアプリリリースで見栄えがします。この時点で、機能リクエストは承認を受ける必要があり、対処する必要のある他の依存関係が頻繁にあります。最終的に、N日後、機能のリクエストが私のチームに伝わります。 （開発者以外のマネージャーによって設定された）元の期限が達成できたとしても、それはもはや不可能です。
控えめに言っても、このスケジューリングシステムは奇妙に見えます。
私の経験では、クライアントは特定のリリースにサインオンします。彼らは、必要な機能と変更のリストを、必要なときに送信し、ソフトウェアを構築するチームと交渉する場合があります。または、開発チームに機能の優先順位付きリストを提供し、開発チームがさまざまな機能セットをいつ出荷できるかについての見積もりを提供します。他の変種もあります。
しかし、私が許可されていないことの1つは、顧客がゲームの後半、特にリリースから1週間後にリリースを変更できることです。デザイナー、開発者、テスターにそのようなプレッシャーをかけるのは適切ではないようです。反復的な開発を行っている場合、それが優先度の高い機能である場合は、バックログの形式に追加して、できるだけ早くそれを実行してください。優先度の高い機能ではない場合、このリリースでは間違いなく必要なく、次のリリースまで待つことができます。
機能のフリーズ、コードのフリーズ、および配信に関して、設計、開発、テスト、および配信のチームと顧客に対応するいくつかの基本ルールを設定することをお勧めします。これらを書面で記入し、全員からコミットメントを得て、それに固執します。一度びくびくすると、もっと曲がると予想され、プロセスの制御を失うことになります。
残念ながら、私はここでは権力の立場にないので、私にできることはあまりありません。
あなたは一人ではないかもしれません。しかし、あなたのデザイナーや開発者、そして/またはテスターは、スケジュールを満たすために多くのプレッシャーを受けているようです。チームとして上司と座り、状況を説明する必要があります。まず、組織にプロセスの改善に取り組み、次にクライアントと協力して、物事がどのように機能するかについての同意を得ます。
これは私が言い訳をしているようにとても感じます。
言い訳を始めるとき、それは 難しい会話 または 重要な会話 を持っているときかもしれません。私はそれらの2冊のうちの1冊をお勧めします。特にすべての面で緊張が高まっている困難な状況に直面する必要がある場合、それらを読むことは私のコミュニケーションスキルの向上に役立ちました。
他のいくつかの答えに対処するため。
悲しいことに、権力は他の人から与えられるのではなく、ほとんどが自分で受け取られます。
Andrea がこれでどこに行くのか分かりません。はい、情報フローを修正する必要があります。ただし、PMとクライアントと協力して、プロジェクトの開始時に誰もが（とにかく）何に同意したかを確実に把握する必要があります。何らかの理由で取り決めがうまくいかない場合は、それを再検討し、仕事と役割を彼らにより適した人々に再分配します。
あなたは権力を取ったり、権力と戦ったりするのではなく、それを使って働き、それを飼いならし、誰にとってもうまく働かせようとします。
問題は、顧客が機能のビジネス価値をほとんど知っているが、その複雑さを理解していないことです。議論して明確にしてください。常に。
loki2302 からのこの引用はかなり注目されています。ソフトウェアエンジニアとしてのあなたの仕事の1つは、適切な人々が、タスクの難易度、実行にかかる時間、および何かを行う際にどのような種類のオプションやリスクが存在するかなどを確実に知ることです。チームの主なコミュニケーターとして、この情報を組織から顧客に伝えることは、理論的にはあなたの仕事です。
これらの期限を設定している人にアプローチするためのフォーラムを見つけてください。彼らはあなたと相談し、より現実的なものを提示できることを彼らに知らせてください。代替案は次のとおりです。クライアントにそれが起こらないことを伝えるか、クライアントに伝えることができます。
チームが作業を開始してからX日でできるように、プレゼンテーションを行うことができます。多分それは混乱でしたか？それが何度も繰り返されない限り、それは正直な間違いです。その後、それは無視されます。
あなたのチームが過去にこれらの締め切りに達したと思います。
残念ながら、私たちの業界ではその風土病なので、多くのデジタル/ソフトウェア代理店は自社の内部の仕組みや要件について何も知りません。多くの人はクイックキャッシュだけに関心を持っています。以前に見積りや期限を提供しないと多くの人が言ったように、経営陣に知らせてください。開発チームのスケジュールを知っている技術者からの見積もりなしで、技術的な作業をx時間で提供することはどのようにして可能ですか。
他のすべてが失敗した場合は、そのままにしておきます。
プロジェクトマネージャー/ボス/クライアントに達成可能な見積もりとスケジュールを伝え、計画を確認するよう依頼するか、最初に何をしてもらいたいかを考え出してから立ち去ります-決して彼に関与したり、楽しんだりしないでください。
あなたの見積もりを反映していないプロジェクト計画が彼から戻ってきた場合は、「見積もりは交渉していません。離れて歩いてください。
CYAのドキュメントがたくさんあることを確認してください。これらの文書を保管していることを関係者全員に明確にしてください。そのような記録を自分のメールアドレスにメールで送信し、上司にCCを送信しましたが、非常に成功しました。
ここでは、指さしの代わりに建設的な方法で出くわすべきアプローチがあります。私はあなたがこれを非難しているのではなく、非難の真実に関係なく、他人の過失で言い訳をするのはうまくいかないと言っているだけです。
これが発生した後、事後分析を行って、プロジェクトを完了するのに実際にかかった時間、またはプロジェクトを完了した場合にかかる時間を計算します。次に、十分な情報とそれを処理するための青信号がある時点から、利用可能なリソース時間を計算します。これらの数値を、締切に間に合わせるために必要な追加のプログラマー数に変換します。
次のように上司と話し合ってください。
プロジェクトの開始日Yと締め切りZの間にX人の空き時間があります。
プロジェクトを完了するには、X + Cの工数が必要でした。
他のプロジェクトにも同様のターンアラウンド要件がありました。
期待に応えるために必要な能力に到達するには、Q人の追加のプログラマが必要です。
...もちろん、予算が限られている場合は、プロジェクトマネージャーと協力して見積もりにもっと時間をかけることで、約束を守り、過剰に納品することができます（必ず控えめな管理を使用してください）。