プロジェクトを開始する最善の方法、または耐え難いほど苦痛にならないようにする方法

すべての良い一日。 プロジェクトの設計について話す番でした。 私自身の経験から、プロジェクトを一から作成することは、既にあるものを整理するよりも難しい場合があることを知っています。 これは主に、あなたまたはあなたが残した遺産によるものです。 この記事では、特別な注意を払う価値があるものを説明し、フォローするための短い計画を提案します。

プロジェクトの理解

何かを計画する前に、どのプロジェクトを実装する必要があるかを理解する必要があります。 私自身は、次のようないくつかのカテゴリのプロジェクトを特定しました。

• ワンタイムクラフトは、ある種のグラフィックコンセプトの作成と投資家へのさらなる販売を目的としたプロジェクトです。 このタイプのプロジェクトの特徴的な機能は次のとおりです。
  
  
  
  
  1. 非常識なドキュメント。 基本的な考え方は明確ですが、ビジネスケースは完全に混乱しており、考慮すべき論理的なホールはありません。
  2. 締め切り。 ドキュメントの作成からプロトタイプ作成まで最大3か月。
  3. 開発計画はなく、さらなるサポートは計画されていません。
  4. 小さなチーム。 通常、デザイナーを含む最大5人。
  5. ビジネスプロセスの欠如。 すべての相互作用は混interとしており、対人コミュニケーション、重要なポイントの明確化、および/または外出先での発明に基づいています。
  6. 役割がぼやけています。 権限と責任範囲の明確な分割はありません。
  7. 実際のデータはありません。 すべてのデータは「美」のために生成され、最適な表示のために調整されます。
  8. 開発をスピードアップするために、外部依存関係が完全に使用されます。
  
  
  
• スタートアップは、特定のアイデアを実装するように構成されたプロジェクトで、その後の開発です。 通常、これらのプロジェクトはスパイラルモデルに従って開発され、このため、最初のタイプ（ワンタイムクラフト）とほぼ同じ特徴を備えています。
  
  
  
  
  1. ステージへの明確な内訳。 最小：特定の期間に実装する必要がある用語と機能のリスト。
  2. 比較的健全なドキュメント。 分析が行われ、完了段階のベンチマークが設定され、改良がスプリント中に行われることがよくあります。 アジャイルが主張した事実にもかかわらず、ほとんどの場合、滝を使用します。
  3. 主な機能の平均期限。 平均して、6〜12か月。
  4. 初期段階では、外部の依存関係が使用され、最終的には独自の実装に変更されます。
  5. 小さなチーム。 通常、最大7〜10人です。
  6. 役割は分離されていますが、責任は曖昧です。
  7. プロジェクトは変更できます。 ある段階では、実装の概念またはアプローチが変わる場合があります。 通常、これは投資家の要件、最初に失敗したアイデア、またはアーキテクチャのエラーによるものです。
  8. 条件付きライブデータ。 フォーカスグループで実行するか、サードパーティのリソースからライブデータを解析します。 確かに、これは常に起こるわけではありません...
  
  
  
• 情報システムは、サードパーティサービスへの統合計画とともにアイデアを実装するプロジェクトです。
  
  
  
  
  1. 開発計画があります。
  2. 明確に書かれたドキュメント。 最小：APIの説明が文書化されています。
  3. サードパーティのサービスとの統合、松葉杖のインストール、またはシステムの一部の再構築が必要になる場合があります。
  4. 中間リリース、ホットフィックスがあります。
  5. 中規模のチーム。 通常10から20-30人まで。
  6. 責任の明確な分離。
  7. セキュリティ要件：分析後、システムの崩壊につながるケースが作成されます。
  8. 時間はテストに費やされます。
  9. アジャイルによって使用されます。
  10. ほとんど常にバックログがあります。
  11. 独自に実装するのに費用がかかる外部依存関係のみが使用されます。 独自のものと同等に実践されています。
      
      
  
  
  
• クローズドシステムは、お客様の特定のニーズに応えるために設計された膨大なプロジェクトであり、さらに洗練されています。
  
  
  
  
  1. 特定の顧客。
  2. 開発計画があります。
  3. 開発用のドキュメントを設計します。 ユーザーを支援するために、お客様のリクエストに応じて個別のドキュメントが作成されています。
  4. ユーザー権利の差別化。
  5. ほとんど常にバックログがあります。
  6. 通常、チームの規模は平均よりも大きくなります。 原則として、10人から心拍数の損失まで。
  7. アジャイルによって使用されます。 随時、追加のタスクが到着しますが、それらはすべてのコストで実装する必要があります。
  8. 予期しないデモンストレーション。 上級管理者の要求に応じて要求が発生するため、実行可能なテスト回路が冗長になることはありません。
     
     
  
  
  
