サイト開発者として、私はそのようなタスクに出会います。 これらのタスクの日付は、ビジネス要件に基づいて設定されます。 厳しい締め切りの中で、ビジネスの要件をどのようにうまく実現できたかについての経験を共有します。
私は自分で導かれ、何度も助けてくれたとアドバイスします。 各声明には、議論、反省、批判が必要です。
記事の口調はカテゴリー的です。 すぐに謝罪します。 簡潔にするために、「考える」、「思う」などのフレーズを省略しました。
例に基づいて経験を共有します。 次の問題を思いつきます。 数字と用語は条件付きです。
私たちは、子供のおもちゃを販売する電子商取引サイトを開発しています。 現金のみでのお支払い。 以下を使用して非現金支払いを実現します。
- PayPal
- Yandex.Money;
- QIWIウォレット;
マネージャーは期限を設定しました-1週間。
完成したコードを読み、アーキテクチャを研究し、これらの要件について考えました。 彼らは、誰もキャンセルしなかった5つのタスクが私たちにかかっていることを思い出しました。 そして、彼らはあなたが確立された時間枠内で対処できないことを認識しました。
あなたはマネージャーに行き、状況を説明しました。 マネージャーは次のように答えました。
- 緊急のタスク、時間がある
- OK、2つのタスクを中断します。 残りの3つのタスクを並行して実行します。
- OK、このタスクを1.5週間延長します
これらのオプションは適していません。 時間が足りません。 あなたは行き止まりにいて、そのような解決策について考えました：
- 早く仕事を始めましょう。
- 仕事に長くとどまる。
- あなたはすでに絶えず遅れています、あなたは2倍長く残る必要があります。
どうする？
ここで、スティーブン・R・コヴィーの著書「7つのスキルの非常に効果的な人々」が役立ちます。
- 積極的に
- まず、究極の目標を想像してください。
- 最初に行う必要があることを行う
- ウォンの精神で考える-ウォン
先を見越して -問題の解決策を提案してください。 一部のマネージャーは、ドアに「提案なしで入らないでください」という対応する標識さえ持っています。
まず、究極の目標を想像してください。ここでの究極の目標は、問題を解決することではなく、ビジネスの現在のニーズを満たすことです。
最初に必要なことを最初に行います -これが問題の解決策です。 私たちは独立して優先順位を見つけ、タスクを段階に分けます！
勝利の精神で考えてください-勝利 -フェージングにより、締め切りよりも早く完成した機能をリリースできます。 マネージャーは、必要な機能を早期に受け取った場合、ステージについての提案を喜んで受け入れます。
スクラム方法論の定義も思い出してください。これは、ハードフィックスと短時間の反復により、エンドユーザーに最高の優先度が決定される新しい機能を備えた作業ソフトウェアを提供する一連の原則です。
アクションは次のとおりです。
- タスクをサブタスクに分割します-プロアクティブなアプローチ。 マネージャーに尋ねないで、自分でやってください。
- 各サブタスクの優先順位を決定します。
- タスクを段階に分けます。
- マネージャーとともに、条件を調整します。
- 大きなタスクを段階的に解決します。
サブタスクは次のとおりです。
- PayPalを実装し、
- ヤンデックスのお金を実現し、
- QIWIウォレットを実装する
マネージャーは、サブタスクのリストを調整します。 優先度は、支払いシステムを使用したい顧客の割合に基づいて設定されます。 そのような段階を受け取った：
- Yandex.Moneyユーザーの60％
- QIWIウォレットユーザーの30％
- PayPal-ユーザーの10％。
マネージャーとともに、次の日付を設定します。
- Yandex.Money-3日
- QIWIウォレット-4日
- PayPal-2日間。
結果：
1週間以内に問題を解決するつもりはないことが判明しましたが、それよりも早く、顧客に役立つ機能をリリースする予定です。
簡単なタスクで示したパーティション分割。 実際には、タスクははるかに難しく、より多くの段階があり、マネージャーは提案に同意しません。 正当化するために、UMLダイアグラムを使用します。
図は、タスクが複雑であり、各要素に多くの詳細と機能が含まれていることを明確に示しています。 このような記述的な説明に基づいて、タスクを時間どおりに実現できない理由を正当化します。
個々の要素の期限は、大規模なタスクの実装の期限よりも正確に推定されます。
結論：
- 不適切な用語についての言い訳や苦情の代わりに、建設的な解決策を提案しました-タスクを段階に分解します。
- ダイアグラムの助けを借りて、タスクの複雑さを証明し、このタスクが複数の段階に分割されていることを正当化しました。
- マネージャーは満足しています-最初のリリース（ステージ1）が予定より早く行われ、有用なドキュメントが登場しました。
- 管理者とのコミュニケーションスキルが向上し、締め切りが不十分で大規模なオーバーホールが回避されました。
- 経験豊富な同僚によって改善された既成のソリューションを提供することにより、設計および文書化のスキルが向上しました。
- 作業がより面白くなりました-プロジェクトに関する追加情報を学びました（ユーザーの優先順位）
ヒントの形での結論：
- 既製のソリューションが付属しています。 追加のボーナスを受け取ります-エラーが修正されます。
- タスクをサブタスクに分割するのに多くの時間を費やさないでください。 ポイントは、議論のためにドラフトを準備することです。
- コーディングを開始しないでください。 マネージャーがあなたの前に図を設計し、描いたとしても。 タスクの独自の解釈をスケッチします。 これにより、不明な点が明確になり、時間を大幅に節約できます。
- 自分に優先順位を付けてみてください。
- 自分自身を設計し、マネージャーまたはチームのリーダーが完全にあなたのステップを制御し、修正するという事実に依存しないでください。 彼らにはこれの時間がありません
参照：
- スティーブン・R・コヴィー著「7つの非常に効果的な人々のスキル」
- スクラム方法論
- Steve McConnell-完璧なコード。 マスタークラスは、設計と擬似コーディングの利点に関するものです。
- 苦しみによる発達
- UML（Craig Larman）の設計、分解、使用。 （ありがとう、 AlexanderG ）
PS
- トピックのリンクと有用なヒントを待っています-記事に追加します
- トピックが興味深い場合は、複雑な例を使用して、タスクを設計してステージに分割するプロセスを分析する記事を書きます。