iCityは誰も気にしない仮想都市です。 死後の内部スタートアップ

みなさんこんにちは。 記事はスタートアップに関するものです。 しかし、眉をひそめることを急がないでください。 この記事は、親会社内の内部スタートアップについてのものです。 これらは、スピンオフと呼ばれることもあります。 名前が示すように、私は内部スタートアップを作成しようとする際にミスを犯した後、どれだけ熱心にミスを犯したかについて読むことをお勧めします。 私は誰かがそのようなエラーに対して警告されることを本当に望んでいます。

背景

いつもたくさんのアイデアがありました。 私はどこで誰によって働きませんか。 私は1990年にまだ学校にいる間にコードの最初の行を書きました。 1996年のどこかで、Yandex.Market（後に判明したように）、後にバリエーター（自動車のギアボックス用のコーン型ギアなど）のようなものを思い付きました。その後、より実用的なものがすでにありました。 -それらを別々に処分します。 要件を詳細に書き留めて、要件を注意深く書き留めました（残念ながら、ビジネスアナリストとして多くの実践がありました）。 彼はさらに特許を取得しました。 今、私は理由がわかりません:)。 2011年までに、私はIT会社のアナリスト、プログラマー、ITプロジェクトマネージャー、商業ディレクターとしてだけでなく、大規模な建設会社の開発ディレクターとして、2つのショッピングセンターを建設し、輸送物流の分野で会社のゼネラルディレクターになりました。 一般的に、経験はワゴンです。 しかし、私はITとの接触を失ったことはありません。 それどころか-すべての業界で、ITを活用して開発に強力な弾みをつけることがどのように可能になるかがわかります。 その結果、2011年にITに戻るように申し出られ、堅実な予算（1​​,000万ルーブル強）、チーム編成でのカルテブランシュを提供しました。 ニュアンスは、トピックに関する興味深い制限でした-「Information City」という名前に適合し、QRコードが積極的に使用される製品を作成すること。 まあ、もちろん、結果としてそれ自体にお金を払い、利益を上げ始めるでしょう。

理想的な条件！？

私になされた提案は、多くのハブロフスク市民にとって究極の夢であることを認めなければなりません-良い予算、分け前、カルトブランシュ、オフィス、チームを選ぶ自由-あなたはそれだけを夢見ることができました！ その瞬間、私は同じことを考え、袖をまくり、製品の概念を書き、その実装を検討しました。

仮想都市の本質

その結果、次のコンセプトが生まれました。 次はドキュメントからの引用です：



アイデアは、ユーザーが自分の裁量で、関心のある主題領域のイメージを形成し、独自のツールを使用してコミュニティコミュニティを整理し、コミュニティメンバーの権限を構築し、自分の人生に積極的に参加できる環境を提供することです。



私たちの環境は、ウィキペディア、ソーシャルネットワーク、モバイルテクノロジーの最高の品質を組み合わせます。 重要な原則は、ソーシャルネットワークの原則に基づいて構築された社会環境と、Wikipediaの原則に基づいて構築された主題インフラストラクチャとの統合です。



このような統合は、モバイルテクノロジーの使用、「拡張現実」の原理、構造評価、およびゲーム要素と相まって、高い確率で成功をもたらすはずです。



プロトタイプを作成するために、アイデアは都市の生活に最も重要な側面、「拡張現実」の要素、行政当局との効果的なコミュニケーションの組織とともに都市の生活に投影されます。



複雑な概念、収益化の不明瞭さ、証明の欠如、基本的な前提さえも、今では考えていません。 「フィールドから」の情報からは、サマラのブロガーの関心のみがありました。サマラのブロガーは、何度か収集し、あなたが故郷で何でもすることができるプラットフォームとしてプロジェクトに強い関心を持っていました。当局と彼らとの戦い。

開始-プラットフォームの選択

