분산된 팀이 중요한 이유와 구축 방법

“당신이 스타트업에 혼자 있고 파트너를 원한다고 가정해 봅시다. 파트너를 찾는 데 시간이 많이 걸리겠죠? 그는 당신 회사의 절반이 될 것입니다. 회사의 3분의 1, 4분의 1 또는 5분의 1을 찾는 데 시간을 덜 들여야 하는 이유는 무엇입니까? 스타트업에 있을 때 처음 10명의 사람이 회사의 성공 여부를 결정합니다. 각각은 회사의 10%입니다. 그렇다면 모든 A 플레이어를 찾는 데 필요한 만큼 많은 시간을 들이지 않겠습니까? 세 사람이 그렇게 위대하지 않다면 왜 당신의 직원 중 30%가 그렇게 위대하지 않은 회사를 원하겠습니까?” — 스티브 잡스

2003년 작가 마이클 루이스는 머니볼( Moneyball: Art of Winning an Unfair Game)이라는 책을 출판했습니다. 표면적으로 이 책은 고전적인 약자 이야기입니다. 고군분투하는 야구 팀은 수십 년의 지혜에 의존하는 인재 스카우트가 승리하는 팀을 구성할 기회를 놓치고 있다는 것을 깨닫습니다. 팀은 최신 도구와 관행을 통합하도록 스카우트 전술을 발전시켜 과소 평가된 선수 명단을 식별하고 고용하여 훨씬 더 많은 급여를 받는 상대를 상대로 승리 기록을 달성합니다.

Moneyball 의 진정한 교훈은 분명합니다. 당신이 대기업이든 당신보다 더 많은 비용을 지출할 수 있는 기존 기업보다 우위를 찾고 있는 초라한 신생 기업이든, 팀 구성에 대한 기존의 통념이 더 이상 현실을 반영하지 않을 때.

기업은 분산 팀을 사용하여 머니볼 게임을 합니다.

우리의 견해로는 조직이 ROI가 높은 인재를 찾는 데 "머니볼"을 할 수 있는 분명한 기회가 있습니다. 팀이 원격 직원을 고용할 수 있도록 권한을 부여하십시오.

미국 근로자의 43% 이상이 작년에 재택근무를 했으며, 이는 1995년의 9%에서 크게 증가한 수치입니다.

2016년, 직원 참여 회사인 TinyPulse는 500명 이상의 원격 직원을 대상으로 설문 조사를 실시한 결과, 그들이 현장 동료보다 더 행복하고, 더 가치 있고, 압도적으로 더 생산적이라는 사실을 발견했습니다. 지난 해 미국 근로자의 43% 이상이 재택근무를 했으며 이는 1995년의 9%에 비해 크게 증가한 수치입니다. 전체적으로 원격 근무를 허용하는 회사는 직원의 스트레스가 적고 효율성이 높으며 이직률이 낮습니다.

분산된 팀을 수용하도록 조직을 조정하는 것은 쉬운 일이 아닙니다. 그러나 우리가 보기에 현상 유지는 훨씬 더 큰 위험을 내포하고 있습니다. 우리는 원격으로의 전환에 저항하는 기업이 구식 인재 스카우트와 같다고 믿습니다. 그들은 20년 전의 건전한 조언에 따라 훌륭한 일을 하고 있습니다. 반면에, 원격 근무를 수용하는 조직은 돈싸움을 하고 있습니다. 모든 사람이 가까운 장래에 자신의 주도권을 따를 것이지만, 당분간은 상당한 경쟁 우위로 보상을 받습니다.

이 기사에서 우리는 분산된 팀에 대한 일반적인 반대 의견을 제시하고 채용, 올바른 측정 기준, 관리, 도구 및 문화 측정의 모범 사례를 다루는 5가지 권장 사항을 통해 이러한 함정을 해결한 경험을 공유합니다.

분산된 팀의 일반적인 문제

노련한 경영진은 초기 아웃소싱 시대의 경험에서 비롯된 분산 개발 팀에 대한 잔류 두려움을 가질 수 있습니다. 신임 경영진은 기존의 통념에 의존하여 원격 팀을 처리할 수 없게 만들고 싶어할 수 있습니다. 두 그룹 모두 다음과 같은 우려 사항을 인용하는 경향이 있습니다.

