定性的、迅速、安価-分割して征服する

プロジェクトを迅速に立ち上げる方法に関する多くの記事がすでに書かれています。 プロジェクトの本質を示す最も単純なバージョンを作成して実行します-経験のある多くの人が言ってください。 そして、私はそれに完全に同意します。 ただし、すべてのプロジェクトをこのような動的な形式で実行できるわけではありません。 そのような場合についての私の考えをいくつか述べたいと思います。



以下に書かれているものはすべて、当初投資家を探していないプロジェクトを指し、その進路はプレゼンテーションやビジネスプランではなく、ドメインと2人の開発者の購入から始まります。 同様に、これは計画とビジネス分析の完全な欠如を意味するものではありません。





だから、あなたはアイデアを持っています、そのような良い考え、思慮深く、有望です。 しかし、あなたはそれがどのように収入を生み出すかを正確に知りません。 有料のサブスクリプションを作成するか、サービスを「ピース単位で」販売するか、登録のために1回限りの支払いを行うことができます。 収益化モデルはそれほど多くないように思われますが、一部は有効です。



そして、ここで彼女はすぐに自分自身を感じさせる間違いです。 さらに、このエラーはまったく存在しないように見える場合があります-ユーザーは購入しますが、どういうわけか十分ではなく、1か月間サインアップしただけです。 たぶん製品は悪いですか？ ほとんどありません。

問題は、プロジェクトの開始時の誤った意見です。主なことは、マーケティング担当者がそれを販売することです。 最初に販売する予定の製品またはサービスを作成する場合は、次のことを考慮する必要があります。

1. 販売できる最小の機能は何ですか？
2. 品質を損なうことなく、これから最も迅速にできることは何ですか？
3. これにどれくらいかかりますか？

これらの質問に答えるのは非常に簡単です。1〜2個の機能を評価することは、最終的に複合施設内のサービス全体の費用を見積もるよりもはるかに簡単だからです。 第二に、できるだけ早く市場に参入する必要があります。 将来的にサービスを開発する最も効果的な方法を紹介できるのは彼だけです。

簡単に思えますが、グローバルな技術的課題、開発計画、完璧なプロジェクトを作りたいという願望を背景に忘れることはめったにありません。

そして、これを行うことは、最初から必要ではありません。 大量の機能があるとすぐに、ユーザーに提供し、そのようなミニサービスを実行できるものを選択する必要があります。



きっとあなたの多くはこう思うだろう：「ここでまた松葉杖で囲いなさい」。 はい、これには、あまり美しくない決定が伴う場合があります。 ただし、プロジェクトのこのような小さな部分を起動することにより、太った納期の問題からあなたを救います。 開発が4〜5か月間既に進行しているが、必要なものをロールアウトするために、さらに3。そして、これを念頭に置いてアーキテクチャを設計する場合、開発者は実際に悲しむことはありません。



上記のすべては、基本的に、できるだけ早く開始する必要があるという考えを明らかにしています。 前の問題と同様の次の問題は、より技術的にのみ表現されています。

結果として得たいものがわかりません。

とても奇妙です、どうですか？ しかし、それは起こります。 あなたのアイデアは非常に具体的ですが、あなたの頭でそれが発展するとすぐに、多くの枝が現れ、それらはすべて非常にクールで便利に見えます。 さらに、本質はほとんど変わっていません。 そして、一方の方向がより高い優先度を取得し、もう一方の方向がより小さな優先度を取得する期間があります。 この混乱の結果、長い間修正される未加工の機能が大量に手に入り、販売するのは残念です。



解決策も大部分が一般的です-機能するものを取り、販売しようとします。 少なくとも少し行けば-開発し、そうでなければ-開発を停止します。

おそらく非常に複雑な状況が判明します。 プロジェクトの一部は基本的なものであり、適切に実行する必要があるため、放棄できない部分がある場合があります。 そして、ここでは、既製の部品の山から組み立てられたミニサービスの立ち上げにより、品質を犠牲にすることなく、重要なものを急いで仕上げることなく快適に時間を過ごすことができます。