大企業で働いていたにもかかわらず、チームは明らかな理由でゼロから採用する必要がありました。 私の論理では、プロジェクトのテクニカルリードは、実装するプラットフォームを決定することでした。他のプラットフォームよりも適切なプラットフォームを選択する必要がありました。 それから、どのプラットフォームを選択するかは問題ではないように思えました-手が適切な場所から成長すれば、適切な品質の結果が適切なタイミングで得られます。 なんて間違ったんだ！ はい。彼らは、Javaの優れた実績と経験を持つ、非常に有能で責任あるスペシャリストでした。 経験が主に産業であり、ウェブ開発ではないという事実は、私にとって取るに足りないように思えました-人が賢明で適切であるため+チームで必要な経験を持つ専門家を募集します。



その結果、パイロット用のCMFを選択する代わりに、迅速にプロトタイプを作成してテストすることができましたが、成功への自信に盲目になって、すぐにJavaで大規模なシステムを構築し始めました。 このプロセスは、疑いもなく産業発展を連想させます。 チームの生産性と開発の品質が望まれず、予定された期限に間に合いたいと考えていたため、チームは着実に成長しており、2011年末までに3人のモバイル開発者を含む8人がすでに存在していました（プラットフォーム）。

失敗の最初の兆候

私たちの目の前でコンセプトが変わり、開発者の側から時々、この狂気を終わらせ、コンセプトを単純化する提案がありました。 そもそも、私たちが何を、誰のために行っているのかを理解しておくといいでしょう。 しかし、それはそれほど簡単ではありませんでした。 その結果、ほとんどの場合、自己満足の目的のために、アイデアが生まれました-すべての標準的なスタートアップは3ペニーのようにシンプルで、1つの問題だけを解決します。 私たちのものはすぐにたくさんの問題を解決しますが、ひとつひとつではなくすべて一緒に解決します。 仮想都市は、サンドボックスではなく都市でなければなりません。 したがって、製品を見続ける必要があります。

しかし、投資家[親会社の経営者でもある]はどうでしょうか。

私たちは毎月会合を開き、行われた作業について熱心に報告し、中間結果を示しました。 選ばれたアプローチの正確性に何らかの形で疑問を投げかけるすべての試みに対して、私たちは頭を上げずに、外部から概念を確認することなく1年間、製品を作ります-私はdigりで却下しました。 私が議論として引用した主な動機-私たちは完全に準備ができている場合にのみユーザーにとって価値がある複雑な製品を作成しています-さもなければ、失敗します。 悲しいかな、私の圧力と説得力は毎月彼らの仕事をしました。 しかし、給与（場合によってはボーナス）が定期的に支払われ、金額はどんどん減っていきました。

できた！

それにもかかわらず、2012年4月に、プロジェクトの最初の（最終的に-そして最新の）バージョンを公開しました。 フレンドリーなブロガーが、フレンドリーで非常にフレンドリーな方法でインターネットについて語ったこと。 キャンペーン全体が実施され、その結果は、Yandex「iCity-we made」と入力することで確認できます。 私たちは熱狂的で、仮想都市に貢献し、オブジェクトの説明を開始し、写真やニュースをアップロードし、他の人のニュースにコメントを付け、評価を獲得するなど、膨大な数の人々の流入による巨大な負荷に耐える用意がありました。 ご想像のとおり、控えめに言っても私たちの期待は実現しませんでした。 パイロットとして、私たちはサマラでコンセプトをテストし、製品を完成させてから、それをロシア全土に公開しました。

QRコード

