開発チームにおける「普遍性」：利益か害か？

こんにちは、みんな！ 私の名前はリュドミラ・マカロワです。UBRD の開発マネージャーで、チームの XNUMX 分の XNUMX は「ゼネラリスト」です。

それを認めてください。すべての Tech Lead は、チーム内で部門を越えて活躍することを夢見ています。 XNUMX 人で XNUMX 人の代わりを務めることができ、さらには納期を遅らせることなく効率的に仕事を進めることができるのは、とても素晴らしいことです。 そして重要なことに、それはリソースを節約します。
とても魅力的に聞こえますが、本当にそうなのでしょうか？ それを理解してみましょう。

私たちの期待の先駆者である彼は誰ですか？

「ジェネラリスト」という用語は通常、開発者とアナリストなど、複数の役割を兼ね備えたチーム メンバーを指します。

チームの相互作用とその仕事の結果は、参加者の専門的および個人的な資質によって異なります。

ハードスキルについては明らかですが、ソフトスキルには特に注意が必要です。 これらは、従業員へのアプローチを見つけて、従業員が最も役立つタスクに導くのに役立ちます。

IT 業界のあらゆる種類の性格タイプに関する記事がたくさんあります。 私の経験に基づいて、IT ジェネラリストを XNUMX つのカテゴリーに分類します。

1.「ユニバーサル・オールマイティ」

これらはどこにでもあります。 彼らは常に非常に活発で、注目の的になりたがり、常に同僚に助けが必要かどうかを尋ね、時には迷惑になることさえあります。 彼らは有意義な仕事だけに興味があり、それに参加すると創造性の余地が生まれ、彼らのプライドを楽しむことができます。

彼らの強みは何ですか:

• 複雑な問題を解決できる。
• 問題を深く掘り下げて「掘り下げ」、結果を達成します。
• 探究心を持っています。

しかし：

• 感情的に不安定。
• 管理が不十分です。
• 独自の揺るぎない視点を持っていますが、それを変えるのは非常に困難です。
• 簡単なことを人にやってもらうのは難しい。 簡単な仕事は全能者のエゴを傷つけます。

2.「ユニバーサル – 私が考えてやってみます」

そのような人はマニュアルと少しの時間を必要とするだけで、問題を解決してくれるでしょう。 彼らは通常、DevOps の強力なバックグラウンドを持っています。 このようなジェネラリストは、設計に煩わされることはなく、自分の経験のみに基づいた開発方法を使用することを好みます。 タスクを実装するために選択したオプションについて、技術責任者と簡単に話し合うことができます。

彼らの強みは何ですか:

• 独立した;
• ストレス耐性がある。
• 多くの問題において有能である。
• 博学 - 彼らと話すことは常にあります。

しかし：

• しばしば義務に違反します。
• すべてを複雑にする傾向があります。九九を部分ごとに積分して解きます。
• 仕事の質は低く、すべてが2〜3回機能します。
• 実際にはすべてがそれほど単純ではないことが判明するため、彼らは常に締め切りを変更します。

3. 「ユニバーサル – 分かった、やらせてもらう、他に誰もいないから」

従業員はいくつかの分野に精通しており、関連する経験があります。 しかし、彼はどの分野でもプロフェッショナルにはなれません。なぜなら、彼はしばしば現在の仕事の穴を塞ぐ命綱として使われるからです。 柔軟で効率的で、自分自身に需要があると考えていますが、実際はそうではありません。

現実的な理想的な社員。 おそらく、彼には自分の最も好きな方向性があるのですが、能力が曖昧なため、開発が行われません。 その結果、人は要求を受けられなくなり、感情的に燃え尽きてしまう危険があります。

彼らの強みは何ですか:

• 責任者;
• 結果志向。
• 落ち着いた;
• 完全にコントロールされている。

しかし：

• 能力レベルが低いために平均的な結果を示す。
• 複雑で抽象的な問題を解決することはできません。

4. 「オールラウンダーは自分の技術の達人である」

