締め切りが何であるかは誰もが知っていますが、正しく設定する方法を誰もが知っているとは限りません。 プロジェクトの締め切りを破ることについて話すために、多くの美しい比beautifulを取り上げることができます。 ゆびつめもその一例です。 これは、日本の指節骨の儀式的な切断です。 特に、彼らはミスのためにリーダーまたは所有者に謝罪するためにゆびつめに頼ります。 ヤクザについての映画を見たら、それが何であるかを理解できました。
儀式はバクト-ギャンブルプレイヤーの間で行われ、借金を払うための適切な代替品と見なされていました。 債務者は小さなファランクスの消費を許可し、これは彼の将来の生活を複雑にしました：彼はもはや剣をしっかりと持つことができず、戦いでは所有者を含む彼の仲間に依存しました。
あなたが住んでいる時間と場所、あなたが何をしていても関係ありません-チームの関係は強くなければならず、締め切りは尊重されなければなりません。 Live Typing Studioのマネージャーは、指を切り落とすことはありませんが、クライアントに与えられた言葉の責任を負っています。 経験上、6つのエラーを定式化することができました。これにより、間違いなく時間通りに仕事を失うリスクがあります。 これらの間違いをやめると、プロジェクトの質がどのように向上し、休息のためにどれだけの時間を空けることができるか、チームメンバーとクライアントとの関係がどのように改善されるかがわかります。
誰と仕事をしているのかわからない
開発チームの各メンバーは、ロールプレイングゲームのキャラクターのようです。誰かはプロジェクトに参加する能力は豊富ですが、忍耐力と集中力に欠けており、誰かがタスクにかかる時間を高く評価しています。 ティムリスは後者から得られ、通常はすべてが得意です。
これらすべてが非常に異なるため、人々は異なるスタイルで作業する必要があります。 厳しい管理であろうと、言葉を奨励するにせよ、インセンティブが必要な人もいます。 他の人は、クライアントのバックグラウンド、彼の理想と人生観、彼がチームに期待すること、そして彼がそれにどのように依存しているかについてあなたに話すことを期待します。 まだ機能するものもあります。 チームメンバーのキャラクターを許可しない場合、チームメンバーは自分のデバイスと最悪の習慣に任せられ、期限はおそらく混乱します。
専門家の経験も同様に重要です。 能力と生産性の係数に応じてタスクを配分します。そうしないと、6月または中旬は最初にできないタスクを失敗します。
プロジェクトの目的を理解していませんでした
Webサイトまたはアプリケーションでの作業は、設計段階から始まります。 これは深刻な段階です。製品を誰が使用するのか、どのような目標を達成するのか、どのように所有者にお金をもたらすのかはまだわかりません。 この段階の結果は、機能タスクに書き込まれ、機能タスクは、デザイナーおよび開発者向けのタスクを定式化するための基礎として機能します 。
アプリケーションの機能には明確な目的が必要です。 マネージャーが彼を理解していなかった場合、これは設計が不十分であり、請負業者に対してタスクが正しく設定されないことを意味します。 開発者は機能の役割を考え始め、それを膨らませ、最終的にコードの記述と書き換えに多くの時間を費やすことができるため、結果は予測できません。
これを回避するために、設計レビューを実施します。結果として得られるプロトタイプまたは設計をチーム全体が慎重に繰り返し見て、できるだけ多くのスペース、エラー、および欠落している画面を見つけます。 設計レビューの高品質な実装は、タイミングに大きく影響します。
ドキュメントの正確性と完全性が高いほど、開発者が開発中に誤解やバグを抱えにくくなり、期限の遵守が保証されます。
チームメンバーがタスクを誤って評価した
不正確な評価は、ほとんどの焦げた締め切りの原因です。 誤った評価の各ケースは、振り返って議論し、理由を見つけ、将来それらに対処するための戦術を開発する必要があります。
一部のジュニアやミドルは、自分の強みを過大評価する傾向があります。 経験を積むと、優れたマネージャーはこれを理解し始め、調整を行います。たとえば、10時間の見積もりを聞いた後、2を掛け、結果がより真実であることがわかります。
シニア開発者は、他の人よりも年上ではありませんが、タスクを完了するのに予想以上の時間がかかる可能性があることを知っており、これを自分とマネージャーに大胆に認めています。 上級開発者はリスクを認識しているので、そうすべきです。 これには次のエラーが当てられます。
あなたとあなたのクライアントはリスクを認識していません
リスクはあなたが計画しなかったすべてであり、それはタスクの作業を遅くします。 それらは外部および内部です。 インターネットの切断、ハリケーンまたは洪水、製品の要件の変更-これらは、アーティストが何らかの方法で影響を与えることができない外部の理由です。 問題の解決策の長期にわたる検索、開発者の神経衰弱-これらは内部的な原因であり、制御することができます。
分解、または大きなタスクを小さなタスクに分割することによるリスクの可能性を減らすことができます。 40時間は、必ずしもそれぞれ10時間の4つのタスクではありません。 分解中に、苦痛になじみのある支払いシステムをなじみのないプロジェクトに統合するには、既製のボックスソリューションでは不十分であり、独自のソリューションを作成する必要があります。 分解は、期限を正しく評価し、遵守の制御を簡素化するのに役立ちます。
特に原因がクライアントにある場合、外部原因の一部も影響を受ける可能性があります。 クライアントがテキスト、ロゴ、ドキュメント、API（サーバー側がクライアント側でコマンドを実行する場合）へのアクセスを許可するのは早ければ早いほど良いです。 また、クライアントに関連するリスクをまとめて収集し、契約に含めるとさらに良いでしょう。 これは、彼がプロジェクトの一部でもあることをクライアントに思い出させる素晴らしいものです。
クライアントが良好な状態であれば、プロジェクトは簡単に進みます。 タスクの状態について彼に通知し、問題を引き起こす可能性があり、期限切れにつながるすべてのことについて話し、問題を解決しようとしていることについて話します。 第一に、それがどのようにあなたを近づけ、可能な限り最も建設的な対話に参加するよう奨励するかに驚かれるかもしれません。 第二に、その用語の可能な出口とその再割り当ては、クライアントにとってもはや驚きではありません。 良いコミュニケーションは成功の鍵です。
プランBはありません
チェスプレーヤーのような優れたマネージャーは、イベントのオプションを事前に計算します。 しかし、チェスのプレイヤーがほんの数分だけ未来を見るなら、マネージャーは-確かに締め切りの数ヶ月前に。 この間、すべてのリスクが出てくるはずです。
そのような場合、多くの特に複雑なタスクでは、ユーザーエクスペリエンスが低下せず、全体的な結果が適切なままである、より予算の多いソリューションを選択する必要があります。 これはフレックスと呼ばれます。 フレックスオプション- カスタムデザインを放棄します 。 ただし、AppleおよびGoogleのガイドラインは引き続き使用してください。 締め切りに間に合うように、これが最善の選択肢であることをクライアントに説明することを忘れないでください。
クライアントの目には、クライアントに価値を加えることはできません。
それでも、謝罪から始めても大丈夫です;これは基本的な礼儀正しさです。 別のことは、謝罪は何か適用されたものによってサポートされる必要があるということです。 次の場合に最適です：
- チームとの会議で問題を分析し、結論を導き、これが二度と起こらないことをクライアントに約束します。
- 期限がプロジェクトの将来にとって意味があることを正当化します。 この16時間は、おそらくアプリケーションを綿密にテストし 、ユーザーの手に渡ると製品とクライアントの画像を取り返しのつかないほど破壊するバグを修正したことでしょう。
罪悪感を感じず、測定された生活のペースで誤動作を起こしたくない場合は、これらの間違いをしないでください。 最も基本的なものをリストしましたが、あなたの仕事の詳細が他のエラーにつながると思います。 あなたがコメントでそれらについて話すならば、それは素晴らしいでしょう。