ここで、少し余談をする必要があります。 プロジェクトの重要な場所の1つはQRコードで占められていました。 当時、このツールはまだそれほど広く知られていなかったので、サマラをロシア（そしておそらく世界）で最初の都市にしたかったのです。各都市にはQRコードがあり、そこからウィキのようなリンクができます。 iCityページでは、オブジェクト自体に関する包括的な情報を取得し、コメント、レビュー、写真をアップロードできます。 私はまだこの概念を良いものと考えており、誰もそのようなサービスに近づいていません。 その結果、住所プレートと一緒にQRコードの使用を管理する規定について、サマラ市の行政に同意することになりました。 適切な決議を準備し、責任者にプレゼンテーションを行いました。 一般に、サマラでは、市長の決議の私たちのバージョンの移転から2年半後、住所空間および住宅および共同サービスでのQRコードの配置を支配する規制はまだありません。



プロジェクトを立ち上げ、仲間のブロガーが私たちのために良いPRを行った後、ユーザーベースを積極的に増やし、コンテンツの量を増やす必要がありました。 そしてここでも、サマラの自治体を通過してQRコードの提供に成功することを非常に期待していました。 残念ながら、QRコードは既に少し上に言及されており、プロモーションに使用しようとした他のツールでは、望ましい効果が得られませんでした。

ピボット

リソースの作業の最初の2か月の結果によると、リソースは、特定の都市の欠点に都市行政の注意を引きたい人々の中で最も需要が高いことが判明しました-彼らは地図に信号を残し、写真を提供しました そして、彼らはそれに応じて、行政による実際の行動があると予想した。 私たちは、システムのこの部分をサマラ政権の同様のシステムと統合するよう努めましたが、この作業は非常にゆっくりと進行し、ユーザーは待つことに飽きてしまいました。 しかし、これは、iCityに基づいて、別の大規模な自治体で市民の訴えに取り組むためのシステムを作成するよう提案されたという事実につながりました。 予算が解散しているため、提案は非常にタイムリーであり、iCityから余分なものをすべて削除し、行政当局と市民および行政当局と市民とのコミュニケーションに責任があるもののみを残そうと努力しました。 その結果、トリアッティのオープンシティシステムが完成しました。 もちろん、iCityにはほとんど何も残っていませんでした。Togliattiの同僚の多くの希望を考慮し、自治体の要件に合わせて製品を調整しました。 他の地域からの関心がありました。



私の代わりに何をしますか？ ええ、そうです。チームの方向をすぐに変え、ロシア連邦の都市や町へのプレゼンテーションに最も早く行くために、私は良い製品を提供し、それをすべての人に販売し紹介しています。 明らかなピボット！ しかし、ここで私は別の間違いを犯しました-それはiCityに費やされた努力であり、リソースが遅く、時には不安定であるためにユーザーが私たちに行かないと信じて急いで終了しました。

市場に勝つ

はい このイベントのためにモスクワに行った後、すべてが逆さまになりました。 それは一種の冷静な魂でした。 帰国後、私は急いでブランカとドーフを読みました。 2011年にこれをどのように行う必要があるでしょうか。 私のすべての間違いが非常に明白になったので、あまりにも非効率的な予算と、あなたを追いかけ、壊れた谷に来る大きなリスクを抱えている人々にとっては耐えられないほど迷惑になりました。



チームのキーパーソンを集めて、新しいコンセプトの本質を伝えました（明確なセグメンテーション-スポーツの街、ゲストの街、エンターテイメントの街、開かれた街など）。 iCityの開発を現在の形で凍結し、新しいコンセプトに従って新しいポータルの1つに焦点を合わせることにしました。 メインページのデザインも作成しました。 しかし、1つのポータルでも十分なお金がないことが明らかになりました。



その結果、作成されたチーム（既に協力し、ミス、成功、失敗の経験があった）を維持するために、別のプロジェクトに外部投資が集まりました。 しかし、これはまったく異なる話です。

今何

3つのモバイルアプリケーションでも、潜在的な顧客に私たちがこの時代に何をしたかを見せるために、脆弱なコンピューターでパブリックドメインを回転させています。 そして、ほとんどの部分で既に他のプロジェクト（親会社内とそれ以外の両方）に散在している私たちのチームにとって、iCityはプロジェクトを行うべきでない方法の良い例として記憶に残ります。