• 품질: 거의 20년 전에 분산된 팀에 대한 첫 번째 노출은 전적으로 비용 절감에 의해 주도된 전통적인 아웃소싱 모델의 맥락에서 발생했습니다. 협업이 불가능하다고 느꼈습니다. 오늘날 우리가 Slack이나 GitHub와 같이 당연하게 여겼던 도구가 없었고, 시간대 문제로 인해 이메일을 교환하는 데 며칠이 걸렸고, 대역폭이 비쌌습니다. 우리가 찾을 수있는 개발자는 형편없는 것으로 판명되었습니다.
• 가시성: 프로젝트 관리자는 놀라움을 싫어합니다. 공장장이 정기적으로 생산라인을 점검하거나, 현장의 트레일러에 앉아 공사장이 책상에 앉아 있는 것도 이 때문이다. 물론 좋은 Wi-Fi 연결이나 모바일 타워와의 근접성을 제외하고 소프트웨어 제품이나 전문 서비스 계약의 진행 상황을 검사하기 위해 물리적 근접성이 필요한 경우는 많지 않지만 모든 관리자 사이에서 존재는 여전히 중요합니다. 종류.
• Agile Orthodoxy: 많은 회사에서 Agile 변환을 고려하거나 적극적으로 구현하고 있습니다. 이러한 변화의 일환으로 그들은 Agile 서적, 코치 및 컨설팅 회사에서 경영진을 위한 지침을 찾는 경향이 있습니다. 팀을 구성할 때 이러한 전문가들은 "팀은 같은 위치에 있어야 합니다."라고 말하는 경향이 있습니다. 15년 전만 해도 이것은 건전한 조언이었습니다. 여러 면에서 Agile은 위의 조건에 대한 반응으로 원거리에서 협업이 거의 불가능했고 엄격한 폭포수 프로젝트 관리 관행이 필요했습니다.

협업 및 커뮤니케이션을 위한 향상된 기술 덕분에 이러한 문제를 야기한 조건은 더 이상 존재하지 않습니다. 아래에 요약된 5가지 모범 사례를 채택함으로써 조직은 고성능 분산 팀을 구축하고 원격 작업의 변형 가능성을 극대화할 수 있는 준비를 갖추게 됩니다.

1. 원격 호환성을 위해 고용

모든 사람이 원격 근무를 위해 만들어진 것은 아닙니다. 최고의 개발자에게 가치 있는 특성인 엔지니어링 및 기술 우수성, 팀 환경에서 잘 작동하는 능력, 개방적이고 정직한 커뮤니케이션에 대해 생각해 보십시오. 특히 소프트 스킬이 원격 환경에서 어떻게 번역되는지 평가하는 것은 어렵기 때문에 다음과 같은 몇 가지 특성을 찾아야 합니다.

• 사전 예방적: 물리적 근접성은 빈번한 체크인을 쉽게 합니다. 그 자원을 제외하고 최고의 고용자는 일을 완료하기 위해 할당된 작업이나 지속적인 지침이 필요하지 않은 스스로 시작하는 사람입니다.
• 무자비한 우선 순위 지정: 훌륭한 원격 근무자는 주어진 프로젝트에서 무엇이 중요하고 무엇이 중요하지 않은지 직관적으로 파악하여 중요한 것을 좁힙니다.
• 능숙한 작문 기술: 원격 팀의 의사 소통은 일반적으로 서면 형식을 취하므로 작문 기술은 원격 팀에 특히 중요합니다.

멀리 떨어진 슈퍼스타는 어디에서 찾을 수 있나요? 위의 특성을 가진 사람들은 일반적으로 비정형 환경에서 성과 기록을 구축할 수 있는 스타트업 배경 또는 이전 프리랜서 계약을 보유하고 있습니다.

2. 분산된 팀을 관리하려면 샌드박스를 만듭니다.

분산 개발 팀에 대해 자주 듣는 우려는 팀 규범, 코딩 표준 및 관행, 프로젝트 관리 프로세스를 시행하는 것이 어렵다는 것입니다. 우리의 경험에 따르면 생산적인 팀은 자체적으로 표준을 설정하는 데 있어 상당한 자유도를 갖고 권한이 부여되고 자치적입니다.

원격 팀도 예외는 아니지만 경영진은 통제가 제대로 이루어지도록 특별한 주의를 기울여야 합니다. 분산된 팀을 관리하는 일반적인 원칙으로 샌드박스의 비유를 사용합니다. 상자의 가장자리는 팀의 경계를 나타냅니다. 예를 들어 스프린트 행사, 사용할 도구 및 프레임워크, 코드 적용 기대치 등과 같이 합의된 제약 조건이 있습니다.

즉, 협업을 위한 프레임워크와 프로세스가 확고하게 정의되어야 하지만 소프트웨어 개발은 ​​과학만큼이나 예술이므로 원격 직원이 샌드박스 내에서 창의력을 발휘할 수 있는 여유를 갖는 것이 중요합니다.

3. 출력이 아닌 결과를 추적하도록 관리자 교육

의식적이든 아니든 일부 관리자는 업무의 결과가 아니라 책상에서 보낸 시간으로 생산성을 측정합니다. 그러나 수천 줄의 하위 코드를 생성하는 개발자가 같은 기간에 수백 줄의 우수한 코드를 생성하는 개발자보다 더 생산적인 것으로 간주되어서는 안 됩니다.

