このテキストでは、非常に急速に発展しているTNC（Transportation Network Companies）、より正確にはROD（Ride on Demand）のプロジェクトの歴史の一部を説明します。 絶対に簡単な方法であれば、タクシーサービス。 昨年の半ばに、かなり大きな西部のTNC（以下、エンタープライズ）がロシアで地域レベルのプレイヤーbpを買収しました。 その事業は中央ロシアに集中していました。 このプレーヤーは、「Taxi 666」と呼びましょう。独自の設計の製品ファミリがありました。クライアントとドライバー用のAndroidアプリケーション、およびそのようなビジネスの管理に必要なDelphiアプリケーション（ドライバーの受け入れ、統計の表示など）。 それとは別に、電話で申請を受け付けるオペレーター向けのDelphiアプリケーションについて言及する価値があります。 Taxi 666ビジネスモデルとUberなどの最も有名なTNCを区別した機能は、電話注文が約80％のシェアを占めていたが、アプリケーションを通じて注文の割合を増やす傾向がなかったことです。 それにもかかわらず、エンタープライズは、この状況を問題のある状況（多くのものが隠されている-以下を参照）としてではなく、巨大な広がりと一般的に低い（しかし急速に成長している）モバイルの普及率を持つロシアにとっての一種の競争上の優位性として認識しましたインターネット。
したがって、監査を含む 技術的、実行され、トランザクションが行われました。 最初の間違いはその瞬間になされました：
エラー番号1 。 タクシー666の創設者と彼の常勤取締役（以下、総長）が会社を辞めることになった場合、エンタープライズエージェントにはバックアップ計画がありませんでした。 彼らは代替品を探し始めませんでした。 これを実現するため、将軍はこの事実を利用して、徐々にエージェントに対するほぼ完全な制御を確立しました。 それで「しっぽが犬を振るようになりました。」
間違い＃2 。 IT監査は表面的に実施されたものであり、企業のナポレオン計画を実施してロシアに深く浸透するための2つの主要なリスクの1つを明らかにしませんでした。 このリスクの名前はFirebirdです。 すべてのDelphiアプリケーションは、約15年前にR＆Dチームのヘッド（以下「メイン爬虫類」、「GG」と呼ぶ）タクシー666によって標準として選択されたこのDBMSの使用に関連付けられていました。 主な問題は、その後コンプレックス全体を絶えず心配していましたが、FirebirdがChNN（高負荷時間）の急激なピーク負荷に対処できないために生じる作業の不安定性でした。 この問題は、bpが集中しているストアドプロシージャのデータベース内の存在に照らして解決するのが特に困難でした。 複雑なロジック。 これらの「カストディアン」の数は数百で測定されました。 監査で特定されなかった2番目の重要なリスクがありました。 以下で説明します。
すでに述べたように、タクシー666には独自のR＆D部門があり、常にGGが率いていました。 GGとその部門および他のビジネスとの関係は複雑でした。 非常に複雑なため、部門の一部のランクメンバーが会社の製品を「側に」交渉し、エンタープライズとの取引が競合他社と合意する少し前にGGが交渉した。 その結果、取引終了日からほぼ2か月後、全力でR＆Dがすべて離陸し、飛行機に乗り、遠い暖かい地域の競合他社に飛びました。 公平に言えば、このような不可抗力を予測することは困難であり、どのマトリックスにも収まらないリスクでした。 ただし、少なくとも2つの方法で最小化できます。
メソッド番号1 。 トランザクションの要件を登録して、複合体の詳細なドキュメントを作成します。 Taxi 666の文書は「一般に」という言葉からは存在せず、この事実も潜在的なリスクとはみなされませんでした。
メソッド番号2 。 R＆D部門が移行期間中維持されることを保証するために、買収された会社の売り手に対する義務を登録すること。 失敗した場合の厳しい制裁措置。 M＆Aの専門家、あなたが私を読んだら-これに注意してください。
先に進む前に、Taxi 666の買収時の企業の「ナポレオン計画」について少し話しておく必要があります。彼らは、1.5〜2年の間に存在都市の数を数十から数百に増やすことを提案しました。 野心的な計画を立てることは良いことです。 状況が突然変化した場合、そのような計画のレビュープロセスがないことは非常に悪いことです。 そして、別の間違いが犯されました。
間違い3 開発部門の突然の全損失は、状況の劇的な変化とは見なされませんでした。 ナポレオン計画は同じままでした。
それにもかかわらず、企業内で危機が発生したことを認めないことは不可能でした。この複雑な要素には、技術サポートが必要でした。 ためらうことは不可能だったので、数人の賢明な専門家が、息をtakingむほどの給料のためにモスクワから緊急に到着したエージェントに雇われました。 彼らは複合体を安定させることができました。 ちなみに、これはプロジェクト全体の数少ない正しいステップの1つでした。
正しい手順は番号1です。 最悪のシナリオの脅威の下では、コストを考慮せずに迅速に行動する必要があります。
同時に、危機のピークを過ぎた後は、「危機対策本部」を削減するために必要な措置が講じられませんでした。非常に高価な専門家を安価な専門家に交換し、部門の恒久的な頭を見つける。 そのため、次のエラーが発生しました。
間違い4 。 エンタープライズアンチクライシスITマネージャーは、タクシー666のITディレクターに任命されました。これは、いくつかの理由で悪い決断でした。 第一に、3人の幼い子供を持つ人は、「3日間で4日間」のスケジュールで数ヶ月間旅行しなければなりませんでした。 第二に、この人物は、IT分野の労働市場の現地の詳細を完全に知らなかったため、迷惑なミス（給与100 trの上級職のジュニア開発者を雇うなど）につながりました。そして一般的に非常に遅い募集プロセス。 第三に、彼の任命は将軍によって「通過」され、その結果、両方の仕事はくすぶっている紛争によってすぐにさらに複雑になりました。
イベントのさらなる発展は、以前に行われた仮定からの一連の結果として最も簡単に説明できます。
- 2番目と3番目の間違いは、チームのすべてのリソースがこの問題の解決に向けられたときに、複雑なアーキテクチャの深い処理に必要な一時停止の代わりに、チームは複雑な問題を解決するために「ブラックボックス」のままであるという事実につながりました、そして、「クラウドへ」の転送のためにそれを準備した人々（彼らは、新しい都市の遠隔開放、分散コントロールセンター、Bloody Gabneyへのアクセス不能などの進歩的なものを待っていた）。 その結果、今後6か月間、これらのタスクはいずれも定性的に解決されませんでした。
- 間違い4は、スタッフリストに「穴」を生じさせ、長い間、複合施設内の同じ「ブラックボックス」を「解読」できなかったため、作業の安定性に新たな問題が生じました。 これは将軍を怒らせ、企業の計画にますます積極的に反対するように彼を押しやった。
- 間違いNo. 1、No。2、No。4は、企業の投資家が、利益をもたらさない費用にうんざりして、最終的にナポレオン計画の崩壊につながったという事実につながりました。 このように、彼らは完全にゼネラルのイニシアチブに屈し、「以前のように」ビジネスをすることを妨げたすべての人々から、最近完成したR＆D部門だけを片付けて喜んでいた（「カットコスト」の口実の下で）。 すなわち 「クラウド」がなく、マネージャーに対する独自のビジョンがありません。 私を含め、元プロダクトマネージャー。
もちろん、この話は完全な失敗の例ではありません。 チームの他のメンバーは、おそらく最終的に複合体の複雑なアーキテクチャを理解し、作業を安定させることができるでしょう。 スマートフォン画面ではなく音声で注文することに慣れている古い世代が去るまで、ビジネスは長い間利益を上げ続けます。 同時に、地域チームの力によって最高の製品を作るという夢は実現することはありません...
誰のためにこのテキストを書きましたか？ まず、トップマネジメント向け。 大規模な財源を自由に使用できる場合は、隠れたリスクを発見し、それぞれについて事前にアクションプランを作成する必要があることを理解できる有能なマネージャーによって管理されていることを確認してください。 第二に、私のような野心的な若者たちは、自分のアイデアで世界をより良く変えることができると考えています。 新しいベンチャーに着手する前に、パートナーの目標とリソースだけでなく、マネージャーの適切性とプロフェッショナリズムも慎重に評価してください。 志を同じくする人々のチームで働く必要があります。