期限に現実的な期待を設定する

私は小さなチームの技術リーダーです。私のプレート上の主要なタスクの1つは、クライアントとのコミュニケーションです。私が特に難しいと思うことの1つは、期限がクライアントによって義務付けられており、頻繁に相談されないためです。

通常、相互作用は次のパターンに従います。クライアントは、追加したい機能Xを考え出します。機能Xは、約6営業日後の来週のアプリリリースで見栄えがよくなります。この時点で、機能リクエストは承認を受ける必要があり、対処する必要がある他の依存関係が頻繁にあります。最終的に、N日後に、機能のリクエストが私のチームに伝わります。元のデッドライン（開発者以外のマネージャーが設定した）が達成できたとしても、それはもはや達成できません。私のチームは非難され、落胆し、全体的な敗北の雰囲気があります。私は落胆し、敗北します。

明らかに、プロセス全体が壊れています。残念ながら、私はここで権力の座にいないので、私にできることはあまりありません。私の現在のアプローチは、クライアントに開始日と締め切り、フィーチャーの範囲などについて穏やかに思い出させることです。これは言い訳をしているように感じます。

似たような状況にあったことはありますか？役に立たなかったこと、役に立たなかったことは何ですか？

あなたは本当にこれについて上司に話し、いくつかの基本的なルールを設定する必要があります：

• 締め切りは、コミットしない限り締め切りではありません。
• 推定値は、あなたがそれを与えない限り推定値ではなく、それから「推定値」であり、厳しい締め切りではありません。

Robert MartinのClean Coderには、このことを上司に伝える方法についての非常に良い章があります。営業チームが不可能なコミットメントを行っている場合、それはあなたの責任ではありません。

新しい機能を取得したら、それを推定し、PERTを使用して確率分布を作成します。「4日以内に完了させる必要がありますが、最大で8日かかる場合があります」。あなたの立場を主張をする。セールスマンと見積りを決して交渉しないでください、不可能にコミットすることになります。

これを数回繰り返した後、セールスマンはうんざりして馬鹿に見えるようになり、振る舞いを、あなたが終わるという約束ではなく、「開発チームに確認し、いつ成し遂げられるかを確認します」に振る舞いを調整します。速報。

似たような状況にあったことはありますか？役に立たなかったこと、役に立たなかったことは何ですか？

主に機能するのは、力に真実を話すことです。

事実を収集します。事実を提示します。顧客が自分のペースで学習する（または学習しない）ようにします。

私のチームは非難され、落胆したと感じており、敗北の全体的な雰囲気があります。

なぜあなたのチームは非難に気付いていますか？顧客があなたを迂回して直接チームと話している場合、あなたは効果がなくなり、その理由を理解する必要があります。

あなたのチームは、「非難」や非難に無知であるべきです。彼らは単にソフトウェアを構築する必要があり、あなたはあなたが何をしていて、いつそれをしているのかを単に顧客に伝えるべきです。

顧客は、最終的にはプロセスを理解するために成長する必要があります。悪い習慣を打破するには、かなりの繰り返しが必要です。大いに。

私はこの正確な状況にあったが、それは快適ではなかった。しかし、私がやったアプローチの1つは、現在開発中の作業の記録を注意深く保持することでした。タスクが実行されると、クライアント、管理者、またはプロジェクトマネージャーに、これが優先事項になったために他の作業がスリップすることを思い出させます（場合によっては、2番目の推測を行い、締め切りを延ばすためにプッシュし続けることもあります）。

それ以外の場合は、プロジェクトマネージャー/顧客連絡/管理/営業担当者であるクライアントを処理し、これらの期限に同意する石垣に、そのノミを叩き続ける必要があると思います。何かをするのに5日かかることに同意するなら、彼らは明らかに5日間の開発について話しているという事実をよく打ちました。つまり、あなたがそれを手に入れてから5日かかることを意味します次の2日間は派手な言葉を作成しますdoc）。

ただし、開発リーダーであるため、そもそも相談しない場合、このような決定は関係ありません。

また、できるだけこれからチームを保護する必要があります。難しいのですが、できる限りクライアント/管理の政治から締め出される必要があります。そうでない場合は、より多くのヘッドハンマーが必要です。

