チームリーダーのどのような問題がゲームの助けを借りて解決できるか

みなさんこんにちは！ 私の名前はYevgeny Rtischevです。Sbertekhで、私はUnified Frontal SystemのプロジェクトでITシステム開発の責任者として働いています。 9月24日、サンクトペテルブルクで開催されたSaint Teamlead Conf 2018カンファレンスで講演しました。 私のレポートは、リーダーとしての私の頭痛を大幅に軽減し、モチベーションと規律を助けたチームで開催されたゲームに関するものでした。 聴衆は非常に暖かくトピックを受け入れ、多くの興味深い貴重な質問をしました。



報告書のいくつかのポイントが欠落しているように思えました。 そのため、この記事では、もう一度実験について話し、結果を共有することにしました。 会議に参加したことがなく、迅速なパフォーマンスレビュー、ゲームを通じてチームを管理、製品開発への関与を増やすための代替ツール、および大企業での「ゲーミフィケーション」と官僚主義の概念を組み合わせる方法についてのストーリーを読みたい人- ようこそ 。

イントロ

それから、チームリーダーになること、意識的な問題と犯した間違いについての一貫したストーリーテリングがあります。 隠しません-解決策は、特別なチームゲームを導入することです。したがって、貴重な時間の10〜15分を費やす意欲と興味がない場合は、「今はみんなMotCを採掘しています」セクションにジャンプして、ゲームの本質、バランスと調整の誤算について直接読むことができます、それから来たもの。

問題と痛み

私がスベルテに来たとき、新しい内部プログラムが始まりました。そして、モバイル開発チームを迅速に編成する必要がありました。 私が去った1ヶ月後、私のスーパーバイザー（私を雇っていた）は辞職し、彼のすべての仕事と問題は私のものになりました。 正直なところ、その前は1年間2人のチームを管理した経験がほとんどありませんでした。 むしろ、それは新しい開発者の技術的な指導と指導のようなものでした。 チームはすぐに11人に拡大し、コードの記述、アーキテクチャの開発、その他の難しいタスクを完全に避けました。 私は感情に敏感になり、管理の原則は状況管理に対応しました。そして、私はより長期的に見て、チームの人々を育て、新しいリーダーを育て、引っ張りが得意な人を祝福し、励まし、そして「悪い人」と怠zyな人を特定して罰する必要がありました。



定期的な管理の要素を導入する方法を見つけました。 つまり 報酬と罰のための透明なルールを備えたシステムが必要でした。 この場合、私は本当にすべてを減らしたくありませんでした

ありふれた方法であり、その反応は常に反対になります。











最初に、条件付き問題のリストを作成することにしました。

チームとして改善したかった。 たとえば、スタンドアップに遅れず、準備を整え、お互いに注意深く耳を傾け、問題の解決に協力してもらいたいと思いました。 多くの人は、スタンドアップや毎日が好きではありません。 作業時間の無駄だと考えてください。



最初のステップは、アジャイルセレモニーで話した言語を変更することでした-私たちは英語でスタンドアップを行い始めました。 決定は突然行われました。多くの人が事前にテキストを準備し、期間を短縮しました（英語は簡潔で、誰もが本質にのみ集中しようとしました）。



そして、私は実験する必要があることに気づきました

問題領域を策定します

体系的思考への傾向は、何かをするためには、まず問題を、より正確には、私が改善したいものを定式化する必要があることを教えてくれました。 それから私は

主な分野の概要を説明しました。

チームメンバーランキング

当社には、一連の成績があります-これらは、独自の正式な責任、特権、および給与フォークを持っている特定のレベルです。 実際の力の配置は、理解できる理由で正式な配置とは異なることがよくあります：空席の数とそのグレードが限られている、すべての人が異なる時間に異なる条件でチームに来た、誰かが短時間で強い成長を見せた、など アップグレード手順は複雑であり、非常にまれであり、それに備えて十分に準備する必要があります。 それに値する人々を客観的に指名する。 最初のそのような手順では、私は大きく誤解されていました。個々の男のすべての長所や失敗を思い出すのは難しいので、おそらく自分の気質のために、いくつかの場所で主観的な意見から進みました。 そして、これは間違っています。



このような状況でエラーを修正するのは非常に困難です。 そして、私は初めて間違えられました（1分間の告白）。 しかし、ネガティブな経験は良い先生です。 明確なツールが必要であることに気付きました-成長している分野で、人のすべての成果と失敗を確認するための簡単な指標です。 情報は常にアクセス可能で適切である必要があり、公開されていても何も問題はありません。その後、チームメンバー全員が次の変更に関して質問を少なくします。

製品開発支援

私が到着したとき、会社はウォーターフォールモデルに従って働いていました。実際、銀行が顧客であり、Sberbank-Technologiesのチームが内部請負業者でした。 1年後、会社は大規模なアジャイルに切り替えました-チームは分散化され、独自の製品（1つの大規模なサブモジュールである可能性があります）の開発に集中しました

