人々が必要とするプロジェクトを行う方法、またはスタートアップが離陸しない理由

今日、実用的な例を用いて、スタートアップの開発を含む、プロジェクト管理の2つの神話を分析します。
1.スタートアップを成功させるための最善かつ唯一の方法は、日常生活で作成者に馴染みのある問題を解決することです。
2.ビジネスの自律性があるという事実。プロジェクトが特定のポイントに到達し、それ以外のことは何もできない場合、それは単にマシンにお金をもたらすだけです。



また、時間通りにタスクを実行したり、アイドルプロジェクトを行ったり、Habrで時間を過ごしたりする「悪いプログラマー」の神話に触れ、問題の大部分は開発をリードする人に起因することを発見します。

1.ユーザーの目を通してプロジェクトを見ることがどれほど重要か

最初の神話から始めましょう。 私はこの声明に異議を唱えるつもりはありませんが、それを拡大したいと思います。 スタートアップを成功させるための最善かつ唯一の方法は、作成者がニーズを十分に理解しているユーザーのタスクを解決するものを作成することであると言えます。

つまり、これらの分野のそれぞれでスタートアップを成功させるために、一生を金融、化学、ペットに費やす必要はありません。 選択した分野に没頭し、エンドユーザーの目を通してプロジェクトを見ることができる必要があります。

このアプローチは、アイデアを開始するためのはるかに幅広い選択肢を提供します。 所有する必要があるのはロジックのみで、ポタペンコが言うように、8年生レベルでは、条件演算子とループという2つの要素があるアルゴリズムを書くことができます。

ところで、セルゲイ・ガリツキーは、論理の重要性についても語っています（誰も知らない-億万長者がMagnit小売ネットワークをゼロから作成しました（！））Business Secretsプログラムでは、このトピックについて触れます。 一般に、私は人々を論理学者と直観に分割しなかったフリッツ・モルゲンの声明が好きであることに注意します。

実際、正しいアプローチはどこでも同じであり、同じドミトリー・ポタペンコは、買い手が何を必要とし、どの製品を最初に選ぶかを感じようとして、常に消費者を非常に慎重に研究すると言います。


時間内に考えるだけでエラーを修正できます

これが実用的な例です。 彼らは、エラーが早く検出されると、それを修正するコストが低くなり、プロトタイプインターフェイスの修正と1,000コピーのリリースの差は1000倍に達する可能性があると言います（絶対的に数百万ドル）。 しかし、彼らがしばしば忘れているのは、 エラーがプロトタイピング（インターフェース設計）段階だけでなく、思考段階でも検出できることです。

Yandexを設計しているとしましょう。 あなたはプログラマであり、プログラマをリードしています。 次の2週間の計画が議論されています。 プログラマーは、クールな高度な検索、クエリ言語、AND / ORロジック、括弧、アスタリスクなどを使用するというアイデアに感染しています。 そして、彼らは2週間でメカニズムを評価します。 プロジェクトをプログラマーとして見ると、同僚の議論に喜んで同意し、開発に参加できることを嬉しく思います。

ただし、ソリティア以上にコンピューターを石化しない知人のブロンドの女の子の靴を履いている自分を想像すると、決定は異なります。 他の検索エンジン、特に外国の検索エンジンを数日間使用して、金髪の目で結果を見て、単純で愚かなクエリを入力すると、特別な体験ができます。 実際に必要な機能の種類を伝える経験。 あなたが最初に気づくであろうことは、ブルジョアシステムは原則としてロシアの形態を理解しないということです。 2つ目-目的の結果が最初の結果になったとき、何が好きで、目的のサイトの5ページ目に移動する必要があるときに腹が立ちます。 また、高度な検索を入力したことがないことも理解できます。開くと、大きなページが読み込まれ、10個の要素を持つフォームが表示され、必死に「戻る」を押すと、友達が怖くなります。