• Saasソリューションは、柔軟な構成と特定の顧客向けのさらなるカスタマイズを備えた膨大なプロジェクトです。
  
  
  
  
  1. マルチモジュラーシステム。 システムはいくつかの部分に分かれています。 特定のプロジェクトの範囲外であっても、個別に使用できます。
  2. 明確な計画。 最小：機能の実装に必要な人件費。 近代化とリファクタリングの時間です。
  3. 体積のドキュメント。 原則として、テストケースを含むほとんどすべてが説明されています。
  4. 原則として、外部依存関係はなく、システム部分の独自の実装が記述されます。 サードパーティの実装がある場合でも。
  5. いくつかの開発チーム。 誰であれ、開発のバックエンドであろうとフロントであろうと、開発の責任を負います。
  6. すべておよびすべてのカバレッジをテストします。 自動、単体、回帰、および統合テストが使用されます。
     
     

すべてのグラデーションは条件付きで、フロータイプが最も頻繁に見つかります。 すべての型が相互に変異する可能性があることに注意してください。唯一の微妙な違いは、近​​代化のコストです。 たとえば、プロジェクトは元々「ワンタイムクラフト」でしたが、その後「クローズドシステム」に進化しました。 通常、これにより、システムの完全またはほぼ完全な書き換えまたはリファクタリングが行われます。 ご存知のように、これは経済的に実行可能ではありません。 同じ理由で、どのようなプロジェクトを最初から作成する必要があるかを理解し、その将来の運命を決定することをお勧めします。

プロジェクトのタイプを決定するために、以下で質問をしました。あなたが望むものがあなたに明らかになる答えを受け取りました。

• プロジェクトの目的は？
• 実装する必要があるものの完全なリスト？
• ドキュメントはありますか？
• 締め切りは何ですか？ 正確な日付が望ましい。
• サードパーティシステムとの外部対話が計画されていますか、またはプロジェクトに外部APIがありますか
• 開発はありますか？
• チームの規模は？
• 誰が何を担当しますか？ 誰がタスクを設定し、誰が受け入れ、誰が拒否権を持っているか。
• 開発計画はありますか？
• 顧客は誰ですか？
• ターンキーソリューションの購入に予算はありますか？
• どの方法論に取り組む予定ですか
• 類似物はありますか？
  
  

ご覧のとおり、リストはそれほど大きくありません。 ただし、何らかの不明な理由により、何かを始める前に同様の質問をする人はほとんどいません。 なぜプロジェクトのタイプを理解する必要があるのですか？ あなたはいつもプロジェクトを永遠にライブにしなければなりませんか？！ 概して、あなたは正しいですが、蒸し暑い冗談のように微妙な違いがあります。 これらのニュアンスはリソースとタイムラインです。 私たちがビジネスのために働き、タスクを実行することを忘れないでください。 プロジェクトの種類を知っていれば、あなたは目標を達成するために良心の揺らぎなしで何かを犠牲にすることができます。

技術の選択

選択の際には、ルールを遵守することをお勧めします。テクノロジーは超新星ではなく、時代遅れであるべきです。 テクノロジーまたはフレームワークが新しい場合、次のような問題が発生する可能性があります。

• 有資格者を検索する
• 開発の見通し：開発の初期段階では、開発が停止する可能性があります。逆に、技術が古い場合は、バグを自分で解決する必要があります。
• 新しいもののターンキーソリューションの欠如、および古いもののアップデートの欠如。
  
  

この問題のリストは、テクノロジーだけでなく、サードパーティの依存関係にも関連しています。 上記のすべてが、プロジェクトを芽に埋めることができます。

特定の何かを選択する前に、数回考えてください。 プロジェクトの重要な要因を含む悪名高い利益の表を作成します。



この例は架空のプロジェクト用です：

プロジェクト機能の名前。	プロジェクト重要度比
フォームを操作する	3
ルーティング	1
アニメーションの書きやすさ	0.3

表からわかるように、選択の重要な基準は「フォームの操作」と「ルーティング」です。 このプロジェクトのアニメーション作成の単純さは重要ではありません。 次に、新しいテクノロジー列を追加して、テーブルをアップグレードします。 この場合、2つあります。

プロジェクト機能の名前。	プロジェクト重要度	テクノロジー1	テクノロジー2
フォームを操作する	3	+	±
ルーティング	1	+	±
アニメーションの書きやすさ	0.3	+	-

表のデータに基づいて、フォームとルーティングでの「テクノロジー2」の動作は不十分であり、アニメーションの作成はサタンを呼ぶようなものであることがわかります。 その結果、この技術の比重は2です。なぜ2なのかと尋ねます。 すべてがシンプルです！ ±を入力すると、このテクノロジーでは特定の機能を実装しますが、何らかの「クランチ」を使用するか、より労働集約的です。 私たちの比較では、「テクノロジー1」の方が収益性が高く、合計で4.3です。 金額の形成に関する説明は不要だと思います。 この表は、テクノロジーだけでなく、リストからの比較と選択を必要とするすべてのもので機能します。 主なことは、書く基準が多いほど、選択しやすくなることを忘れないことです。

