よくあることですが、専門家の緊密なチーム、途中の強力で高品質の製品、金融セキュリティの厚い投資枕、そして何かが間違っています。 さらに、これらの「何か」の毎週でますます多くなっています。 従業員は緊張しており、残業モードで膨大な量の仕事が行われ、内部コミュニケーションが絶え間なく失敗し、責任と有罪を求めています。勝利には多くの父親がいます。敗北は常に孤児です。 スタジオの開発のためのこのような破壊的なシナリオは、その活動の完了への遅いが確実な道です。 しかし、数か月前に集まっただけではありませんか？
多数の新興企業は、ある時点でスケーリングを正しく計画および制御できないという事実が原因で、「邪魔にならない」ようになっています。 どんな組織も生き物のようなものです。 開発の欠如は、遅いが確実に死んでいることを直接示しています。 逆説は、急速で制御されない成長が望ましい結果の反対につながる可能性があるということです。 しばらくして、会社は粘土の足で巨像になりました。 微風、市場状況の変化、または楽観主義の世界的なプロセスでさえ、すべてが崩壊する可能性があるという感覚は追加されません。 緊張、ストレス、むら、結果としての生産性の低下。
この記事では、このような状況を克服するための経験を説明しようとします。 簡単ではありませんでしたが、私たちはそれに対処しました。
物語
部屋8は2012年春に登場しました。 ジャンルの古典。 モバイルデバイス用のゲームを作成したいという大きな欲求は、志を同じくする人々を集めました。それぞれの人々は、新たに作成された会社がその活動を行う業界にまったく関係のない経験を持っていました。
このビジネスモデルには、本格的なゲーム開発スタジオの構築が含まれていました。 計画では、年間5〜6個の高品質のゲームを制作する予定でした。 モバイルゲーム業界の急速な成長は、主なリスクのバランスが取れており、さらなる成長と開発の可能性が高いという希望を抱かせました。 ともに、これらの要因の両方がVostokVenturesベンチャー企業の注目を集め、Room 8のスタジオは投資支援に同意しました。
投資を受けた後、スタジオは急速に成長し始めます。 開発、テスト、設計、ゲーム設計、マーケティング部門が大幅に強化されています。 わずか2か月で、スタッフは7人から30人に増えました。 3か月後、スタジオには60人の従業員がいます。 設立から5か月後、同社は新たに特定された膨大な数の問題を抱えた雑多なチームの雑多な花束でした。
火事
上で述べたように、急速な成長は多くの世界的な問題を引き起こしており、それぞれの従業員が一人で解決しようとしても無駄になりました。 開発に関する（解決可能な）問題に加えて、管理の問題も「燃え尽きる」。 歴史的に、プロジェクト管理機能はGameDesignerに割り当てられていましたが、GameDesignerはそれを主な活動であるゲームデザインに関する製品開発と組み合わせる必要がありました。 創設者グループの調整行動は、一貫性、経験の欠如、および互いの期待を管理できないことによって妨げられました。 これはすべて、残業の混雑とコミュニケーションの問題によって悪化しました。 そのとき、組織構造は次のようになりました。
1つのプロジェクトの典型的な写真
そのような構造の欠点を理解してみましょう。
- 権限と責任。 一方で、ゲームデザイナーは作成されるゲームに対して個人的な責任を負います。 一方、ディレクターにはプロジェクトチームメンバーを管理する権限もあります。 実際には、gamedizでの意思決定の自由は限られていることがわかります。 この状況は責任の曖昧さをもたらします-遅かれ早かれ、ディレクターの一人が「加熱された」議論に関与しました。
- 可用性とコミュニケーション。 多数の人々がプロジェクト管理に関与しており、その多くが一度に複数のプロジェクトに関与しているため、スキームも複雑です。
- 利益相反。 ゲームデザイナーは、製品の責任（最高の製品を作成する必要があります！）とプロジェクトの責任（製品を作成するための最適な方法を常に探しています）を組み合わせました。 したがって、ゲームデザイナーは内部矛盾の永続的な状態にありました。 一方で、品質と美しさの感覚、そして他方で-タイムライン、期限、収益性。
- 優先順位付けの間違い。 急速に成長する構造は管理が困難です。 多くの場合、ゲームデザイナーに対する多方向のプレッシャーにより、彼は次第に矛盾する決定に至りました。 ゲームデザイナーが製品を想像する方法は、多くの場合、他のプロジェクト参加者の世界観とは異なっていました。 したがって、通信障害、競合、および大量の否定的なフィードバック。
（急速に成長している）スタートアップの特徴の1つが、私たちの側でまだプレイされていることに注意してください。 柔軟性を意味します。 はい、会社の構造を修復して更新するのにほぼ6か月かかりました。 はい、参加者の問題を克服しなければなりませんでした。 交渉し、妥協し、再度交渉します。 しかし、現時点では、数百日前よりも、アジャイルの原則に取り組んでいる合理化された全体的なメカニズムのようです。 過去6か月間のすべての混乱により、私たちはさらに良い製品を生産できると信じたいと思います。 しかし、まず最初に。
火を消す方法
プロセスの参加者として、その原則と論理に影響を与えることは非常に困難です。 自己管理の変更のリスクは非常に大きいです。 会社の経営者が当初から管理システムの組織にミスを犯した場合、エラーに対して多くの深刻な作業を行ったという保証はどこにありますか？同様の結果は得られませんか？
このリスクを軽減するために、多くの国内の新興企業にとって非典型的なステップを踏んだ。 つまり、外部からの男性が招待されました。 この「上」のプロセスの専門家の位置に関連して制御システムを構築する原則の知識は、特定の希望に影響を与えました。 私たちはどんなアイデアや提案にも完全にオープンであり、これらのアイデアは表明されました。 実際、私たちは自社組織の強化に投資し、スタートアップの熱意を利用した後、スタジオは第2の風を切り開きました。
この外の人は誰ですか？
ベンチャー企業はスタートアップに金以外の何も提供しないという誤解があります。 お金が「与える」のではなく「投資する」からという理由だけで、これはまったく真実ではありません。 もちろん、私たちの「ビジネスエンジェル」は、しばらくして私たちが身をかがめることに全く興味がありませんでした。 専門家のアドバイス、可能なビジネスコンサルタントの連絡先の詳細、モラルサポート-これらはすべて、ベンチャー投資家から完全に受け取ったものです。
私たちは何をしましたか？
私たちは上から始めました-取締役会で。 プロジェクトの重要性において優先順位が特定され、私たちが指示する準備ができているリソースの量が見直されました。 写真では次のようになります。
プロジェクトの優先順位は 、見通しに応じて決定されました。 当然、すべてが最も重要ではないかもしれません。 Occamのカミソリは単純な質問です。「ゲームを1つだけ作成する機会がある場合、開発用にどちらを選択しますか？」という選択はまあまあです。 今晩、私の子供の誰が夕食を食べますか？ タフで快適ではありませんが、必要です。
リソース割り当て。 既存のプロジェクト間で重点が複雑に調整された後、リソースが分配されました。 より重要なプロジェクトは、チーム内の最強の人材を獲得し、もちろん注目を集めるべきであることは明らかです。 この単純な原則の導入後、人員の毎日の再配置の絶え間ない実践は終了しました。 誰もが最も重要なプロジェクトではなく、誰よりも明るく燃えているプロジェクトを握りました。
「上」に注文した後、次のステップはSCRUMの実装でした 。 最初の波の一部として、このシステムの一部の要素のみを紹介しました。 できるだけ早く目的の結果をもたらすはずだった要素。 これらは毎日のスタンドアップと反復デモです。
毎日のスタンドアップ。 毎日プロジェクトチームが集まり、それぞれが3つの簡単な質問に答えました。昨日は何をしましたか？ （誇り）どんな問題に遭遇しましたか？ （助けを求める）今日は何をしますか？ （約束）このシンプルな革新は、チームがコミュニケーションの効率を高めるのに役立ちました。 スクラム委員会はすぐには根付かなかったかもしれませんが、スタンドアップはプロジェクトの調整と理解を著しく高めました。 たとえば、金曜日の夜ではなく、火曜日の朝にタイムラグについて知ることができることに突然気付きました。
反復デモは、開発中の製品のステージとコンポーネントの状態を明確に示しています。 この要素の導入により、チームレベルでのコミュニケーションを確立することができました-リーダーシップ。 プロジェクトへの関与とその状態の認識により、透明性が大幅に向上し、それにより全体的な緊張が軽減されました。
なぜ再び問題が発生するのですか？
スタジオの最初の3か月後、多くの場合、すでに解決された問題が再発することがわかりました。 さらに、同じ人々や異なるプロジェクトで同様の問題が発生する可能性があります。 その理由は非常に些細なものでした。特定のプロジェクトへの注意が引き裂かれ、それぞれのプロジェクトの開発が妨げられました。 プロジェクトの開発における小さな、しかし計画外の一時停止は、明確な後退です。
継続的な開発プロセスをサポートするツールを見つけるのに時間はかかりませんでした。 まず第一に、私たちは異なるレベルの計画に行きたかったのです。 会社の機能の反復的な品質保証の実践をテストすることにしました。 次のようになります。
1.ディレクターグループは、各部門（エンジニアリング、テスト、アート、ゲームデザイン）の品質基準のセットを作成します。デフォルトでは、コンプライアンスは作業品質のプロセス全体を決定し、効果的です。 基準は次のようになります。
エンジニアリング：コーディングスタイル、コードレビュー、リファクタリング
テスト：エンジニアリングチームとのコロケーション、テストケース、欠陥メトリック、機能メトリック
アート：設計リポジトリ...など
2.その後、月に一度、開発された基準に従って各プロジェクトを評価するプロセスが通過します。 定性的な数値メトリックは次のようになります。
または、詳細に興味がある場合は次のようにします。
3.次に、部門長は、結果の現実像を分析します。 まず、問題のあるプロジェクトのレッドゾーン。 分析では、次の2つの主な質問に対する回答を提供する必要があります。これが発生した理由と、次の会議までに状況が変わるようにする必要があることです。
4. 1〜2か月後、何が起こっているかを説明する写真が安定します。 つまり、ほとんどすべてのプロジェクトコンポーネントが徐々にグリーンゾーンに移行しています。 これは、すべてが今うまくいくことを意味するのではなく（プロジェクトは開発中です！）、新しい基準を開発し、ステップ1から3を繰り返して、実際にプロジェクトをレッドゾーンに追い込みます。
このツールの意味は、スケジュールが常にグリーンであるということではなく、会社が内部リソースのみを使用して、サイドからの「キック」なしで開発することです。
ビジネス分析で無理をしない方法
SCRUMシステムを実装することにより、プロジェクト管理で状況を改善する試みがありました。 しかし、このシステムに「押し付けられた」ほど、ゲームデザインが悪化しました。 そしてその逆に、ゲームのデザインが判明したとき、SCRUMの原則への準拠は低下しました。 小規模な分析の結果、SCRUMとGameDesignの競合の主な理由が明らかになりました。プロジェクトマネージャーとゲームデザイナーの機能を組み合わせた従業員にとっても、内部の利益相反と同じであることが判明しました。 決定したように、唯一の方法は組織構造を変更することです。 特に、すべての管理機能は、意志の強い決定によってゲームデザイナーから削除されました。 しかし、誰かがプロジェクトを管理する必要がありますか？ 各プロジェクトを管理するために、プロジェクトコーディネーターという新しい役割が導入されました。
その結果、次の構造が得られました。
おわりに リーンマネジメントを発明しました
SCRUM実装のパスを克服して、1年前に同社が直面したすべての問題の解決策を見つけました。 さらに、克服のプロセスだけでなく、移動の方向を選択する問題にも困難が生じました。 当然、会社の発展は継続的なものであることを完全に認識しています。 一度目を覚ますことはできません。「それだけです。 私の会社は発展しました。」 私たちは無数の道と分岐点に行かなければならないことを理解していますが、彼らが言うように「道は歩いている道によって圧倒されます」。 私たちは、新しい問題を探し続け、それらの説明を定式化し、それらを解決する方法を探し、改善されていないすべてを改善します。
会社がどのような状態にあるかという質問に対する答えは、プロセスの理想性を評価することではなく、業界全体および市場全体の状況の変化に応じてプロセスを迅速に変更する能力にあります。 それ以外の場合は機能しません。 あなたは、スタートアップが生き残るだけでなく、彼らを現代的で若い精神と効果的なビジネスに変えるのに役立つ何かを絶えず検索して見つける必要があります。