彼女は再び高度な検索をしているようです。

あなたがそれを信じ始めたときに演技から何かがあります。 あなたは金髪であり、彼女の役割に没頭していること。 ダイビングが上手くいけば行くほど、プロジェクトでの動作をより正確に確認し、特定の問題を解決するときに自分自身を観察するだけでそのアクションを予測できるようになります。

繰り返しの計画に戻りましょう。 これで、高度な検索に2週間の時間を費やすことになります。 直接の金銭的条件で-10 * N * S（i）、ここでNはプログラマーの数、S（i）は就業日ごとの給与です。 たとえば、1日100ドル相当の3人のプログラマーの場合、これは10x3x100 = 3000ドル、つまり約100,000ルーブルになります。 そして、これらの2週間にわたって競争上の優位性をもたらす競合他社がまだ存在する場合、損失は不釣り合いに大きくなります。

同時に、検索エンジンにとって何が重要かをすでに知っています。 まず、結果の関連性-ユーザーの要求に近いほど良い。 第二に、可能な限り正確にリクエストを理解すること、そしてロシアの形態、典型的なタイプミスなど。

したがって、ユーザーの皮膚に没頭すると、次のことが可能になります。
1.現在の重要なタスクの正確な理解
2.その結果、意図的なレベルでも不要な機能を遮断する機能-ユーザーのタスクを解決しない場合、安全に遮断することができます。

同時に、私たちはあなたのユーザーを正確に特定することを検討していません-これは記事の範囲外です。そして、私のお気に入りのポタペンコは同じことを言っています-「あなたの顧客は誰か」という質問の90％ 50」、これは完全にでたらめです-つまり、買い手は正確に定義されていません。

ほとんどのスタートアップは、誰も必要としない機能を作成するだけで、お金と時間を無駄にするだけだからだ。 同時に、本当に必要な機能を作成する少数の人々が離陸します。 多くの場合、これは最初の原則の特定のケースの適用が原因で発生します-人々は単純に手探りしていることを行い、知っている問題を解決します。

2.プログラマーと正しく通信する方法

締め切りを遅らせたり、不必要なタスクを実行したり、アイドルプロジェクトを実行したりする、いわゆる悪いプログラマーについて。 これは単なる神話であると確信しています。 ほとんどの場合、プログラマーは、自分のビジネスに取り組む場合、非常に頭が良く、責任を持ち、常に自分がしていることに関与し、魂を持ってタスクに取り組み、常に時間どおりに努力します。

しかし、なぜ私たちはどこでもこれらの告発を聞くのですか？ はい、ロシアにはほんの数人の優秀なマネージャーがいるわけではないので、一般的にはそうではないと考えてください。 つまり、プログラマーの仕事はプロジェクトマネージャーに依存します。 すべての問題を順番に分析します。

1つ目は、プログラマーが興味を持たないことです。 これは、個人が自分のビジネスに従事していない場合（ウェブマスターから来て、お金のために愚かな仕事をしているなど）である可能性があり、通常、支払いを行っても気にしません。 しかし、これはまれです。 2つ目は、マネージャーがプログラマーとの時間を無駄にせず、プロジェクトで何が面白いか、何が行われているかを彼に見せないことです。 ユーザーからのフィードバックを提供しません。 多くの場合、彼は単にTKを与えて言う-私が言ったように、それがすべてです。 同時に、プログラマーがユーザーの観点からプロジェクトを説明し、何がおいしくて重要なことをしているのかを示し、感謝を共有する場合-ICQからログを送信するだけでも、「なんてクールなセクション」だったのか-プログラマーは彼の活動を感じ始めますプロジェクトでの役割、およびはるかによく機能します。 あなたはただ真実を共有し、関与の重要性を理解する必要があります。