システム）。 そのようなチームの製品所有者の肩には、線形管理とサービスアーキテクト（技術製品の場合）に加えて、製品管理、つまり 彼のビジョンの形成、開発の戦略マップ、タスクの詳細化と優先順位付け、および実装のタイミングに対する責任。



そして、私は製品の所有者として、チームメンバーにタスクを遂行するだけでなく、製品の成長、新鮮な新しいアイデアの提供、責任と頭痛の軽減を助けてほしいと本当に望んでいました。 たとえば、要件の収集、要件の開発、および特定の論理的タスクと順次タスクへの分解に多くの時間が費やされました。 別の問題は、製品サポートとユーザーとのコミュニケーションでした。 私たちの製品は、モバイルiOSアプリケーションを開発するための内部ライブラリーです（これについてはすでにHabrに関する一連の記事がすべてあります）。 そして、私たちの消費者は他のアプリケーションチームです。 ある時点で、ユーザーの数は約120人の開発者、デザイナー、マネージャーに達しました。 そして、私は皆と通信するために1日12時間すらありませんでした。 私は、チームがこれを積極的に支援することを本当に望んでいました。

計画の正確さとタイムキラーの決定

長い間、ストーリーポイントインジケーター（以下SPと呼びます）は、スプリントからスプリントへと急激に変化しました。 毎回、PROMから欠陥が到着したか、または

いくつかの計画外の非常に重要なタスクは、リーダーシップから直接。 彼らは定期的に文句を言い、自分自身に不満を抱いていました。時間が過ぎた場所、新しく受け取ったタスクがスプリントよりも重要かどうか、それが製品にもたらす価値を理解できなかったためです。 0 SPで欠陥を評価するための複雑さと一般に受け入れられているアプローチを追加しました-私は常にスプリントに追加しました

スプリント中に到着した重大な欠陥と交換できるように、一定数の欠陥。

新鮮で新しいもの

1つの製品と同じチームで2年間働いた後、人々は疲れ始め、目は狂った光沢を失い、生産性が低下します。

発明しなければならなかった解決策は、再び光を少しと

チームを元気づけてください。

チームについて少し

チームについてもう少しお話したいと思います。プロダクトオーナー、アナリスト（別名スクラムマスター）、9人のiOS開発者です。 こんなに均質なチームの力のバランスを理解したいと思った理由を今理解していますか？











いくつかのソーシャルデータ：2人の女の子がおり、参加者の年齢は

22から33の範囲です。関心のあるエリアは異なっていましたが、

一般的なチームアクティビティ：通常のボードゲーム、ミニ企業イベント、

会議への共同旅行など

今誰もがMotCを採掘しています

私は常にゲーム業界に大きな関心を持っていました。 子供の頃、レゴキューブから世界全体を構築し、紙に簡単なボードゲームを描き、3D Maxに夢中になり、その後、Dark Ba​​sicやGame Factoryなどのコンピューターゲームを作成するための簡単なツールを学び始めました。 私はMMOに多くの時間を費やし、最も奇妙なことに、Warcraft 3のマップエディターでゲームディアブロ2の独自バージョンを作成しました（市内のローカルネットワークでも成功を収めました）。



あなたが理解しているように、私は再びゲームの世界を作成し、没頭したかった

リアルタイムチャレンジのチームメンバー











ゲームには、それ自体で非常に有用な基礎が含まれています。つまり、競争、ポイントとレーティング、ルールと違反、シングルとチームの成績です。 ゲームは興奮（私たちの場合は関与に似ています）に感染し、敗北の苦味と勝利の喜びも教えます。



残っているのは、設定を選択し、メカニズムとルールを考え出し、バランスを調整し、条件付きのバイラル性に取り組むことだけです。





Saint Teamlead Confに関する私のレポートの大部分は、ゲームを作成し、必要なすべてのポイント（ゲームプレイ、バランスの問題、4種類のプレイヤーの心理学など）を完了することに専念しました。 私はそのすべての情報をテキストに翻訳するつもりはありません-興味のある読者がolegbuninがエントリーを公開する（または私に私を書く）のを6か月待つことを望みます。 また、11月2日のチームリード会議に耳を傾けることができます。

MotCの入手方法

つまり、特定のアクションを実行するための仮想コインを取得できます。

1.スプリントタスクを終了します。 これはビジネス価値をもたらすものであるため、これは重要であり、奨励する必要があります。 1 Story Pointは1.2 MotCをもたらしました。 なぜ等しい値ではないのですか？ はい、それは簡単です。まず、マジックナンバーは既に何らかの係数があることを示しており、その存在を示しているので、いつでも慎重に変更できます（バランスを調整するため）。 Plus MotC-整数、つまり また、より多くのストーリーポイントをクローズするための追加のインセンティブでもあります。 3の場合は3つのMotcを取得し、5の場合は6を取得します。



