チームの効果を評価する方法

旅の始まりにあるクールなスタートアップは、Peregrine Falconに似ています。 小さなチームが急速に勢いを増し、将来に突入し、多くのタスクを本番に持ち込みます。 Skyengのようにプロジェクトが有望であることが判明した場合、数年後にはかなり多くのチームが存在することになり、その中には、少なくとも何かがユーザーに届くように、constantlyに火を常に放り込む必要がある蒸気機関車が存在する可能性があります。





チームが素晴らしいかどうかを判断するための正式な基準がわからない場合は、Saint TeamLead ConfでのAlexey Kataevの講演をご覧ください。 「かなり」、「いくら」、「ひどく」のカテゴリで操作するのではなく、技術的な負債を数時間で測定できるようにしたい場合。 プロダクトマネージャーが1か月に3人のチームで60のタスクを実行すると考えている場合、この記事を見せてください。 マネージャーがメトリックを使用して開発を中断し、次のような結果に基づいて対策を講じることを提案している場合：「34％はチームが計画に問題があると思う」、このレポートはあなたのためです。







講演者について： Alexey Kataev（ deusdeorum ）は15年間Web開発に携わっています。 バックエンド、フロントエンド、フルスタック開発者、チームリーダーとして働くことができました。 現在、 Skyengで開発プロセスの合理化に取り組んでいます。 分散したチームの仕事について話す際に 、チームリーダーがよく知っている場合があります。



最後に、フロアをスピーカーに渡します。 コンテキストから始めて、徐々に主な問題に移りましょう。







私は2015年にSkyengに入社し、5人の開発者のうちの1人でした。彼らは全員社内の開発者でした。



3年余りが経過し、現在15のチームがあります-これらは68人の開発者です。







すべての開発者はリモートで作業し、世界中に散らばっています。



会社を5人から68人の従業員に拡大するときに必然的に発生する問題を見てみましょう。



写真では、Sergeyが開発マネージャーです。





チームが1つになったら、Sapsanが未来に駆けつけ、生産のために多数のタスクを実行しました。 しかし、タスクだけでなく、技術的な負債も少しあります。 それから、ある時点で、予想外に、もっと多くのチームがありました。



セルゲイが直面する最初の質問は、 すべてのチームがサプサンであるかどうか 、またはfireを火室に投げ入れる必要がある蒸気エンジンがあるかどうかです。





この質問は重要です。なぜなら、そのような状況が発生する可能性があるからです。プロダクトマネージャーまたはビジネス担当者がセルゲイに来て、時間がないと言って、チームはうまく機能していません。 しかし実際には、問題はチーム内だけではありません。 問題は、チームとビジネスの関係、またはビジネス自体にある可能性があります。目標を適切に設定できないか、計画が楽観的すぎる可能性があります。



チームがクールかどうかを理解する必要があります 。





2番目の質問は、チームのリソースです。製品に対してどれだけのタスクを引き受けることができますか。 製品には近い将来に多くの計画が常にあるため、この問題は重要です。 チームがこれらの計画に対処するかどうか、またはタスクの半分を捨てる必要があるかどうかを理解することが重要です。 または、すべてのタスクを完了するためにさらに数人を雇う価値があります。





3番目の質問は、どれだけの技術的負債を抱えているかということです。 これは重大な問題です。なぜなら、その量が制限値を超えると、最終的に私たちの列車はどこにも行けなくなるからです。 チームを解任し、最初からプロジェクトを開始する必要がありますが、これは許可しません。





最後に- すべてのチームが列車ではなくサプサンであることをどのように確認しますか？

1.チームのクールさを決定します。

もちろん、最初に頭に浮かぶのは、いくつかのメトリックを測定することです！ 今、私たちの経験と、私たちが何度も何度も間違っていた方法についてお話します。





まず、 速度を監視しようとしました-スプリントのためにロールアウトするタスクの数。 しかし、チームの半数にはスプリントがまったくなく、カンバンがあることが判明しました。 スプリントがある場合、タスクは時間単位またはストーリーポイントで評価されます。 タスクを実行するチームがまだ2つあります。カンバンがなく、スクラムが何であるかがわかりません。



これはデータの不整合です。 完全に異なるデータで1つの数値を計算しようとしています。 同時に、すべてのチームが同一になるようにスプリントをいたるところに作成すると、非常に費用がかかります。 1つのメトリックを計算するには、プロセスを変更する必要があります。