2つ目はアイドル機能です。 同じこと-リーダーがプログラマーに説明し、ユーザーの観点から見るように彼に教え、重要なポイントを強調し、ロジックに伝えた場合-プログラマー自身がすべてがどのように機能するかをチェックし、90％のケースではテストする必要はありません McConnellによると、やる気のあるプログラマーとやる気のないプログラマーは、速度が最大10倍異なります。


他のプロジェクト参加者に情報を正確に伝えることの重要性を過小評価してはなりません。

別のポイントは問題の声明です。 プロジェクトマネージャーにタスクをポイントごとに設定することを教えているので、プログラマーはタスクを簡単に理解できます。 基準は1つしかありません。タスクを読んだ後、プログラマーに質問はありません。 一般的に。 同時に、問題文が少なくとも2つのポイント-抽象化と実装（ここでも依存関係反転規則の原則）に分割されるように努めています。 たとえば、フィルター付きのテーブルを作成するタスクがあり、レイアウトが指定されています。 最初に、視覚的な部分を参照せずに、作業のロジックを記述する必要があります。 言葉のアルゴリズム、入力と出力、境界値を考慮し、ライブの戦闘データで動作するアルゴリズムの例を示します（つまり、入力が何であり、出力がどうあるべきか）。 次に、レイアウト仕様、どの要素がどの機能を実行し、どの要素が他の要素とどのように関連しているかを説明します。

実際、プログラマーの言語でタスクを説明する必要があり、技術的な言語に近いほど、簡単になります。 理想的なオプションはUMLダイアグラム（シーケンスダイアグラムなど）で、手で簡単に描いてすばやくスキャンできます（スキャナーは1週間で100ドルの費用がかかり、月に何時間も話せません-情報の90％が視覚的に送信され、約9-10％しか送信されません-耳で）。

同時に、アルゴリズムによって、私はすでに実装を理解していませんが、それがどのように機能するかを理解しています。 実装オプションはプログラマーが選択できます。

さらに、非現実的な用語。 また、思考のレベルで簡単に解決できます。 タスクを設定するアイデアを得る前に、自分自身に尋ね、いくつかの質問をする必要があります。
1.これはできませんか？ このタスクの熟考、詳細化をどの程度延期できますか（詳細化とは、プログラマーにとって思考を正確な声明に変えることを意味します）。
2.これをどのように簡単にできますか？
3.問題を解決するための代替オプションは何ですか（管理者まで）。

選択した場合は、プログラマーと協力する必要があります。 まず、タスクを音声で話し合い、時間を尋ねます。 フィルター付きのテーブルの場合、23時間聞いたことがあるのに、4時間タスクを実行する必要があるとします。 国、リゾート、日付ごとのドロップダウンリストの3つのフィルターがあり、テーブルにはエントリが表示されます。 プログラマーにタスクの段階を描き、考えさせるのに30分を与え、リストを取得するよう依頼してください。
-リゾートの辞書、管理者パネルを備えた基本レベルの国-8時間
-日付選択用カレンダー-1時間
-テーブルでの並べ替え-4時間
-データベースからの選択とテーブルからの出力-2時間
-ページング-4時間
-日付、国、リゾートでフィルター-4時間

理解できない点で主要な質問をし、本当に重要な機能を思い出し、さらにタスクがライブデータでどのように見えるか疑問に思う場合、次の手順を実行します。
1. 100を超えるエントリがないため、ページングは​​不要です。
2.フィルターとレコードがほとんどないため、並べ替え（プログラマー自身が簡単にリストに含める）は必要ありません。
3.本当に2つの国があるため、10未満のリゾートがあります。ほとんどの場合、昨日録画を見る必要があります。たとえば、カレンダーなしでハードコード（コード内の配列）の国とリゾートと昨日で直接開始する必要があります
4.プログラマーが平均して100％楽観的であることを知って、最も重要なことは、単純なテーブルの形でデータベースからデータを出力することであり、裸のHTMLで5分間スケッチできる（時間を節約し、後でレイアウトを固定する）こと、そして2時間与えます。 その結果、4時間で彼はあなたが必要とすることをするでしょう。
5.リファクタリングの時間が与えられることを確認します。