2.欠陥の修正。 SPには評価がないため、MotCで評価してください。 重大度のレベルが異なると、MotCの観点からも重みが異なります。 しかし、ここでも（すべての開発者が好むわけではない）欠陥の修正を促進するために、1つのクローズドバグは常にわずかな量のコインをもたらします。



3.非印刷タスクの修正。 欠陥に加えて、ビルドサーバーの故障、UIテストの低下、管理者からの緊急かつ重要なタスクの到着など、その他の緊急タスクがありました。 今、彼らのために、人はMotCを受け取り、それによってスプリントのSPの不足を補った。



4.評価とランク。 すでに4つのカテゴリが考案されています：SPチャンピオン、貢献最大化（MotCの最大数）、スプリントヒーロー、チーム賞。 最初の2つの原則は、名前から明確にすべきであり、残りはもっと興味深いはずです。 スプリントのヒーローは、レトロで投票するチームによって選ばれました。これは、Motの数と名声と重要性の両方の面で、チームで最も名誉ある賞の1つでした。 チーム賞の存在が重要です 彼女は個人的な結果だけでなく、チーム全体の全体的な結果も重要であることを示しています。 3つのグラデーションが発明されました。通常のスプリント、トップスプリント、および失敗したスプリントです。 スプリントバックログの78％以上がクローズされた場合、100％であった場合、これがトップスプリントです。 トップスプリントの場合、チーム全体が大幅に増加しました。 しかし、コインには裏返しがありました-これは失敗したスプリントです。

マイニングネガティブMotC

MotCは重要です。 したがって、負の値のコインを取得することができました。 反メリットがこれにつながったもの：

1. 失敗したスプリント。 スプリントバックログの78％未満が完了した場合、チーム全体がマイニングを負いました。
2. 欠陥を開きます。 注入タスクに明白な欠陥があった場合、プルリクエストを注入した開発者とそのレビュー担当者が否定的なMotCを獲得しました。
3. 3.スタンドアップまたは同僚の不注意に遅れたため、追加の資金システムも発明されました。 彼女は「3行連続」の原則に基づいて行動しました。 3つの同一のアイコンが新しいものに崩壊し、ネガティブマイニングが発生しました。 恩赦のルールがありました。スプリントで25を超えるMotCを受け取ったとき、崩壊はネガティブマイニングにつながりませんでしたが、バッジはリセットされませんでした。

MotCの使い方

はい、はい。 コインの意味は、個人の評価だけでなく、使用できるという事実にもあります。 このために、アクティベーション機能が発明されました。 正のコインのみをアクティブ化できます。 品物とその価値がある店全体がありました。 制御のために、それらの数は制限されていました。



店には何がありましたか？

1. 仕事を早く辞めるか、後で戻ってくる能力。 最も重要なhodovichok。
2. リモートワークの日。
3. 計画における優先タスク選択の可能性。
4. LinkedInの推奨事項。
5. Swiftで開発するモジュールを選択します。 すべてのコードはObjective-Cで作成されており、Swiftで開発したいと考えています。
6. 会議チケット（利用可能な場合）。

他のポジションもありましたが、ここで最も重要なルールは、購入の可能性を保証することです。そうしないと、自信が損なわれます。

ゲーム中の修正

実験中、特定の時点で、プライマリバランスの問題が顕著になりました。

どれ？



1.ロールモデルプレーヤー。 開発者に加えて、チームには1人のアナリストがいて、MotCを取得する彼の能力は非常に制限されていました。 ストーリーポイントのタスクの大部分は、開発のために研ぎ澄まされました。 また、アナリストの機能には管理タスクの一部が含まれており、常に監視するのに費用がかかりました。 解決策は、「特権マイニング」の概念を導入することでした。 特定の数のMotCが毎日の義務を果たすために自動的にクレジットされます。 将来、別の不均衡が見つかったのは興味深いことです。アナリスト（休暇など）がいない場合、誰かが仕事を引き継ぎ、特権マイニングの生産に参加しました。



2.タスクの減価償却。 時間が経つにつれて、特定の反復タスクが完了しやすくなります。 たとえば、新しいバージョンのフレームワーク（製品）をリリースする手順がありました。これには約1.5〜2時間かかりました。 DevOpsの開発により、その時間は30分に短縮されました。 それに対応して、MotCの報酬も減少しました。 または、定期的に新しい形式のレポートまたはステータスを準備するタスクがありました。 初めてこれを行うことは困難ですが、それを繰り返すのは簡単です-したがって、コインの推定は減少しました。 チームはそのような調整を適切に認識しました。