私たちは、さらにいくつかのオプションを試してみて、単純な指標- プランの実装 -を考えました 。 これも費用がかかりますが、製品計画のみを同一で一貫性のあるものにする必要があります。 誰かが彼らをJiraに導き、誰かがGoogleスプレッドシートの誰か、誰かがグラフを作成します。1つの形式に変換することは、チームのプロセスを変更するよりもはるかに安価です。



四半期ごとに、チームがビジネス要件を満たしているかどうか、完了した計画タスクの数を確認します。





インシデントの数のカウントも失敗しました。



会社に損害を与えたすべての失敗したロールバックまたはバグ、および事後を記録します。 セルゲイはチームリーダーとして私のところに来て言いました。「あなたのチームは最も多くの転倒を認めています。 なぜそうなのか」と私たちは考え、見たところ、私たちのチームが最も責任があり、すべての転倒を記録する唯一のチームであることが判明しました。 残りは、急落したという原則に基づいて行動し、倒れたとは見なされません。



ここでも問題は、データの不整合と不十分なサンプリングです。 着陸するだけのチームがあります-決してクラッシュすることはありません。 このチームの方が優れているとは言えません。プロジェクトがより安定しているからです。



第二に、私のお気に入りのトピックは認知バイアスです。 認知の容易さは、私たちにとって簡単に思える結論を下し、すぐにそれを信じ始めるときです。 批判的思考は含まれません。転倒が多い場合、それは悪いチームを意味します。



インシデントの数とまったく同じメトリックに到達しましたが、その実装を修正しただけです。 すべての転倒が記録されるプロセスを作成しました。 毎月末に、インシデントの隠蔽に興味のない人に質問します。これはQAと製品です。これはチームの障害が原因で発生した問題の完全なリストです。 彼らは私たちが何かを落としたときを覚えており、このリストを補足します。





世論調査にも問題があります。 それは超普遍的なツールのように思えます-私たちはチーム（チーム、製品、チームリーダー、顧客）にどんな問題があるかをインタビューします。 彼らの答えに従って、グラフを作成し、すべてを見つけます。 しかし、多くの問題があります。



まず、閉じた質問をすると、これらのデータから結論を引き出すことはできません。 たとえば、「チームは計画に問題がありますか？」と尋ね、34％が彼らが持っていることとそれをどうするかを言っていますか？ 「インフラストラクチャを備えたチームの問題は何ですか」という自由回答形式の質問をすると、誰もが書くのが面倒なので、空の答えが返ってきます。 これらのデータから結論を引き出すことはできません 。



このアイデアを開発しました-最初にスクリーニングとして調査を実施し、次に問題を正確に理解するためにインタビューを実施します。 インタビューについては少し後で説明します。



私は3つの例を挙げましたが、実際には数十のメトリクスを試しました 。



現在は次のもののみを使用します。

• 計画の履行。
• インシデントの数。
• 投票+インタビュー。

最も高価なものは実装であるため、すべてのチームでこれらの単純なものを測定することさえ言うと、私は欺かれます。 特に、15の異なるチームが存在する場合、製品に「はい、まったく必要ありません！ タスクを展開する必要がありますが、今はそれではありません！」 すべてのチームで1つの数値を測定することは非常に困難です。

インタビュー

開発者とのインタビューについて簡単に説明しましょう。 私はいくつかの記事を読み、食料品コースを通過しました。 ユーザー調査と顧客開発についてはたくさんあります。 私はそこからいくつかのプラクティスを取りましたが、それらは開発者とのコミュニケーションに非常によく当てはまりました。



チームが抱えている問題を見つけることが目標である場合は、まず、答えを探すターゲットを絞った質問を作成する必要があります。 つまり、30個の質問を投げるだけでなく、答えを探している2〜3個の質問を選択します。 たとえば、チームにインフラストラクチャの問題がありますか。 ビジネスとチーム間のコミュニケーションの確立方法。



この場合、質問は次のとおりです。

• 開く 質問への答え：「問題はありますか？」-「はい！」-何も言わないでしょう。
• ニュートラル 問題に関する質問は悪い質問です。 「チームの計画プロセスについて教えてください。」 人がプロセスについて話すと、あなたはすでに彼にもっと深い質問をし始めています。

