前の出版が成功した後、私たちは長い間、次の記事を書くように頼むことを考えました-誰がセックスについての記事で人気を主張しなければならないでしょうか。 この選択は、404Group Roman Druzyaginの技術ディレクターに委ねられました。彼は「技術的」の観点からプロジェクトの立ち上げについて話します。
「スタートアップ」について、その始まり、発展、終わりは完全に怠zyな人だけが書いたのではなく、このトピックはとても関連性があり人気があります。 プロジェクトは毎日数十回表示されたり消えたりするため、キックスタートのようなサービスを視覚的に確認できます。 ファッションに敬意を表して、私は会社の壁の中でインターネットプロジェクトを立ち上げ、成長させた長年の活動の結果として形成されたスタートアップ市場での経験と展望を共有したいと思います。 さらに、これらのプロジェクトの多くは、多くの場合非常に最初に悲しい結果をもたらしました。
このエッセイで提示された資料は、真実と呼ばれることを主張していませんが、平均的な「スタートアップ」の実際の状況とそこに生じる典型的な問題をよく反映しています。 私は技術専門職の代表なので、私の意見は「技術者」の立場から正確になります。 通常、何が正しくて間違っているのか、そしてプロジェクトのどのような結果が後につながるのでしょうか？
余談の代わりに
会社404グループとそれを設立した人々は、十数年前からWebプロジェクトに投資してきました。 ケースの70％で、アイデアは「支配エリート」の代表者によって内部で発明され、開発に着手されました。 残りの30％は、組織内で協力してくれる有望な製品に当てられます。 プロジェクトが会社の壁の中で2つの方法のどちらであるかは関係ありません。その後、ゲームは平等にプレイされます。
プロジェクトには、プロジェクトに設定された目標を完全に担当する1人または2人のマネージャーが率いるチーム（「技術者」および「マネージャー」）がいます。 その代わりに、会社はすべてのリソースをチームに提供します：主要な参加者によって合意された規模の金融投資、Cookieとコンソールを備えたオフィスアメニティ、運用サポート（金融、弁護士、秘書、HRおよびその他の専門家）、技術的能力（経験豊富なエンジニア、DBA、システム管理者） ）および会社がプロジェクトの実施のために持っているその他の能力。
プロジェクトの開発パスと成功するかどうかは、チームによって異なります。 長年の実践により、特定の製品が開発されているいくつかの典型的なシナリオを特定することができました。 経験を積んで、可能な限り、プロジェクトが「滑りやすい路線」に入ったことがわかった場合、プロジェクトのコースを修正することを学びました。 また、お金やその他のリソースが流入するだけの「ブラックホール」を故意に失うと、会社の管理下に置かない人もいます。
3つの典型的なスタートアップ開発シナリオ
最も有望なシナリオNo. 1 ：プロジェクトは結果に焦点を合わせ、 「速くて頻繁に出荷する」という哲学、またはより馴染みのある言葉で言うと「x ** kと生産」の哲学を遵守します。 このアプローチの支持者は、消費者からのフィードバックに基づいて、実用的な製品をできるだけ早く市場に投入し、積極的に開発および改善するよう努めています。 このプロジェクトでは、特定の方法論や開発方法をほとんど使用していません。 許容レベルの能力を備えた開発者が雇われ、昨日までに行うことが望ましい「即時」タスクの突然の設定に基づいて「機能」の作業が行われます。 そのようなモデルは、可能な限り実現可能です。なぜなら、それはおそらく、創業者に彼らのお金で実行される本当の成長と開発を実証する機会を提供するからです。 このシナリオの重要な問題は、製品の品質に対する注意が不十分であり、プロジェクト全体を脅かす深刻なリスクにつながる可能性があることです。
シナリオ番号2 ：プロジェクトは品質に焦点を当てています。 そのようなプロジェクトは、雇われたパフォーマーに飽き飽きしていて、何か違うことをしようとするプログラマーによって行われます。 高貴な仕事ですが、「バグ」や日常作業との絶え間ない戦いにうんざりしているため、専門家はすべてを考慮に入れて事前に予測するために、プロジェクトにとって非常に危険な決定を下します。 多くの時間は正しいアーキテクチャに費やされており、商用コンポーネント、つまりプロジェクトがどのようにお金をもたらすかを研究するのに十分な時間はありません。
Webプロジェクトでは、すべてを考慮することはほとんど不可能です。 この問題を解決するための努力の中で、チームは投資家のお金の完全な浪費に気付かず、プロジェクトは無残に死にます。 長年の経験から、創造的志向のマネージャーは、アーキテクチャの現在の状態に非常に垂直なタスクを思い付くことができるため、それを実装するには数週間から数ヶ月のリモデリングが必要になることがあります。 実際には、速度を落とすために、あまり快適でない方法に頼り、品質を犠牲にする必要があることは明らかです。
シナリオ番号3 ：プロジェクトの内容が明確ではありません。 そのようなプロジェクトは、多くの場合、最初は死産です。 それを発明した人々は、技術的および商業的アイデアの頭の中に理解できない混乱を抱えていますが、それは具体的なものには組み込まれていません。 すばらしい戦略計画が作成されており、大きな「機能リスト」が描かれています。 開発中に、このリストは自由に調整、補足、および拡張されます。 開発のペースが追いついて、チームがお金を使い果たす前に新しいアイデアを生み出すペースを追い越す場合、組み立てられた「共有」は完全に不適切であることがわかります。機能要素は一貫しておらず、相互に弱く組み合わされて単一のユーザーエクスペリエンスになります。 「使いやすさ」-ゼロ; 目に見える豊富な機会があるので、ユーザーは自分自身で何をすべきか、そしてこれがどのように彼に利益をもたらすかをまったく理解していません。 その結果、プロジェクトがフィニッシュラインに入ると、このフォームで製品を起動できないことが明らかになります。
根拠のないように、練習からいくつかの例。
- 例1：大規模な広告ネットワーク
成功する製品を作ることは正直で良い試みでしたが、同時に技術的に高品質であり、商業的成功を収めた会社の他のプロジェクトに存在する問題から解放されました。 当初、優秀なエンジニアが何人か雇われ、多くのサーバーを購入し、アーキテクチャを思いつき、6か月以上「ソーイング」し、スタートの準備をしました。
実際には、深刻なオーバーエンジニアリングが発生し、ほぼすべてのタスクで複雑な多層アーキテクチャをサポートすることがチームに義務付けられました。 このような状況での決定のペースが受け入れられず、競合他社に追いつくことができないことに気付いた瞬間、これは特に重要になりました。 その中で、「ひざまずき」で組み立てられたシステムでは、パートナーとの統合に半日かかり、わが国ではせいぜい半週間しかかかりません。 レースは敗北し、プロジェクトは終了しました。 - 例2：小さくても誇り高いソーシャルネットワーク
開始時：大きくて明るい何かをしたいという欲求。 特異性のため、収益化方法は特に示されていません。 最も勇敢で勇敢なsaに雇われて、グローバルな「機能リスト」が編集されました。 実際には、混乱と揺れ動き、「フィッシュリスト」が成長し、プロジェクトのアーキテクチャは建築家の頭の中だけに存在し、「すべてが非常に複雑」という質問に答えられます。
このような作業を6か月行った後、スタッフは解散し、親会社の専門家の通常の技術者が持ち込まれ、システムは2〜3週間で設計され、凍結した「フィッシュリスト」を使用して数か月で組み立てられました。 これらの「機能」が必要かどうかにかかわらず、誰もまだ考えていません。収集して見せることが重要です。創設者は非常に不幸です。 出力は、一貫性のない製品であり、疎結合の機能でいっぱいです。これは、ソーシャルネットワークにとって悲惨なものです。 UIの再設計、修正、編集にさらに3か月が費やされます。 プロジェクトはリリースされ、動作しますが、商業戦略が十分に開発されていないため、「排気」はゼロです。 結果：プロジェクトがフリーズします。
プロジェクトを成功させるためのレシピは何ですか？ 最初のシナリオに従って開発した製品が成功する可能性が最も高いと推測することは難しくありません。 それにもかかわらず、商業的に成功したが技術的に破綻したプロジェクトを見つけるためには、技術部門の従業員と商業担当者の両方が観察する準備ができているいくつかの妥協を受け入れる必要があります。
- 妥協点1：技術の選択と運用
まず第一に、使用するテクノロジー（プログラミング言語、DBMS、アプリケーションサーバー、Webサーバーなど）と方法論は関係ありません。 費用対効果の高いソリューションを選択する必要があります。 人気のある伝統的なもの（PHP、MySQL / PostgreSQL）は、幅広い候補者を手頃な価格で採用する可能性を提供します。 もちろん、Erlangでアプリケーションを作成することもできますが、その場合は、特別なお金を要求しない適切な専門家を探して苦しみます。
第二に、選択した技術と方法論を体系的に活用することが非常に重要です。 コードを書いて構造化し、コメントを書くためのルールとガイドラインを確立するのに怠けすぎないでください。 コードレビューのプラクティスを導入し、プログラマーがこれらの要件を体系的に満たすようにします。 プロジェクトの成功は、正しいアーキテクチャ（いつでも正しくなくなる）にあるのではなく、チームによるサポートの体系的な性質にあります。 すべてのプログラマーが統一されたスタイルでコードを書くと、他の開発者によって書かれたタスクの本質でプログラマーを理解するコストが大幅に削減され、通常、技術部門の効率が向上します。 ルールと規制を無視しないでください。それらは開発プロセスのほとんど最も重要な側面です。
そして、決して、速いペースで正確なコードを書くことができないというプログラマーの言い訳に耳を傾けないでください。 これはばかげた声明であり、怠または無能の兆候です。 文体的なデザインとコーディング文化は、優秀なプログラマーの間で筋肉の記憶のレベルに存在する訓練されたスキルです。 プログラマーを訓練し、リラックスさせます。 - 妥協点2：普遍性の拒絶
次の譲れない妥協案は、普遍的なアーキテクチャを作ることを意識的に拒否することです。 私の同僚の一人が言ったように、次のプロジェクトが「すぐにすべてを正しく行う」状態から「最初はすべて間違っていた」状態に移行する瞬間を見つけることは不可能でした。 これは避けられないことであり、あなたはこれに出くわすでしょう。 あなたのプロジェクトが次善の決定と松葉杖を持っているという事実を受け入れます。
これがいかに逆説的であるか、そのような決定を実装するためのルールを考え、それらを文書化します。 原則として、これらはビジネスにとって最も重要なロジックを実装するソリューションです。 このようなドキュメントの存在は、コード内の美しいコメントよりも価値があります。このコメントは、ツールによってクラスメソッドのドキュメントを含む美しいHTMLページに自動的に変換されます。 誰もそれらを読むことはありません。 そして、集中的に開発しているプロジェクトでは、100％のドキュメントを維持することはほとんど不可能なので、プログラマーの努力をすぐに指示し、本当にそれを必要とする問題を説明するよう要求します。 - 妥協＃3：セキュリティの懸念
実践によると、最も経験豊富なプログラマーでさえ、Web製品のセキュリティについて非常に表面的なアイデアを持っていることがよくあります。 攻撃の典型的なベクトルは何ですか？また、攻撃者はどのように攻撃を利用できますか それらから自分を守る方法は？ 情報の損失や盗難を避けるためにデータベースをどのように使用するのですか？ 開発者はこれらの質問に対する答えを知らないか、またはそれらに十分な注意を払わない場合があります。なぜなら、プログラマーにとって行われている作業の最も重要な側面は彼のコードだからです。
実際、インターネットプロジェクトの最も重要なリソースはデータです。 コードはシステムの中核であり、商業担当者は技術的能力が限られており、他の理由で頭痛の種であるため、技術部門はそれらについて考えません。 データの重要性の理解と認識は、リソースが競合他社によって攻撃されたときに現れます。これは、まだ「バックアップ」していない管理者についての悲しい冗談のようです。
これをチーム全体に伝え、安全なコードを書くために必要なプラクティスを開発し、システムサポートを監視し、正しいバックアップ手順とデータリカバリ検証を確立するチームに少なくとも1人の人がいることを確認します（非常に望ましい、技術リーダーの地位を占める）。 私は、非常に些細な脆弱性を使用して「クラック」する成功したプロジェクトを繰り返し観察しました。 完全に異なる製品の意図的な監査は、同じ問題を明らかにしました：入力パラメータのフィルタリングの欠如、画像をアップロードするための保護されていないフォームなど。これらはすべて、セキュリティの問題に注意を払うだけで防止できる一般的な愚かなものです。
データはコードよりも重要です。 新しいコードを書くことはできますが、失われたデータは簡単に収集できます。
まとめると
この記事に技術的に成功した作業プロジェクトの例がないのはなぜですか？ そのような性質は非常にまれです。 製品が本当に機能し、利益を上げる場合、常に問題が発生します：多数の緊急タスク、それらを解決するための作業手不足、曲がったプログラムモジュール、すべてをゼロから書き直そうとするプログラマーの強い欲求、数か月待っていた毎日のバグ、サービス拒否、商業的性質の危機であり、半日で迅速かつ迅速なファイルカットが必要です。 このすべてが、チームが毎日すくい上げ、同時になんとかして製品の開発を管理する必要があります。