開発者としての本格的なバックグラウンドを持つ人は、システム思考を持っています。 衒学的で、自分自身にもチームにも要求が厳しい。 境界が定義されていない場合、彼が関わるタスクは無限に大きくなる可能性があります。

彼はアーキテクチャに精通しており、技術的な実装方法を選択し、選択したソリューションが現在のアーキテクチャに与える影響を注意深く分析しています。 控えめで、野心的ではありません。

彼らの強みは何ですか:

• 仕事の質の高さを示す。
• あらゆる問題を解決できる。
• 非常に効率的です。

しかし：

• 他人の意見に不寛容。
• マキシマリスト。 彼らはすべてを正しくやろうとするため、開発時間が長くなります。

実際には何ができるでしょうか？

役割とコンピテンシーが最も頻繁にどのように組み合わされるかを見てみましょう。 出発点として標準的な開発チームを考えてみましょう: PO、開発マネージャー (技術リード)、アナリスト、プログラマー、テスター。 プロダクトオーナーやテクニカルリードは考慮しません。 XNUMXつ目は技術力の不足によるものです。 XNUMX人目は、チーム内に問題がある場合、すべてを行うことができる必要があります。

コンピテンシーを結合/統合するための最も一般的なオプションは、開発者とアナリストです。 テストアナリストと「スリーインワン」も非常に一般的です。

私のチームを例​​として、同僚のゼネラリストの長所と短所を示します。 私のチームには彼らの XNUMX 分の XNUMX がいますが、私は彼らをとても愛しています。

PO は、既存の製品に新しい関税を導入するという緊急の任務を受けました。 私のチームにはアナリストが 4 人います。 当時、XNUMX人は休暇中で、もうXNUMX人は病気で、残りは戦略的任務の遂行に従事していた。 それらを撤回すると、実装期限に混乱が生じるのは避けられません。 唯一の解決策は、「秘密兵器」、つまり必要な主題分野を習得した多才な開発者兼アナリストを使用することです。 彼をアナトリーと呼びましょう。

彼の性格タイプは、 「普遍的 – 私が考えてやってみます」。 もちろん、彼は長い間「自分の仕事が山積みになっている」と説明しようとしてきましたが、私の強い意志により、彼は緊急の問題を解決するために派遣されることになりました。 そしてアナトリーはそれをやった！ 彼はステージングを実行し、予定通りに実装を完了し、顧客は満足しました。

一見したところ、すべてがうまくいきました。 しかし、数週間後、この製品には再び改善の必要性が生じました。 さて、この問題の定式化は「純粋な」アナリストによって実行されました。 新しい開発をテストする段階では、なぜ新しい関税の関連付けに誤りがあるのか​​、長い間理解できませんでしたが、そのとき初めて、すべての絡み合いを解き明かして、真実の底に到達しました。 私たちは多くの時間を無駄にし、締め切りに間に合わなかった。

問題は、多くの隠された瞬間や落とし穴がステーションワゴンの先頭部分にのみ残され、紙に転写されなかったことです。 アナトリーが後で説明したように、彼はあまりにも急いでいたのです。 しかし、最も可能性の高い選択肢は、彼が開発中にすでに問題に遭遇し、それをどこにも反映せずに単純に回避したということです。

別の状況もありました。 現在、テスターは XNUMX 人しかいないため、一部のタスクはゼネラリストを含むアナリストがテストする必要があります。 したがって、私は条件付きのヒョードルにXNUMXつのタスクを与えました - 「ユニバーサル – わかりました、他に誰もいないのでやらせてください」.
ヒョードルは「XNUMX in XNUMX」ですが、開発者はすでにこのタスクに割り当てられています。 これは、Fedya がアナリストとテスターのみを組み合わせる必要があったことを意味します。