私たちは血で書く：

1. すぐに大きな予算が悪いです。 これにより、真実が考えられるよりもずっと長く見えないようにすることができます。 大きな予算を正当化できる唯一のことは、知識が豊富で権威ある（圧迫されたり、専門家でない立場を確信することのできない）メンターの存在です。 ありませんでした
2. 開発プラットフォームは非常に重要です。 不適切に選択されたプラットフォームは、確実に期限、予算の過大評価、または容認できない品質のいずれかにつながります。 そして、ほとんどの場合、それはすぐにすべてにつながり、チームの深刻な動機付けの源となります。
3. プロジェクトチームが他のスタッフと同じオフィスにいることは悲惨です。 安全なオフィス環境で従業員としてスタートアップを作ることは非常に困難です。 とにかく給料が支払われることを従業員が知っている場合、6歳以降の長所は何ですか？ 周りには、オフィスで時々議論される他のプロジェクトがたくさんあります。 極端な場合、別のプロジェクトに移行します。 その結果、効率とエンゲージメントが低下します。
4. チームのメンバーが従業員のように感じず、1つの大きなことをするチームのメンバーのように感じるようにする必要があります。 この従業員がどれほど専門的であり、親会社でどのように使用するかに関係なく、プロジェクトの考えを信じていない人々のチームを取り込むべきではありません。
5. 人々に勉強し、さまざまなセミナーやトレーニングに参加する機会を与えます。 脳を再フォーマットすることの利点は、費やされるお金や従業員が誘惑されるリスクよりもはるかに高いです。 停滞はスタートアップにとって直接的なリスクです。
6. プロジェクトマネージャーがプロジェクトに関係のないタスクを委任することは破壊的です[誘惑は素晴らしい-人は給料をもらっていて、資格があり、簡単にさらに2つのプロジェクトを取ることができます]。 チームがリーダーがプロジェクトに関係のない問題に対処していることに気付いた場合、プロジェクトにそれほど集中することはできないため、プロジェクトはそれほど重要ではありません。 その結果、マネージャーの集中力が失われ、チームの仕事が弱まり、チームの動機が低下します。
7. リーンスタートアップに精通していない人に社内スタートアップの責任を負わせることは受け入れられません。 スペシャリストがどれほど有能であっても、また彼の背後にある工業プロジェクトやカスタムプロジェクトがいくつあっても、スタートアップを作成する原則を知らない場合、および/またはそれらに経験がない場合は、プロジェクトを信頼する必要はありません。 そしてさらに、彼が説得し、導く能力を持っているなら。 説得して逃げましょう。 それだけが成功する可能性は低いです。
8. スタートアップリーダーが新しいアイデアを定期的に生成してプロジェクトに適用しようとするイデオロギーの人である場合、彼は間違いなく、プロジェクトを新しいアイデアでバラバラにせず、実際にそこに値する小さなバックログのみを許可するプラグマティストとペアにする必要があります。 さらに良いことに、バックログから余分なものをすべて削除し、最も重要なものだけを残します。 そして同時に、プロジェクトリーダーの激しいスピーチに抵抗する必要があります-実用主義のみです。
9. ピボットがプロジェクトのドアをノックしている場合は、無視しないでください。 また、親会社のリーダーは、新製品に対する市場の反応を注意深く監視する必要があります。チームは、ピボットの前提条件を確認できない場合があります。 または私が見なかったふりをする。 給与と明らかな安定性があるためです。 そして、私は必要なことではなく、面白​​いことをしたいのです。
10. 内部スタートアップを作りたい親会社のリーダーにとって、リーンスタートアップとそのようなものを作成するための基本原則について読むことは非常に役立ちます。 それ以外の場合は、プロジェクトマネージャー（さまざまな言語を話す相手）と長時間議論するか、プロジェクトと投資が問題になっているリスクを認識できません。