建築

現在、建築設計用のツールを提供するさまざまなサービスから選択することが可能です。 確かに、それらのどれにも欠点があります。いくつかは重大ですが、誰かはそうではありません。 私は「古くさい」ので、一枚の紙とペン、またはボードとマーカーを好みます。

最初に何をつかむかを理解するには、システムの主要部分の概要を説明してから、アーキテクチャの構築方法を選択する必要があります。 原則として、実際には3つだけが使用されます。

降順 -開発者はシステムの大きなノードからプッシュして、小さなノードに移動します。 アーキテクチャの意味は、主要なコンポーネントが小さなノードを含む大きなノードであることです。

昇順 -開発者は小さなパーツからプッシュして、大きなパーツに移動します。 アーキテクチャの意味は、最初は多くの小さなコンポーネントが作成され、大きなコンポーネントはすでにそれらから組み立てられているということです。

モノリスは不可分なアーキテクチャであり、しばしば「レガシー」と呼ばれます。 実際、これは堅固な構造であり、その変更には「隙間」のない解決策が必要です。 これは最悪の選択肢ですが、私たちの世界のあらゆるものと同様に、存在する権利があります。 モノリスは特定の機能を実装するために使用されるものであり、今後維持する予定はありません。 他と比較して、このアプローチの速度は何倍も高速です。 まあ、あなたが目をたくさん閉じられるからです。

アーキテクチャの選択は、プロジェクトの目的と開発の速度に依存します。 通常、最初の方法は、期限が切れず、大きなモジュールの数が少ない場合に使用されます。 その特徴は、特定のモジュール間の関係を正確に表現できることです。 マイナス面のうち、一連のアクションに関連する長い開発時間に注目できます。



2番目の方法は、高い開発速度が必要であり、最上位アーキテクチャの理解がない場合に適しています。 機能は、さまざまな大きなノードで使用されることがある多くの小さなコンポーネントです。 他のタスクに関係なく、ほとんどすべての開発を並行して実行できることに注意してください。 このアプローチの欠点は、上位レベルのアーキテクチャの要件を満たさないコンポーネントになります。したがって、コンポーネントを書き換えるか、カスタマイズの可能性を作成する必要があります。



実践が示すように、すべての開発手法はスパイラルアプローチに縮小されており、機能の段階的な構築が特徴となっています。 この記事の枠組みの中で検討することは適切ではないと思います。

計画中

いわゆる「ロードマップ」は、仕事をより効率的に行うのに役立ちます。 実際、これは特定の機能の配信の条件付き期限を伴うスケジュールです。 日付は延期できますが、実践が示すように、上記の点を適切に実装することで、修正は最大30％になります。 実際には、これは通常10〜15％です。 計画により、プロジェクトの進行状況を追跡したり、たるみを確認したり、リソースやシフト日などの形で調整したりできます。

後で彼らはあなたに感謝します

すべてのプロジェクトはドキュメントから始まり、それが多ければ多いほど良いです！ だから怠けてはいけません-私たちはすべてを文書化します。 はい、時間がかかりますが、その後、あなたのせいではなく何かがうまくいかない場合、リーダーシップの怒りからあなたを救うことができます。 また、プロジェクトに参加した後は、作成したものを理解する必要がある人々を忘れないでください。 そして文書がなければ、これは簡単ではありません。

結論

この記事では、プロジェクトを開始するときに、どのように行動し、何を探すべきかについて説明します。 これらの段階は、前部、後部、テスト、またはすべてを同時に行う場合に共通です。 誤解を招かないように、私は意図的にテクノロジーの詳細を避けました。

使用するテクノロジースタック、アーキテクチャ、およびプロジェクトの時間枠を決定する必要がある場合に選択できる場合、以下の表が役立ちます。

プロジェクトの種類/機能	使い捨てクラフト	スタートアップ	情報システム	クローズドシステム	サースのソリューション	他のプロジェクト
5歳未満の人の数		X	X	X	X
7から10までの人数
10〜30人の人数	X
30を超える数量	X	X
完了日は最大3か月		X	X	X	X
納期は6〜12か月
12ヶ月以上の期間	X
ドキュメント
他のシステムとの統合要件
既知の特定の顧客
さらなるサポート予定
計画中
役割が明確に描かれている
外部依存関係の使用を許可
テストおよび分析用のライブデータがあります。
安全要件
テストが必要
必要な製品ドキュメントまたは指示の作成
モジュラー実装が必要
いくつかの開発チーム
合計

テーブルの使用方法は、誰もがすでに推測していると思いますが、念のため-前のものとまったく同じで、塗りつぶされたセルの形で少し追加されています。 つまり、このプロジェクトでは値を使用できません。 また、テーブルが不完全である可能性があることに注意してください。必要だと思われる行を追加してください。