基本的に、私はそれを楽しんでいませんでしたし、プロセスをどれほど厳しくしても完璧になりませんでした。しかし、私はなんとか物事を改善することができました。

おそらくできることは、顧客と話すことだけです。表示されているとおりに何が起こるか、すべてのリスクなどを説明してください。私は同じような状況にあり、本当に怒っていました。今でも、私がすべての技術的な見積もりを担当しているとき、よく耳にします-月曜日までにそれをやりたいです。私はちょうど言います-あなたはそれを手に入れません、月曜日までにあなたが何を望んでいるか正確に議論しましょう。そして、多くの場合、すべての重要な機能は実装するのが非常に簡単で、月曜日は絶対にうまくいくようです。他のすべての機能は、その後のリリースでスケジュールされます。

問題は、顧客が機能のビジネス上の価値をほとんど知っているが、その複雑さを認識していないことです。話し合い、明確にするだけです。常に。

開始日が機能をリクエストした日付よりも後であることをクライアントに思い出させるのは良いスタートです。また、クライアントと最初に話し合った人と話をして、機能の詳細を取得し、その時点でクライアントがより良い期限になることを伝えることができるようにする必要があります。すでにクライアントと連絡を取り合っているので、「だから、この締め切りに同意したのは誰ですか？

話し合いに参加してくれない場合、または黙って同意する期限を守るように言われた場合は、チームが時間通りにいれば会社全体の見た目が良くなることを思い出させることができます。それを達成するためには、締め切りに入力してください。

情報の流れを修正します。

• クライアントと通信することになっている場合は、プロジェクトのすべての利害関係者（クライアントを含む）に常に直接連絡するように強制します。

悲しいことに、権力は他の人からあなたに与えられるのではなく、主にあなた自身によって奪われます。

私のプレート上の主要なタスクの1つは、クライアントとのコミュニケーションです。私が特に難しいと思うことの1つは、期限がクライアントによって義務付けられており、頻繁に相談されないためです。

クライアントとのコミュニケーションを担当することになっている場合、組織内の責任者とクライアント側のカウンターパート間でこの情報を伝達できるように、なぜスケジュール（および予算）について相談しないのですか？この問題を修正することは、あなた、あなたのチーム、そしてあなたのプロジェクトにとって大きな利益になると思います。

クライアントは、追加したい機能Xを思い付きます。機能Xは、約6営業日後の来週のアプリリリースで見栄えがよくなります。この時点で、機能リクエストは承認を受ける必要があり、対処する必要がある他の依存関係が頻繁にあります。最終的に、N日後に、機能のリクエストが私のチームに伝わります。元のデッドライン（開発者以外のマネージャーが設定した）が達成できたとしても、それはもはや達成できません。

控えめに言っても、このスケジューリングのシステムは奇妙に思えます。

私の経験では、クライアントは特定のリリースにサインオンします。必要な機能と変更のリストを送信し、必要なときにそれらを送信してから、ソフトウェアを構築するチームと交渉します。または、開発チームに機能の優先順位リストを提供し、開発チームはさまざまな機能セットをいつ出荷できるかについての見積もりを提供します。他にもバリアントがあります。

しかし、私が許可したことは一度も見たことのないことの1つは、特にリリースから1週間後ではなく、ゲームの後半でリリースを変更できることです。デザイナー、開発者、テスターに​​そのような圧力をかけるのは適切ではないようです。繰り返し開発を行っている場合、優先度の高い機能であれば、バックログのフォームに追加して、できるだけ早くそれを取得するようにしてください。優先度の高い機能ではない場合、このリリースでは絶対に不要であり、次のリリースまで待つことができます。

設計、開発、テスト、配信の各チーム、および顧客に対応する基本ルールを設定し、機能の凍結、コードの凍結、および配信を行うことをお勧めします。これらを書面に入れ、全員からコミットメントを得て、それに固執します。一度振ると、さらに曲がることが予想され、プロセスを制御できなくなります。

残念ながら、私はここで権力の座にいないので、私にできることはあまりありません。

あなたは一人ではないかもしれません。しかし、あなたのデザイナーや開発者、テスターは、スケジュールを満たすために多くのプレッシャーを受けているようです。チームとして上司と座って状況を説明する必要があります。最初に、組織にプロセスの改善を約束させ、次にクライアントと協力して、物事がどのように機能するかを理解してもらいます。