別の非常に良いアプローチは、 優先順位付けです。 チームライフにはさまざまな側面があります。 あなたは、彼の意見では、どれが最もクールで同じままであり、おそらく改善されるべきである従業員に尋ねます。



本「インタビュー」のインタビューに関する章から取った別のアプローチがあります。 あなたのナンバーワンの問題を解決してください-「このような質問をしてください：」製品に尋ねたら 、どう思いますか、どのような問題に名前を付けますか？「これにより、開発者は私の立場からではなく、全体像を見てすべての問題を見ることができます

2.リソースを大切にします

次に、リソースの評価について説明します 。



製品のアプローチから始めましょう。通常、チームのリソースをどのように評価するかです。 3人で、1か月に20営業日です。日数を掛けると、60のタスクが得られます。







もちろん、誇張しますが、通常の製品ではこれが60日間の開発期間として増加します。 しかし、これも間違っています。60日間で60日間のタスクを誰もロールアウトすることはありません。 スクラムでも、フォーカスファクターを検討し、0.2などの特定のマジックナンバーを掛けることをお勧めします。 実際、反復から反復まで、12、17、10のタスクを展開します。 これは非常に大まかな評価だと思います。



リソースを評価するための独自のアプローチがあります。 まず、労働時間におけるチームの総リソースを考慮します。 私たちは開発者に何時間もかけ、休暇や休暇を奪います。 750を取得するとします。しかし、すべての開発が開発そのものではありません。





上記の実際のデータは、コマンドの1つの例です。

• コミュニケーションに費やされた時間の36.9％は、会議、ディスカッション、技術レビュー、コードレビューなどです。
• 63.1％-問題を直接解決します。

製品はこれらの63.1％を当てにできますか？ いいえ、製品タスクは一部にすぎないため、できません。 バグの修正とリファクタリングのためのクォータ（約20％）がまだあります。 これは、timlidが配布するものであり、製品はこの時間に依存しなくなりました。





製品のタスクについても、すべてのタスクが製品が計画したものではありません。 リリースのために緊急の助けを求めている他のチームの製品タスクがあります。 他のチームからのタスクの約8〜10％を見積もっています 。





そして今、私たちは287時間を持っています！ 成績に常に適合していれば、すべてがクールになります。 しかし、このチームでは平均の過剰消費がカウントされました-1.51、つまり、平均して、タスクは予想よりも1.5倍時間がかかりました。





主なタスクを完了するために、合計750時間が189時間残ります。 もちろん、これは近似値ですが、この式には変更可能な変数があります。 たとえば、1か月をリファクタリングに費やす場合、この値を代入して、何に頼ることができるかを調べることができます。



私は一日中これに専念しました-私はタスクを取り、Excelで平均時間を計算し、分析しました-私は多くの時間を費やし、二度とそれをしないと決めました。 毎回自分の手でそれをしないように、これにはいくつかの迅速なアプローチが必要です。



JiraとEazyBIのプラグインを勧められました。 これは非常に複雑なツールです。または、十分な能力がありませんでしたが、途中でgaveめました。



レポートをすばやく作成する方法を見つけました。





タスクトラッカーから既知の任意のDBMS（PostgreSQLは当社）にデータをアップロードし、アナリストにすべての計算を依頼します。 ディマがあり、彼はすべてを2時間で計算しました。





同時に、彼は多くの追加データを提供しました-開発者の残業、タスクの種類の残業、いくつかの係数、彼の洞察と新しい仮説について教えてくれました-楽しくてスケーラブルです：すべてのチームですぐに使用できます。

リソースを増やす方法

チームのスピードを上げる方法について -開発者の数を増やすことなくリソースを増やします。



まず、何かを加速するためには、まずそれを測定する必要があります。 通常、2つのメトリックをカウントします。

1. 反復のタスクの初期要約評価（時間単位）。 たとえば、1週間に100時間タスクを展開しました。
   
   
2. また、平均ローリング時間は、タスクが開発に入ってから実稼働するまでの時間である場合があります。 これはよりビジネス上の指標であり、開発者ではなく製品にとって興味深いものです。
   
   

週末に書いたボットArsenyに話すのは飽きません。 毎週彼はダイジェストを投稿します-どれだけのタスクをロールアウトしたか。







