개발팀의 "보편적": 이익인가 해로움인가?

안녕하세요 여러분! 제 이름은 Lyudmila Makarova이고 UBRD의 개발 관리자이며 팀의 XNUMX분의 XNUMX은 "일반주의자"입니다.

인정하세요. 모든 기술 책임자는 팀 내에서 다양한 기능을 지원하는 것을 꿈꿉니다. 한 사람이 XNUMX명을 대체할 수 있고 마감 기한을 지체하지 않고 효율적으로 수행할 수 있다는 것은 정말 멋진 일입니다. 그리고 가장 중요한 것은 자원을 절약한다는 것입니다!
매우 유혹적으로 들리지만 정말 그렇습니까? 그것을 알아 내려고 노력합시다.

우리 기대의 선구자, 그는 누구인가?

"일반주의자"라는 용어는 일반적으로 개발자-분석가와 같이 둘 이상의 역할을 결합하는 팀 구성원을 나타냅니다.

팀의 상호 작용과 작업 결과는 참가자의 직업적, 개인적 자질에 따라 달라집니다.

하드 스킬에 관한 모든 것이 명확하지만 소프트 스킬에 특별한 관심을 기울일 가치가 있습니다. 그들은 직원에 대한 접근 방식을 찾고 직원이 가장 유용할 작업으로 안내하는 데 도움을 줍니다.

IT 업계에는 다양한 성격 유형에 관한 기사가 많이 있습니다. 내 경험을 바탕으로 IT 일반직을 네 가지 범주로 분류하겠습니다.

1. “보편적 – 전능하신”

이것들은 어디에나 있습니다. 그들은 항상 매우 활동적이며 관심의 중심이 되고 싶어하며 동료에게 도움이 필요한지 끊임없이 묻고 때로는 짜증을 낼 수도 있습니다. 그들은 창의성을 발휘할 여지를 주고 자부심을 즐겁게 할 수 있는 의미 있는 작업, 참여에만 관심이 있습니다.

그들의 강점은 무엇입니까?

• 복잡한 문제를 해결할 수 있습니다.
• 문제에 깊이 빠져들어 “파고” 결과를 얻습니다.
• 궁금한 마음을 가지세요.

하지만 :

• 감정적으로 불안정하다;
• 제대로 관리되지 않음;
• 흔들리지 않는 관점을 가지고 있으며 변경하기가 매우 어렵습니다.
• 누군가에게 간단한 일을 하게 하는 것은 어렵습니다. 쉬운 일이 전능자의 자존심을 상하게 합니다.

2. “만능 – 내가 알아서 할게”

그러한 사람들에게는 매뉴얼과 약간의 시간만 있으면 문제를 해결할 수 있습니다. 그들은 일반적으로 DevOps에 대한 강력한 배경 지식을 가지고 있습니다. 이러한 제너럴리스트는 디자인에 신경을 쓰지 않고 오직 경험에 기초한 개발 방식을 선호합니다. 그들은 작업 구현을 위해 선택한 옵션에 대해 기술 책임자와 쉽게 논의할 수 있습니다.

그들의 강점은 무엇입니까?

• 독립적인;
• 스트레스에 강한;
• 많은 문제에 능숙합니다.
• 박식한-항상 그들과 이야기 할 것이 있습니다.

하지만 :

• 종종 의무를 위반합니다.
• 모든 것을 복잡하게 만드는 경향이 있습니다. 부분별로 적분하여 구구단을 푸세요.
• 작업의 질이 낮고 모든 것이 2-3 번 작동합니다.
• 실제로 모든 것이 그렇게 간단하지 않은 것으로 밝혀지기 때문에 끊임없이 마감일을 변경합니다.

3. "유니버설 - 알았어, 내가 할게, 아무도 없으니까"

직원은 여러 분야에 정통하고 관련 경험을 가지고 있습니다. 그러나 그는 그 중 어떤 분야에서도 전문가가 되지 못합니다. 왜냐하면 그는 종종 현재 업무에 구멍을 뚫고 생명선으로 사용되기 때문입니다. 유연하고 효율적이며 자신이 수요가 있다고 생각하지만 그렇지 않습니다.

실용적인 이상적인 직원. 아마도 그는 자신이 가장 좋아하는 방향이 있지만 역량이 흐려져 발전이 이루어지지 않습니다. 결과적으로 사람은 소유권을 주장하지 못하고 감정적으로 지칠 위험이 있습니다.

그들의 강점은 무엇입니까?

• 책임이 있는;
• 결과 지향적;
• 침착한;
• 완전히 통제됩니다.

하지만 :

• 낮은 수준의 역량으로 인해 평균 결과를 보여줍니다.
• 복잡하고 추상적인 문제를 해결할 수 없습니다.

4. “다재다능한 사람은 자신의 기술의 달인이다”