3.欠陥のダブルポイント。 各チームに予期しない状況があり、ルールを「調整」する必要があることを示す例。 長い間、自動カスケードマージを使用していました（つまり、修正プログラムを注入すると、以前のリリースバージョンで自動マージが表示され、開発されました）。 ある時点で、develop-eでマージの競合が絶えずハングするため、この悪質なプラクティスを停止することを決定し、変更をアップロードするすべてのバージョンでタスクを複製するというアイデアに移りました。 これにより、JIRAに複数の同様のタスクが出現しました。











その結果、正式にルールに従って、プレーヤーは2〜3個のタスクをすばやく実行して完了し、2〜3倍のコインを獲得できました。 そのようなタスクの修正を導入する必要がありました。なぜなら、それらの複雑さが減少したためです（ただし、個々のブランチの変更による潜在的な競合のためにゼロにはなりません）。



4.ユーザーと協力してやりがいのあるアイデア。 私は消費者を助けるためにみんなを「強制」したかった（そしてこれは約100人のアプリケーション開発者であり、愚かな繰り返し質問に満ちている）。 さまざまなアプローチを試みました。アテンダントを任命し、詳細な知識ベースを維持し、エキスパートユーザーのコミュニティを成長させ、それらを奨励します。 しかし、簡単な解決策が登場しました。1日に1回、Slackのサポートチャットをざっと見て、チームの最もアクティブなコンサルタントに、MotCの形で小さくても楽しい報酬を与えました。 みんなの評価



一般的に、ゲームは生きる過程であり、その過程で変化しなければなりません。 主なことは、最初から自分自身を保証し、有機的な操作の余地を残すことです。 ゲームの仕組みを変更すると、プレイヤーの間でresみが生じる可能性があります。 当初、マイニングと「賞品」のコストのバランスを正しく計算できないのではないかと心配していました。そのため、店内の数が限られており、可能な限り補充されることをすぐに示しました。 さらに、ご存じのとおり、供給市場は独占によって制御されており、独占は常に赤字またはインフレを宣言できます！

結果と観察

実験全体は9スプリント（4ヶ月）続きました。 合計968個のMotCが使用され、262個が使用されました。トップスプリントが3回あり、同じ人が4回スプリントのヒーローになり、チームでのMotCの分布は次のようになりました。

	MotC	MotC +
プレイヤー1	104	86
プレイヤー2	203	203
プレイヤー3	148	128
プレイヤー4	65	47
プレイヤー5	172	92
プレイヤー6	58	40
プレイヤー7	68	68
プレイヤー8	95	77
プレイヤー9	55	55

ここにあります-それが私が作成したかった唯一の指標です。



ちなみに、データベース全体がNumbers（MacOSの場合はxls）に格納され、週に1回（レトロ向けにMotCを発行した時点で）参加者に送信されました。 マイニング履歴、購入履歴、オファーストア、マイニングの詳細、サマリーテーブルの5つのページがあり、エンドツーエンドの式がありました。



私は会議でそれを行うのに長い時間がかかったかどうか尋ねられました。

答えはノーです。 それどころか、私はJIRAでタスクを設定する時間を短縮しました。

ちょっとしたことや、ノートブックと同期すること。

すべての委任タスク。 「ディテール」というテーブルはただ

命令を書き留めることができる新しい種類のノートブックと、それらが実行されたとき

報酬を記録します。 以下は、プレーヤーごとに1つのスプリントの例です。

MotC	マイニング
1	問題Xの提案
1	デモ用のライブラリアイコンの更新でMakovを支援する
2	IP用のボイラープレートでリポジトリを準備する（デモ用 マニュアル）
2	IPの例のためのXSDスキーマの準備、および 定型相談
3	欠陥閉鎖
16	14 SPに変換
4	マキシマイザーSP

実験が終了したとき、私はみんなに尋ねました-誰もがイノベーションに満足しており、新鮮でエキサイティングであることを確認しました。









結果は、Win-Winの状況です。 開発を管理するのが簡単になりました。彼らには新しい機会とチャレンジ精神があります。 一部の人は、新しい開発方法と製品に利益をもたらす方法を自分自身で見つけました。 同時に、チーム全員が一緒になって、スプリントの終わりまでに最高の結果を得ようとしました。



これが適切な管理オプションまたは理想的なツールであることを証明しようとはしていません。これは、私の管理スタイルを多様化し、良い方法でチームを「元気づける」ための単なる例です。 実験することを恐れないでください。最も重要なことは、常にプロセスを最適化し、新しいルールとテクニックを作成することです。 パフォーマンスレビューとチームの動機付けに対するあなたの例やアプローチに耳を傾けたいと思います。



読んでくれてありがとう！



PS FacebookまたはLinkedInで友人として私を追加することができます。また、11月2日に開催される次のチームリード会議でこのトピックに関するスピーチを聞くことができます。