특히 원격 팀의 경우 생산성 지표가 단순한 출력이 아닌 결과의 품질을 측정하는 것이 중요합니다. 지난 달에 얼마나 좋은 소프트웨어를 출하했습니까? 개발 속도가 안정적이고 예측 가능하며 시간이 지남에 따라 가속화되고 있습니까? 팀이 지속적인 개선을 보여주고 있습니까? 관리자는 작업 자체를 수행하는 과정에 대한 가시성이 부족하고 직원이 "작업을 보여주는" 것을 관찰하여 부분적으로 인정할 방법이 없기 때문에 원격 팀은 올바른 측정 기준에 대해 평가해야 합니다.

4. 올바른 도구 사용

도구는 오늘날 원격 작업이 번창하는 주된 이유입니다. 최신 커뮤니케이션 및 협업 앱은 분산된 팀이 이전 시대의 함정을 해결할 수 있도록 지원하는 발판입니다. 우리는 사람들이 Slack을 사용할 때 사무실에 있다고 말하고 싶습니다. 필수 도구 목록은 다음과 같습니다.

• 실시간 채팅: 실시간 채팅은 원격 팀에 필수적인 도구입니다. 배치된 팀에서 수행할 수 있는 즉각적인 상호 작용 및 협업을 복제할 수 있기를 원합니다. 실시간 채팅은 커뮤니케이션에 필수적일 뿐만 아니라 원격 문화 구축에도 도움이 됩니다. 이것이 성공하려면 모든 팀 커뮤니케이션이 한 곳에서 중앙 집중화되는 것이 중요합니다. 샌드박스에는 벽이 필요합니다. Toptal에서는 Slack을 사용하지만 대안으로는 HipChat, Flowdock 및 Skype가 있습니다.
• 정보 전달자: 정보 를 공유하기 위한 대면 상호 작용이 없으면 팀에 정보를 전달하기 위한 온라인 위키와 스토리 월이 필요합니다. Agile 또는 Kanban 개발에서 전체 팀 및 모든 관련 이해 관계자는 진행 중인 스토리, 테스트 대기 중, 결함 등 개발 상태에 대한 즉각적인 정보에 액세스할 수 있어야 합니다. 또한 팀은 빌드 파이프라인 및 상태, 코드 적용 범위 및 기타 주요 데이터. 원격 관리자는 팀과 이해 관계자가 상태에 대해 의존하는 정보의 각 영역에 대한 단일 정보 소스를 원합니다.
• 화상 회의: 실시간 화상 채팅은 인스턴트 메시징을 보완하는 필수 요소입니다. 경험상 실제로 다른 사람과 대화하는 것과 같은 것은 없습니다. Toptal에서는 Zoom, Slack 통화, 때때로 Skype를 일대일, 상태 회의 및 코드 쇼케이스에 사용합니다. 화상 회의를 통한 일일 스크럼 스탠드업은 팀 문화와 신뢰를 구축하는 좋은 방법입니다.

5. 축하 행사

계획 및 평가 회의, 코드 검토, 소프트웨어 데모와 같이 각 스프린트의 고정된 지점에서 여러 팀 행사가 있을 것입니다. 위치에 관계없이 모든 팀 구성원이 참여할 수 있도록 일정을 잡습니다. 이상적으로는 팀이 하루에 몇 시간씩 온라인 상태로 작업하는 것이 좋습니다.

분산된 팀을 구축할 때 시간대에 대해 걱정하는 것은 자연스러운 일이지만, 경험상 원격 소프트웨어 개발 분야에서 경력을 선택한 많은 사람들은 전통적인 9-5 근무일 외에 작업하는 것을 선호하며 허용되면 훨씬 더 생산적입니다. 그렇게 하기 위해. 가능한 한 최대한 팀이 자신에게 가장 적합한 시간을 정의할 수 있도록 하십시오.

결론: 이미 분산된 팀에 의존하고 있을 수 있습니다.

조직에서 분산 개발 모델을 직접 활용하지 않았더라도 그 이점을 상당 부분 활용하고 있을 것입니다. 오픈 소스 소프트웨어를 사용하고 있을 가능성이 높습니다.

그 특성상 오픈 소스 개발은 처음부터 배포되었습니다. 오픈 소스 세계의 혁신은 엄청난 속도로 이루어지며, 진화하는 엔지니어링 방식은 그 속도를 높이는 데 도움이 됩니다. 초기 오픈 소스 프로젝트가 해결한 첫 번째 과제 중 하나는 분산된 팀을 위한 온라인 협업과 프로세스의 투명성이었습니다.

당신이 오픈 소스 세계의 선두를 따르고 있든, 인재 중심의 소프트웨어 개발 및 전문 서비스 세계에서 Michael Lewis의 지시를 따랐든, 조직에 부과하는 제약을 고려하십시오. 지역 인재 풀에서만 고용할 수 있습니다.

이러한 규모의 문화적 변화는 중요한 작업이지만 즉시 전환을 시작할 수 있습니다. 사무실의 정통성을 버리고 분산된 팀을 환영하며 팀 구성원에게 메트릭, 관리 , 도구 및 문화를 통해 작업을 수행할 수 있습니다.