私の意見では、主なことは私たち（小規模開発者）にとってこれは非常に「長いお金」だということです。 マネージャーが技術的なタスクのすべてを文書化したとしても、実際の開発では、このようなプロジェクトは、ほとんどすべてに生じるさまざまな提案、改善、完了、困難、不十分なフィードバック、新しいアイデア、思考などのバラストとともに急速に成長します開発段階。
個別に表示されないのはこれらすべての小さなもののようで、何らかの理由で追加の支払いを要求することは深刻ではありません。 これらの小さなものの多くがプロセスに蓄積するため、それらの実装は、用語の大幅な増加または開発チームの追加の負担につながります。
問題を部分的に解決します。非常に詳細です。 しかし、人々もそれを書きます、そして、実践が示すように、すべてを考慮することはまだ不可能です。 したがって、次のステップでは、プロジェクトを論理的に完成した部分に分割し、各部分は納入時に支払われます。 たとえば、次を選択します。
1.設計、レイアウト
2.サイトを構築する
3.プロジェクトを埋めます。
4.ユーザー管理
5.インタラクティブ。 フォーラム、コメント、通知、内部メール
6.請求など
部品の数と量は、ワーキンググループの裁量で決定されます。 これに新しくて革新的なものは何もありません。同じように、またはほとんど同じだと思います。 休憩は「長いお金」を多かれ少なかれ「速く」するが、アイデア、追加、および他の「バラスト」に関する主な問題を解決しないからです。
最近から、メインステージのリストに、最後の段落に必ず「ラッピング」が含まれており、検証と初期テストと組み合わせることもあります。 そして金銭的には、改良は残りの段階より安くはありません！
このシンプルなアプローチにより、チーム全体と顧客の心の安らぎを維持することができます...私たちは冷静にプロジェクトをある部分から別の部分に移し、顧客のすべての願いとアイデア、そして私たち自身を別のファイルに不安に書き留めます。
リストの最後から2番目の項目が実装されるまでに、作業アルファが得られます。 しかし、最も重要なこと：
- 私たちのリストにあるアイデア追加の真の利点を、 統合プロジェクトの観点から評価する素晴らしい機会です。
- プロジェクトの主要な作業が完了すると、いくつかの考えが「ホット」であることが示唆され、それらの実装には単に必要がなく、多くの意味があります。
- 顧客は、彼の「ささいなこと」によって占有されているボリュームの数を確認できます。