このようにして、各タスクで、必要なものを80〜90％取得します。 次に、別のプログラマーと別のタスクに切り替えて、現在のプログラマーとリファクタリングさせます。 ここですべてが得られます：最初に、ライブデータで非常に迅速にいくつかの反復を行い、システムの最終的な外観とロジック、およびプログラマを取得します-彼はあなたがそれをやり直さなければならないことを長い間書かないでしょう（結局、あなたは正確にマイクロイテレーションをしていません適切な方法を理解してください）、そして間抜けなコード（時にはクイックオプションを押して利点を示す必要があります）を使用して、数回の反復を行い、タスクの非常に正確なバージョンを取得し、リファクタリングできます。すべてがどのように機能するかについて既に正確に理解しています。

時間の経過とともに、プログラマーは賢くなり、より経験豊富になり、タスクの段階（新しい機能の開発またはプロジェクトの開始）に応じて、戦略を選択します。たわごとコードとマイクロイテレーション+リファクタリングをすばやく実行するか、要件と正確な実装をすぐに明確にします（どこにも行かない場合は、 dopilkaプロジェクト）

もちろん、上記のすべてはマイクロ管理ですが、プロジェクトの初期段階で毎日リリースし、80〜90％の正確な機能を実現できます。 最初の段階で行動するのに適したアプローチを知っている場合は、コメントに記述してください。

3.プロジェクトを常に開発する必要がある理由

今、2番目の神話について。 事実は、あらゆる生命体が動き、進化するということです。 これは、どのプロジェクトにも競合他社がいることを意味します。 また、プロジェクトをそのままにしておくと、あるプロジェクトに参加している間、他のプロジェクトが前進します。 含む-および機能を使用し始めるユーザーは、あなたが意図したものではありません。 時間内に介入しないと、すべてをやり直す必要があります。


時々、プロジェクトのズボンのサイズがなくなった

例-Mantisに基づいたプロジェクト管理システムがあるとします。 メインプロジェクトとサブプロジェクトだけがあります。 あなたはかつてそのような階層を構築し、それを変更しませんでした。 年が経ちます。 プロジェクトの数が大幅に増加すると、人々はサブプロジェクトに追加し始め、他のエンティティは既に-開発が進行している新しいセクションを追加します。 おそらく、プロジェクトとして、「クライアントサイト」などのカテゴリが追加されます。 そして最後に、問題に到達すると、カテゴリ、プロジェクト、セクション、クライアントとの通信、特定の部門との通信など、単純なツリーの構造に多くのエンティティがあることがわかります。 つまり、構造は変更されませんでしたが、プロジェクトの基盤である生きたデータは進化し、そのフレームワークを超えました。

そのため、常にライブデータのすべてをチェックし、プロジェクトの進行を常に監視し、変化の方向を予測し、構造とロジックを現在の状態にスケーリング/リドゥすることが非常に重要です。

まとめると

1.最も重要なことは、正しく考えることです。 ユーザーの目を通してプロジェクトを見て、それによって本当に重要なタスク、およびこれらのタスクをどのように行う必要があるかを理解できるようにします。 スタートアップは、誰も必要としない間違った機能を作り、お金と時間を失うため、離陸しません。
2.プロジェクトの問題の90％は、不適切な管理によるエラーです。
3.適切な動機付け、プログラマーの関与、精巧なタスク設定、および特定の方法論に従ったプログラマーとの緊密な作業により、プログラマーにリファクタリングするための時間を割り当てながら、最大10倍まで加速し、必要な機能の80-90％を適時に実行できます
4.すべてのプロジェクトは、生き残るために開発する必要があります。

幸運を祈って、コメントであなたの経験を共有することを提案します。

私のLJのクロスポスト