これは私が言い訳をしているように感じます。

言い訳をし始めたら、難しい会話や重要な会話をする時が来るかもしれません。私はこれらの2冊の本のいずれかをお勧めします。それらを読むことは、特にあなたがすべての面で緊張が高い困難な状況に直面する必要があるとき、私のコミュニケーション能力を向上させるのに役立ちました。

他の回答のいくつかに対処するため。

悲しいことに、権力は他の人からあなたに与えられるのではなく、主にあなた自身によって奪われます。

アンドレアがこれでどこに行くのかわかりません。はい、情報の流れを修正する必要があります。しかし、プロジェクトの開始時に全員が合意したことを確実に把握するために、PMとクライアントと協力する必要があります。何らかの理由で取り決めがうまくいかない場合は、再検討し、仕事と役割をより適した人々に再配分します。

あなたは権力を奪ったり、権力と戦ったりしませんが、あなたはそれで働き、それを飼い慣らし、それを皆のために働かせようとします。

問題は、顧客が機能のビジネス上の価値をほとんど知っているが、その複雑さを認識していないことです。話し合い、明確にするだけです。常に。

loki2302からのこの引用はほとんどスポットです。ソフトウェアエンジニアとしての仕事の1つは、適切な人がタスクの難しさ、所要時間、何かをする際にどのようなオプションやリスクが存在するかなどを確実に把握することです。チームの主要なコミュニケーターとして、この情報を組織から顧客に伝えることは、理論的にはあなたの仕事です。

これらの期限を設定している人にアプローチするフォーラムを見つけてください。彼らはあなたと相談し、より現実的な何かを提示することができることを知らせてください。代替手段は次のとおりです。発生しないことをクライアントに伝えることも、クライアントに伝えることもできます。

チームが作業を開始してからX日以内にできるように提示できます。たぶんそれが混乱だったのでしょうか？それが何度も繰り返されない限り、それは正直な間違いです。それからそれはただの怠慢です。

あなたのチームは過去にこれらの期限に間に合っていたと思います。

残念ながら私たちの業界では風土病なので、多くのデジタル/ソフトウェア代理店は会社の内部の仕組みや要件について何も知りません。多くの人は手っ取り早い現金にしか関心がありません。見積もりや期限を提供していない場合は、多くの人が以前に言ったように、経営陣に知らせてください。開発チームのスケジュールを知っている技術者からの見積もりなしで、x時間までに技術的な作業を提供することはどのように可能ですか。

他のすべてが失敗した場合は、そのままにします。

プロジェクトマネージャー/ボス/クライアントに達成可能な見積もりとスケジュールを与え、彼にあなたの計画を確認するように頼むか、彼があなたに最初に働きかけたいことを考えてから立ち去ってください。
彼があなたの見積もりを反映していないプロジェクト計画で戻ってきたら、「私は見積もりを交渉しません。」という声明で彼に返してください。立ち去ります。

十分なCYAドキュメントがあることを確認してください。これらの文書を保管していることを関係者全員に明確にしてください。私はそのような記録を個人のメールアドレスにメールで送信し、上司にCCを送信しました。これは非常に成功しました。

これは、指を指すのではなく建設的に見られるアプローチです。私はあなたをこれで非難していません。非難の真実に関係なく、他の誰かと過失の言い訳をするのはうまくいかないと言っているだけです。

これが発生した後、事後分析を行って、プロジェクトを完了するのに実際にかかった時間を計算します。次に、十分な情報と作業に必要な青信号の時間から利用可能なリソース時間を計算します。これらの数値を、締め切りに間に合わせるために必要な追加のプログラマー数に変換します。

これらのラインに沿って上司と会話しましょう。

プロジェクトの開始日Yと締め切りZ
の間にXの工数がありました。プロジェクトを完了するにはX + Cの工数が必要でした。
他のプロジェクトでも同様の所要要件がありました。
期待に応えるために必要なキャパシティに達するには、Qの追加プログラマが必要になります。
...もちろん、予算が限られている場合は、プロジェクトマネージャーと協力して、見積もりにさらに時間を組み込むことで、約束を十分に果たせず、過剰に配信できるようにすることもできます（トライトマネジメントスピーチを使用してください）