要件が収集され、仕様が開発に提出され、テストの時間になりました。 ヒョードルはシステムが「手の甲のように」変更されることを知っており、現在の要件を徹底的に検討しました。 そこで彼は、わざわざテストスクリプトを書くのではなく、「システムがどのように動作するか」をテストし、それをユーザーに渡しました。
テストが完了し、リビジョンが本番環境に移行しました。 その後、システムが特定の残高口座への支払いを停止しただけでなく、これに参加するはずのない非常にまれな内部口座からの支払いもブロックしたことが判明しました。

これは、ヒョードルが「システムがどのように機能してはいけないのか」を確認せず、テスト計画やチェックリストを作成しなかったという事実によって起こりました。 彼はタイミングを逃さず、自分自身の直感に頼ることに決めました。

問題にどう対処すればよいでしょうか?

このような状況は、チームのパフォーマンス、リリースの品質、顧客満足度に影響を与えます。 したがって、その理由を注意して分析せずに放置することはできません。

1. 問題の原因となったタスクごとに、統一されたフォーム、つまり「ドローダウン」が発生した段階を特定できるエラー マップに記入するようお願いします。

2. ボトルネックを特定した後、問題に影響を与えた各従業員とのブレーンストーミング セッションが開催されます。「何を変更するか?」 （過去を振り返る特別なケースは考慮しません）、その結果、期限付きの特定の行動（各性格タイプに固有）が生まれます。

3. チーム内の交流に関するルールを導入しました。 たとえば、タスクの進捗状況に関するすべての情報をプロジェクト管理システムに必ず記録することに同意しました。 開発プロセス中に成果物が変更/特定された場合、これをナレッジ ベースと技術仕様の最終バージョンに反映する必要があります。

4. 制御は各段階（従来は問題のある段階に特に注意が払われていました）で実行され、次のタスクの結果に基づいて自動的に実行され始めました。

5. 次のタスクの結果が変わらない場合、私は問題のゼネラリストを、うまく対処できない役割に就かせることはしません。 私は彼の能力と、この役割において能力を開発したいという意欲を評価しようとしています。 反応が見つからない場合は、彼に近い役割を任せます。

最後に何が起こったのか？

開発プロセスの透明性がさらに高まりました。 BUS係数が減少しました。 チームメンバーは間違いに取り組むことで、よりモチベーションが高まり、カルマが改善されます。 私たちはリリースの品質を徐々に向上させています。

所見

ゼネラリスト社員にはメリットとデメリットがあります。

利点：

• 滞っているタスクをいつでも閉じたり、緊急のバグを短時間で解決したりできます。
• 問題を解決するための統合的なアプローチ: 出演者はすべての役割の観点から問題を検討します。
• ジェネラリストは、ほぼすべてのことを同じようにうまくこなすことができます。

短所：

• BUS 係数が増加します。
• その役割に固有の中核となる能力が損なわれます。 このため、仕事の質は低下します。
• 期限が変更される可能性が高くなります。 各段階での制御はありません。 「スター」を育てるにはリスクもあります。従業員は自分がプロであることをよく知っていると自信を持っています。
• 職業上の燃え尽き症候群のリスクが高まります。
• プロジェクトに関する多くの重要な情報は、従業員の「頭の中」にしか残らない可能性があります。

ご覧のとおり、さらに欠点があります。 したがって、私は十分なリソースがなく、タスクが非常に緊急である場合にのみジェネラリストを使用します。 あるいは、ある人は他の人にはない能力を持っていますが、その質が危機に瀕しています。

共同作業で役割分担のルールが守られていれば、仕事の質は高まります。 私たちは問題をさまざまな角度から見るので、視界がぼやけることなく、常に新鮮な考えが生まれます。 同時に、各チームメンバーには専門的な成長と能力の拡大のためのあらゆる機会が与えられます。

最も重要なことは、プロセスに参加していると感じて仕事に取り組み、徐々に能力の幅を広げていくことだと私は信じています。 ただし、チーム内のジェネラリストには利点があります。主なことは、さまざまな役割を効果的に組み合わせることができることです。

皆さんが「自分の技術の世界的達人」で構成される自己組織化されたチームになることを願っています。

出所： habr.com