개발자로서 진지한 배경을 가진 사람은 시스템 사고를 가지고 있습니다. 현학적이며 자신과 팀을 요구합니다. 그와 관련된 모든 작업은 경계가 정의되지 않으면 무한정 성장할 수 있습니다.

그는 아키텍처에 대해 잘 알고 있으며 기술 구현 방법을 선택하고 선택한 솔루션이 현재 아키텍처에 미치는 영향을 신중하게 분석합니다. 겸손하고 야심적이지 않습니다.

그들의 강점은 무엇입니까?

• 높은 작업 품질을 보여줍니다.
• 어떤 문제라도 해결할 수 있다.
• 매우 효율적입니다.

하지만 :

• 다른 사람의 의견을 용납하지 않습니다.
• 극대주의자. 그들은 모든 일을 제대로 하려고 노력하며 이로 인해 개발 시간이 늘어납니다.

실제로 우리는 무엇을 가지고 있습니까?

역할과 역량이 가장 자주 결합되는 방식을 살펴보겠습니다. PO, 개발 관리자(기술 리드), 분석가, 프로그래머, 테스터 등 표준 개발 팀을 출발점으로 삼아 보겠습니다. 우리는 제품 소유자와 기술 책임자를 고려하지 않습니다. 첫째는 기술 역량이 부족하기 때문이다. 둘째, 팀에 문제가 있으면 뭐든지 할 수 있어야 한다.

역량을 결합/병합/결합하는 가장 일반적인 옵션은 개발자-분석가입니다. 테스트 분석가와 "XNUMX in XNUMX"도 매우 일반적입니다.

우리 팀을 예로 들어 동료 제너럴리스트들의 장단점을 보여 드리겠습니다. 우리 팀에는 그들 중 XNUMX분의 XNUMX이 있는데 나는 그들을 매우 사랑합니다.

PO는 기존 제품에 새로운 관세를 도입하는 긴급 임무를 받았습니다. 우리 팀에는 4명의 분석가가 있습니다. 당시 한 명은 휴가 중이었고 다른 한 명은 아프고 나머지는 전략 과제 수행에 참여했습니다. 내가 그것들을 빼낸다면 필연적으로 구현 기한을 방해하게 될 것입니다. 탈출구는 단 하나뿐이었습니다. 필요한 주제 영역을 마스터한 다재다능한 개발자 분석가인 "비밀 무기"를 사용하는 것입니다. 그를 아나톨리라고 부르자.

그의 성격 유형은 “보편적, 내가 알아서 할게”. 물론 그는 오랫동안 자신이 "자신의 업무가 꽉 찼다"고 설명하려고 노력했지만 나의 강한 의지로 긴급한 문제를 해결하기 위해 파견되었습니다. 그리고 아나톨리는 해냈습니다! 스테이징을 진행하고 제 시간에 구현을 완료해 고객들이 만족해 했습니다.

언뜻보기에 모든 것이 잘되었습니다. 그러나 몇 주 후에 이 제품에 대한 개선 요구 사항이 다시 발생했습니다. 이제 이 문제의 공식화는 "순수한" 분석가에 의해 수행되었습니다. 새로운 개발을 테스트하는 단계에서 우리는 새로운 관세를 연결하는 데 왜 오류가 발생하는지 오랫동안 이해할 수 없었고, 그제서야 전체 얽힌 부분을 풀어 진실의 바닥에 도달했습니다. 우리는 많은 시간을 낭비했고 마감일을 놓쳤습니다.

문제는 숨겨진 많은 순간과 함정이 우리 스테이션 왜건의 머리에만 남아 있고 종이로 옮겨지지 않는다는 것입니다. 나중에 Anatoly가 설명했듯이 그는 너무 서두르고 있었습니다. 그러나 가장 가능성이 높은 선택은 개발 중에 이미 문제를 발견하고 이를 어디에도 반영하지 않고 간단히 우회하는 것입니다.

또 다른 상황이있었습니다. 이제 테스터는 한 명뿐이므로 일부 작업은 일반 전문가를 포함한 분석가가 테스트해야 합니다. 따라서 나는 조건부 Fedor에게 한 가지 작업을주었습니다. "보편적 - 알았어, 내가 할게, 아무도 없으니까".
Fedor는 "XNUMX in XNUMX"이지만 이 작업을 위해 이미 개발자가 할당되었습니다. 즉, Fedya는 분석가와 테스터만 결합해야 했습니다.

요구사항이 수집되었고 사양이 개발에 제출되었으므로 이제 테스트할 시간입니다. Fedor는 시스템이 "손등처럼" 마무리되는 것을 알고 있으며 현재 요구 사항을 철저히 해결했습니다. 그래서 그는 테스트 스크립트 작성에 신경 쓰지 않고 "시스템이 어떻게 작동해야 하는가"에 대한 테스트를 수행하고 이를 사용자에게 전달했습니다.
테스트가 완료되고 수정본이 생산되었습니다. 나중에 시스템이 특정 잔액 계정에 대한 지불을 중단했을 뿐만 아니라 이에 참여해서는 안 되는 매우 드문 내부 계정의 지불도 차단한 것으로 밝혀졌습니다.

