はい、送信できます。 要件形成手順と開発サイクルを参照してください。 しかし、この場合、この顧客との関係がこれ以上ないという非常に高い可能性があります。 特に長期的な関係が予想される場合は、顧客を教育することができ、また教育する必要があることに同意します。 そして、これが最初の連絡先であれば？ 時には譲歩する必要があります。
破裂の症状は何ですか？
- 圧力とストレス
- 非常に厳しい締め切り
- 明確に定義されていないタスク
- 不確実性
これらすべてをどうするか？
1.落ち着きます。
ストレスの多い状態では、生産的な仕事はほとんど不可能であることを説明する必要はないと思います。 より多くのエラーが許可され、エラーの検索と除去に時間がかかります。 注意が低下します。 そのような場合は、パニックに陥るのではなく、プロジェクトの不確実性を減らすことに取り組んでください。
2.要件を定義します。
時には、これは完全に重要なタスクです。 一部のマネージャーは、もしあなたがそれらを押すと...プロジェクトの締め切り、あなたの考えを明確にする能力は完全に失われます。 「すべてが間違っている、すべてをやり直す必要がある」-これは標準オプションであり、誰もがすでに慣れていると思います。 しかし、「このグリーンは十分に重くありません」というフレーズは、かつて私を短いst迷に駆り立てました。 だから、彼らがあなたに何を望んでいるのかを理解したら、リストを作成し、それをもう一度（マネージャーまたは顧客と）話します。 各アイテムの確認を受け取ります。 そのため、相互理解に自信を持つことができます。
3.タスクに優先順位を付けます。
あなたがそれぞれ1時間の労働を伴う10のタスクのリストを持っていて、たった1つの夕方があなたの自由であるならば、占い師に行かないでください-時間がない。 したがって、すべてのタスクは優先度でソートする必要があります。 最良のオプションは、顧客自身がそれを行う場合です。 彼にとっては、上司への今後のプレゼンテーションを見越して、データをインポートする問題を修正するよりも、「この緑色のチップを左に6ピクセル移動する」ことがより重要かもしれないからです。 製品のデモンストレーションが成功した場合でも、さらに1週間または2週間で別の「リファクタリング」を行うことができます。
4.プロジェクトに興味があるすべての人の意識を高めます。
少なくとも、顧客（またはマネージャー）は、製品の新しいバージョンが配信された日にあなたが間に合わないことを知りたいと思っています。 私を信じて、適切なマネージャーの大半は、2週間で、イテレーション中に1〜2日の期間のシフトに耐える用意ができています。 しかし、不確実性と予測不能性を愛する人はいません。 条件および機能の変更をすべての関係者に報告します。 これで安心させてください。 同時に、より少ないプレッシャーで作業する機会を得ます。 発生した問題の説明とそれらを解決する方法とともに、進捗レポートを提供することは論理的です。
さらに、コールのログを保持する可能性がない顧客との通信を避ける必要があります。 つまり、顧客は電話でいくつかのタスクに集中することができ、配信にはまったく異なるタスクが必要です。 コミュニケーションに電子メールを使用すると、常に特定の手紙を参照する機会があるため、これらの状況を回避できます。
もちろん、請負業者であり、顧客と直接接触している場合-簡単な推奨事項：プロジェクトマネージャー（およびすべての関係者）をコピーに入れます。 それから、報告の間に、当局は「今まで何をしていたのか」を説明する必要はありません。
はい、そのような状況は健康とは言えません。 誰もが仕事を整理する方法を知っています-しかし、実際には、残念ながら、すべてが異なって起こります。
5.リストと作業計画を作成します。
緊急プロジェクトに16〜18時間連続して座らなければならなかったことを覚えています。 リストは私を大いに助けてくれました。 私は自分の脳が7〜9時間の仕事の後、知的活動ができなくなることを知っていました。 したがって、タスクを簡単にしました。 最初の1〜2時間は、タスクの詳細な分解とSRIの形成に費やしました。 その結果、完全に狂気の状態でさえ、私は非常に生産的に働くことができました。 なぜなら、私は一見複雑に思えたすべての作業を単純なタスクに分解したからです。
自由に使える日が数日ある場合は、ガントチャートを作成することをお勧めします。
6.グループタスク
可能であれば、同じタイプの問題を1つのアプローチで解決し、作業の全期間にわたってそれらを分散させないことが理にかなっています。 これにより、時間を稼ぐことができます-タスクを切り替える期間が短縮され、コードを開く、ドキュメントの学習、コミュニケーションなどの準備作業に費やす時間が少なくなるためです。
気配りのある読者は気がつくと思います-問題のプロジェクト管理の基本概念についてではありません。 それは彼らについてです。 問題、リソースの不足、何らかの結果を得るために必要な期限があります。 おそらく、違いは、うわさに伴うストレスだけです。
私には、緊急作業自体が持つネガティビティがあれば、それからも恩恵を受けることができるように思えます。 ここに私が自分のために特定したものがあります：
- Avraliは動員を余儀なくされました。 限界まで取り組むことで、能力についてさらに学ぶことができます。
- 問題を解決するための新しくて本当に効果的な方法を見つける機会があります
- いくつかのケースでは、噂はチームビルディングに貢献します
しかし、これはそのような状況が例外的な場合のみです。 プロセス全体が「極端なプログラミング」に基づいている場合-これは、転職を真剣に考える機会です。 （かつて、インタビュー中に、候補者はこの用語を次のように私に説明しました：金曜日の夜に、ビジネスロジックを確定し、テストなしで戦闘サーバーにプロジェクトをアップロードします）。
最後に-マネージャー、顧客、そしてあなた自身に正直になりましょう。 要件と非現実的な期限の長いリストを受け取ったとき、それを内部で取り上げて「それは完了します」と言うべきではありません。 これにより、もちろん全員を安心させることができますが、他人の間違いに対しても責任を負い、これらの受け入れられたタスクを後で解決する必要があります。
オリジナルはこちらです。