同じ方法をプロジェクトマネージャーが使用して、状況を悪化させたり、開発者に圧力をかけたりしないようにすることができます。

1. すべてのシステム機能のリストを定義する
2. 売れるものを選ぶ
3. 既製のものか、最小限の労力で完了します
4. それらを完了して実行します

したがって、すべての締め切りが終わり、プロジェクトが理解できない状態にある場合、危機から抜け出すことが可能です。 明らかに、そのような特別なリリースは一週間以上かかるべきではありません。 しかし、今週はすべての部隊を切り替えてから、静かに主要な開発を続ける必要があります。



そして私が言いたい最後の問題

タイミングとイノベーション

プロジェクトが標準ソリューションのみで構成されておらず、何らかの調査が含まれている場合、多くの場合、正確な日付を評価できず、割り当てられた日付は中断されます。 これは、チームが以前に遭遇したことのない、または部分的にしか対処していない問題を解決するのにかかる正確な時間を判断することができないためです。

この点を考慮することは非常に重要です。さもないと、「いつ？」「なぜ？」という質問で迷子になります。



残念ながら、この問題を解決するための何らかの体系的なアプローチを見つけることはまだ可能ではありません。 また、プロジェクトでは次の方法論を使用しています。



短い期間、たとえば1日が設定されます。 これらのギャップは進捗を測定します。 それはすべて、「問題を解決する方法」という質問から始まり、そのような「方法」の連鎖が構築されます。 遅かれ早かれ、最終決定に至ります。 ソリューションを見つける方法に沿って、新しいタスクの時間を設定します。 しかし、グローバルな期限はありません。

など、どれだけの労力が必要になるかが明確に決まるまで。 もちろん、進行が停止した場合は、解決および理解されたすべての分析が行われます。 停滞の理由と研究を継続するためのオプションが特定されています。



多分少し面倒だったので、簡単な結果を要約します。

アイデアがあり、それを実装することに決めた場合、設計、設計、プログラミングに飛び込む前に、次の質問について考えてください。



収益化

あなたは売ろうとしています。 これは主な目標ではないかもしれませんが、それでも重要なコンポーネントです。 したがって、1か月で何を販売できるかを正確に決定してください。 また、どの形式で提示するかを考えてください。 このような実験は、可能な限り迅速に行うことが最善です。 間違いなく時間を節約できます。



理想的なVSリリース

高品質の製品を開発してください。そうしないと、プロジェクトの喜びを感じることができません。 ただし、効果のない、または見苦しいソリューションを備えた小規模なリリースでは、メイン製品の開発にかなりの時間を費やすことができるという事実を受け入れます。

すぐにすべてを行うことはできません。プロセスにはさまざまな性質の多くの調整があります。 時間がかかり、その結果を提供したい場合は、高い確率でそれを満たすことはできません。 リファクタリングや何かを書き直したいという欲求に夢中になるからです。 とにかく起こります。 おそらくあらゆるプロジェクトの自然な進化。 しかし、これを理解し、定期的に「ダーティ」リリースを行う場合、主な開発は、技術的負債の継続的な返還や期限の行き詰まりに陥るようなものではありません。



新しい問題を解決するための時間の推定

タスクのプール全体を、評価および調査が容易な標準タスクに分割します。 これにより、多くの管理上の問題が解消されます。 期限はよりよく尊重され、開発者は興味深い問題を解決する機会を与えられ、結果に急いでいないことに満足します。



これはすべて個人的な経験の結果であり、スタートアップに関する本に書かれている多くのことを反映しています。 しかし、実践が示しているように、それらの重要性を理解するために感じる必要がある瞬間があります。 また、上記では、プロジェクトを開始する場所だけでなく、説明した問題がすでに明らかになっている場合にプロジェクトを保存する方法についても説明しています。