ここには2つの興味深いことがあります。

1. 私がオブザーバー効果と呼んでいるもの-何らかの指標を評価して、すでにそれを変更しています。 このボットの使用を開始するとすぐに、反復中に行うタスクの数を増やしました。
   
   
2. メトリックはやる気にさせる必要があります 。 まず、スプリントする時間がないことを示すことから始めました。 私たちは10％、20％間に合わなかったことが判明しました。 これはまったく動機付けではなく、オブザーバー効果はありません。
   
   

速度は遅れた指標であり、直接影響を与えることはできません。 それは何かを示していますが、速度に影響を与えることができるメトリックスがあります。 私の意見では、2つの主なものがあります：



1.評価タスクの精度。

ここで、最初の評価に応じてタスクの実際の時間を計算した担当アナリストディマの助けを借りました。





これは実際のデータです。 上の図はタスクを完了する実際の時間のグラフで、下の図は推定値です。



Joel Spolskyは、タスクごとに16時間が制限であると主張しています。 私たちにとっては、12時間後に評価が意味をなさないことは明らかであり、分散が大きすぎます。 私たちは本当にソフト制限を導入し、タスクを評価しないように12時間以上試みました。 その後、分解または追加調査のいずれか。



2.時間の消費。つまり、開発者が費やさない可能性のあるものに時間を費やす場合。

私たちのチームの1つでは、最大50％の時間がコミュニケーションに費やされました。 その理由を分析し、理解し始めました。 問題はプロセスにあることが判明しました。すべての顧客が開発者に直接質問し、質問をしました。 プロセスを少し変更し、この時間を短縮し、速度インジケーターを改善しました。



あなたの場合、これは必ずしも通信であるとは限りません。たとえば、配備やインフラストラクチャの時間になるかもしれません。 ただし、このための前提条件は、すべての開発者が時間を記録する必要があることです。 Jiraで時間を記録している人がいない場合、これを実装するのは明らかに非常に費用がかかります。

3.技術的負債への対処

「技術的義務」と言うとき、私はそれをぼやけたものとして視覚化します-それがどのように測定できるかは明らかではありませんか？





チームの1つで正確に648時間の技術的義務を負っている場合、あなたは私を信じません。 しかし、私たちがそれを測定するアルゴリズムを教えます。





四半期に一度、チーム全体としてリファクタリングミートアップと呼ばれます）カードを作成します：コードで松葉杖（私たちや他の人）が見たもの、疑わしい決定、その他の悪いこと（例えば、ライブラリの古いバージョン-何でも）。 これらのカードの束を生成した後、それぞれに解決策を書く-それをどうするか。 技術的な義務ではないため、またはライブラリのバージョンを更新したり、リファクタリングする必要があるなどの理由で、何もしないかもしれません。 次に、Jiraでチケットを作成します。「これは問題です。これが解決策です。」



そして今、私たちはJiraに150のチケットを持っています-それらをどうしますか？







その後、1人の開発者に対して10分かかるアンケートを実施します。 各開発者は1〜5の評価を与えます。1-「いつか次の人生でやる」、5-「今すぐやらなければならないので、かなり遅くなります。」 この評価をJiraのチケットに直接追加します。 「リファクタリングの優先度」と呼ばれるカスタムフィールドを作成し、優先度の高い技術的な負債と問題のリストを取得しました。 最初の10〜20を評価し、テールに平均評価を掛けると（150枚のチケットすべてを評価するには遅すぎます）、 技術的な負債が数時間で得られます。



なぜこれが必要なのですか？ この評価は四半期ごとに実施します。 第1四半期で700時間を過ごした後、たとえば800時間になった場合、すべて正常に動作しています。 そして、それが1400になった場合、脅威があることを意味し、リファクタリングの割り当てを増やす必要があります。これは、1か月またはすべての時間の40％をリファクタリングするというビジネスに同意するものです。



さて、技術的な負債の問題を解決しました。それは鍵と鍵の下にあります。





しかし、その発生につながる理由について話しましょう。 これはほとんどの場合、コードレビューが不十分です。

悪いコードレビュー

不十分なコードレビューの主な理由の1つは、バスファクターです。 bus-factorを形式化することを学びました 。 私たちはチームを取り、このチームに関連する分野のリストを書きます。たとえば、プラットフォームチームの場合は、ビデオコミュニケーション、演習の同期、ツールです。 各開発者は1〜3の評価を与えます。