이는 Fedor가 "시스템이 작동하지 않아야 하는 방법"을 확인하지 않았고 테스트 계획이나 체크리스트를 작성하지 않았기 때문에 발생했습니다. 그는 타이밍을 아끼고 자신의 본능에 의존하기로 결정했습니다.

우리는 문제를 어떻게 처리합니까?

이러한 상황은 팀 성과, 릴리스 품질 및 고객 만족도에 영향을 미칩니다. 따라서 이유에 대한 관심과 분석 없이는 방치할 수 없습니다.

1. 어려움을 야기한 각 작업에 대해 통일된 양식, 즉 "감소"가 발생한 단계를 식별할 수 있는 오류 지도를 작성해 주시기 바랍니다.

2. 병목 현상을 파악한 후 문제에 영향을 준 각 직원과 함께 브레인스토밍 세션을 진행합니다. “무엇을 바꿔야 할까요?” (회고하여 특별한 경우를 고려하지 않습니다), 그 결과 마감일이 있는 특정 행동(각 성격 유형에 따라 다름)이 탄생합니다.

3. 우리는 팀 내 상호 작용에 대한 규칙을 도입했습니다. 예를 들어, 우리는 프로젝트 관리 시스템의 작업 진행 상황에 대한 모든 정보를 반드시 기록하기로 합의했습니다. 개발 과정에서 아티팩트가 변경/식별되면 이를 지식 베이스와 기술 사양의 최종 버전에 반영해야 합니다.

4. 제어는 각 단계에서 수행되기 시작했으며(과거 문제가 발생한 단계에 특별한 주의를 기울임) 다음 작업의 결과에 따라 자동으로 수행되었습니다.

5. 다음 작업의 결과가 변하지 않았다면 나는 제너럴리스트가 제대로 대처하지 못하는 역할에 문제를 두지 않습니다. 나는 이 역할에서 역량을 개발하려는 그의 능력과 열망을 평가하려고 노력합니다. 반응이 없으면 그 사람에게 더 가까운 역할에 맡긴다.

결국 무슨 일이 일어 났니?

개발 과정이 더욱 투명해졌습니다. BUS 요소가 감소했습니다. 실수를 해결하기 위해 노력하는 팀원은 더 많은 동기를 부여받고 카르마를 향상시킵니다. 우리는 릴리스의 품질을 점차적으로 개선하고 있습니다.

조사 결과

일반 직원에게는 장단점이 있습니다.

장점 :

• 언제든지 늘어진 작업을 종료하거나 짧은 시간 안에 긴급한 버그를 해결할 수 있습니다.
• 문제 해결을 위한 통합적 접근 방식: 수행자는 모든 역할의 관점에서 문제를 봅니다.
• 일반주의자는 거의 모든 일을 동등하게 잘 할 수 있다.

단점 :

• BUS 요소가 증가합니다.
• 역할에 내재된 핵심 역량이 침식됩니다. 이로 인해 작업의 질이 저하됩니다.
• 마감일 변경 가능성이 높아지기 때문입니다. 각 단계에는 제어가 없습니다. "스타"로 성장하는 데에는 위험도 있습니다. 직원은 자신이 전문가라는 사실을 더 잘 알고 있다고 확신합니다.
• 직업적 소진의 위험이 증가합니다.
• 프로젝트에 관한 많은 중요한 정보는 직원의 "머리 속에"만 남을 수 있습니다.

보시다시피 단점이 더 많습니다. 따라서 자원이 충분하지 않고 작업이 매우 긴급한 경우에만 제너럴리스트를 사용합니다. 또는 다른 사람이 부족한 역량을 가지고 있지만 품질이 문제가 됩니다.

작업에 대한 공동 작업에서 역할 분배 규칙을 준수하면 작업의 질이 향상됩니다. 우리는 문제를 다양한 각도에서 바라보고, 시야가 흐릿해지지 않으며, 항상 신선한 생각이 떠오릅니다. 동시에 각 팀원은 전문적인 성장과 역량 확장을 위한 모든 기회를 갖습니다.

가장 중요한 것은 프로세스에 참여하고, 업무를 수행하며, 점차적으로 역량의 폭을 넓히는 것이라고 믿습니다. 그러나 팀의 제너럴리스트는 이점을 제공합니다. 가장 중요한 것은 서로 다른 역할을 효과적으로 결합하는 것입니다.

나는 모든 사람이 "자신의 기술의 보편적인 대가"로 구성된 자체 조직 팀을 갖기를 바랍니다!

출처 : habr.com