• 1-「それが何であるかわかりません。何度か聞きました。」
• 2-「この領域からタスクを実行できます。」
• 3-「私はこの分野の超専門家です。」

興味深いことに、一部の分野ではチームに専門家が1人もいなかったため、これがどのように機能するのか誰も知りませんでした。



バス係数の問題をどのように解決しましたか？



次に、各エリアの中央値を計算し、定期的なチーム会議で一連のレポートを実施し、専門家がそれらのエリアについてチーム全体に話しました。 もちろん、この方法はあまりうまくスケーリングできませんが、まず、これらのレポートのビデオがあり、次に、非常に高速な方法です。 現在、チーム全体がビデオ通話の仕組みをある程度理解しています。 一部の領域では、まだドキュメントを作成していませんが、ドキュメントを作成するタスクを実行しています。 いつか書きます。





次に、十分な時間がない場合のコードレビューについて説明します。 現在、レビューコードレビューを行っている実験中です。 毎月末に、ランダムプルリクエストを選択し、開発者にコードレビューを再度行い、できるだけ多くの問題を見つけます。 したがって、誰かがあなたの後にダブルチェックすることを知っているとき、あなたはレビューに対してより敏感になります。 また、チェックリストも追加しました-ご覧になりましたか、これとあれ-一般的に、コードのレビューを改善するよう努めています。



それがすべて技術的な義務です。 最後の質問が残っています 。 すべてのチームがサプサンズであることを確認する方法です 。

4.すべてのチームをサプサンに変える

これを行う最も簡単な方法は、最初からです。 新しいチームが結成されたとき、特に新しいチームリーダーが到着して人材を採用したときは、すべてのプロセスについて同じクロスレビューを行います。 つまり、計画、最初の技術的ソリューション、技術スタック、すべてのプロセスなど、すべてをチェックするチームエキスパートを採用します。 したがって、作業を開始するチームに正しいベクトルを設定します。 費やした時間のために非常に高価ですが、それは報われます。



ここでも、一定の前提条件があります。GoogleSuiteを使用して、すべての会議をビデオに記録します。すべての会議、すべての計画、すべての回顧、いつでも確認できます。



2番目の安価な測定基準は、もちろんチェックリストです。





上記はチェックリストの例ですが、実際にはもっと長いです。 チームごとに、チームに自動テスト、継続的インテグレーションなどがあるかどうかを巨大なテーブルに記録します。



ただし、これらのチェックリストには問題があります。作成した翌日に期限が切れます。 管理アシスタントが問題の解決を支援します-これらは、日常的なタスクを設定できる人です。 タスクを設定し、更新できるものを自分で更新します。更新できない場合は、チームリーダーを更新します。 したがって、チェックリストの関連性を維持します。

まとめると

私たちは話しました：

• どのチームがうまく機能し、どのチームがうまく機能しないかを判断する方法。
• チームのリソースを評価し、時にはチームをスピードアップする方法。
• これらのチームが抱えている技術的負債を評価する方法。
• すべての新しいチームをPeregrine Falconsにする方法。

ボーナス

レポートには、アレクセイがリクエストに応じて共有する準備ができている資料は含まれていませんでした。

• QAメトリックは、すべてのチームをクールにするためのテストにおける10以上の異なるメトリックです。
• Skyengの誰もが試したすべてのメトリックのリスト。 これは単なるリストではなく、経験とコメント、さらにこれらのメトリックのいくつかの分類を含むリストです。
• Arsenyボットはオープンソースですぐに利用できるようになります。発生したらすぐに確認できます。

これらのリストを取得し、チームのパフォーマンスの評価の詳細については、Telegram（@ ax8080）またはFacebookで Alekseyにメールしてください。

2月25〜26日にモスクワで開催されるチームリーダーのためのTeamLead Conf 2019カンファレンスでの論文募集は既に開催されています。 レポートの提出方法と参加条件の概要は次のとおりです。 これは 、申し込みフォームへのリンクです。



そして私たちと一緒にいてください！ 開発チームの管理に関する記事とビデオを引き続き掲載します。 ニュースレターでは、有用な資料を数週間収集し、会議のニュースについて書きます。