효과적인 개발 팀을 만드는 요소

원문 :  효과적인 개발 팀을 만드는 요소 | 저스틴 조이스 (justinjoyce.dev)

What makes an effective development team | Justin Joyce

좋은 팀은 신뢰가 있고, 나쁜 팀은 비난만 있습니다.

 

6명에서 1000명 이상의 규모에 이르는 회사에서 엔지니어로 수년 동안 일한 후, 저는 많은 팀에서 일했습니다. 좋은 팀들은 매우 비슷했고, 나쁜 팀들은 각자 나름대로 나빴다. 이 게시물은 좋은 팀을 좋게 만든 이유를 설명합니다.

트러스트

신뢰는 좋은 팀의 기반입니다. 팀원들이 자신이 무엇을 하고 있는지 알고 있고, 여러분과 같은 기준을 따르고 있으며, 관심을 갖고 있다는 것을 믿어야 합니다. 그들은 보살핌을 받을 필요도 없고, 회사의 사명에 따라 살아 숨 쉬고 있을 필요도 없지만, 양질의 업무를 제공하는 데 신경을 써야 합니다.

프로덕션 사고가 발생하면 "현장에 있는" 팀원이 실제로 현장에 있다는 것을 신뢰할 수 있어야 합니다. 그들은 개인적으로 문제를 해결할 수 없을지 모르지만 상황을 처리하고 적절한 사람들을 신속하게 참여시킬 수 있어야 합니다.

버그가 있을 때, 버그를 고쳤다고 말하는 사람이 실제로 버그를 고쳤다는 것을 신뢰할 수 있어야 합니다. 우리 모두는 "오, 잘됐어, X가 고쳤어"라는 말을 듣고 더 이상 질문하지 않는 사람/팀을 만난 적이 있습니다. 내가 속해 있던 최고의 팀은 모두 X와 같은 사람들로 구성되어 있었다.

팀원의 업무를 신뢰하는 것과 함께 팀원을 사람으로 신뢰할 수 있어야 합니다. 저는 경력의 대부분을 어떤 형태로든 애자일 분야에서 일했는데, 이는 스프린트나 큰 프로젝트 후에 (대부분) 회고 회의를 가졌다는 것을 의미합니다. 최고의 팀은 회의에서 자신의 감정을 솔직하게 표현하는데, 이는 나머지 팀원들이 자신의 말을 경청하고 가능하다면 자신을 괴롭히는 문제를 해결하는 데 도움을 줄 것이라고 믿기 때문입니다. 저는 이러한 토론을 통해 만들어진 작업, 즉 팀원들이 말하는 것을 불편해하지 않았다면 일어나지 않았을 수도 있는 가치 있는 작업에 전체 스프린트를 할애했습니다.

신뢰는 어렵습니다. 벌어야 하는데 쉽게 잃어버린다2. 하지만 제가 몸담았던 모든 좋은 팀에서는 그것이 매우 중요했습니다.

존중

존중과 신뢰는 밀접하게 관련되어 있으며, 둘 중 하나가 없으면 다른 하나를 갖기가 어렵습니다.

유능한 팀에서도 항상 순조로운 항해는 아닙니다. 모든 사람은 자신의 의견을 가지고 있으며, 우리 모두, 특히 엔지니어는 자신이 옳다고 생각합니다3. 즉, 논쟁이 일어날 수밖에 없다는 뜻입니다. 좋은 팀에 대해 내가 느낀 점은 논쟁이 격화되더라도 항상 존중한다는 것입니다. 사람들은 격렬하게 동의하지 않을 수 있지만, 그들은 그것을 개인적인 것으로 만들지 않고 일에 집중합니다. 사실, 이러한 의견 불일치는 종종 "정확히 왜 이 기능을 구축하고 있는가? 다른 곳에서 시간을 보내는 것이 더 낫지 않을까요?" 팀은 이러한 대화를 나눌 수 있어야 하며, 존중하지 않으면 빠르게 비생산적이 될 수 있습니다.

소통과 협업

모든 관계에서 커뮤니케이션은 핵심입니다. 원격 근무의 시대에는 원격 근무가 훨씬 더 중요하고 잘하기가 더 어렵습니다. 문제를 해결하는 데 도움을 주거나 누군가와 프로그램을 화면 공유 및 페어링할 수 있다는 것은 엄청난 일입니다. 소프트웨어 엔지니어링의 세계는 방대하고 아무도 모든 것을 아는 사람은 없지만 팀의 엔지니어 전체에는 많은 지식이 있습니다. 기꺼이 요청해야 하고, 팀원도 기꺼이 도와야 합니다.

도움을 요청하는 것은 신입 엔지니어가 어려움을 겪을 수 있는 일입니다. 정말 막혔을 때를 아는 것은 생각보다 어렵지만 귀중한 엔지니어링 기술입니다. 후배들이 다른 사람들이 자주 도움을 요청하고 받는 것을 본다면, 그들은 스스로에게 더 많은 질문을 하는 경향이 있을 것이다. 그리고 그들은 그래야 합니다! 혼자서 고군분투하는 것보다 지식이 풍부한 팀원과의 짧은 대화를 통해 훨씬 더 많은 것을 배울 수 있습니다.—이것이 바로 제가 아무도 알려주지 않는 개발자 워크플로 팁에 썼던 많은 팁을 배운 방법입니다.

겸손

위에서 도움을 요청할 수 있다고 언급했습니다. 여기에는 당신이 무언가를 모르고 그것을 알아내지 못했다는 것을 인정해야 한다는 것이 내포되어 있으며, 여기에는 전문적인 취약성이 필요합니다. 그렇기 때문에 모든 사람이 상호 작용에서 겸손을 보이는 것이 중요합니다.

질문이 기본처럼 보일 수 있고 "그건 좀 멍청해, 그들은 이미 알고 있어야지"라고 생각할 수 있지만, 그런 식으로 상호 작용에 접근하면 도움을 구하는 사람이 다시는 도움을 요청하지 않을 것이고 결과적으로 팀 전체가 고통을 겪을 것입니다.

당신이 더 잘 알고 있을 수도 있지만, 당신이 알고 있더라도 사람들은 그들이 말을 잘하는 것처럼 느껴진다면 당신과 함께 일하고 싶어하지 않을 것입니다.

소유권 및 책임

회사 규모가 아주 작지 않다면 여러 팀으로 구성될 가능성이 높습니다. 각 팀이 각자의 도메인에 대해 구체적이고 뚜렷한 소유권을 갖는 것이 중요합니다. 누가 무엇을 소유하고 있는지 명확해야 합니다. 공동 책임은 항상 다른 사람의 책임이 됩니다4.

주인의식과 밀접한 것은 책임입니다. 도메인을 소유한 사람이나 팀도 이에 대한 책임을 져야 합니다. 우리 팀이 결제 서비스를 소유하고 있다면 문제가 발생하더라도 우리의 책임이어야 합니다. 결제 관련 사고가 발생하면 대기 중인 사람이 즉시 저희에게 연락할 것으로 기대합니다.

관련 : 비난과 사후 분석

책임에는 비난의 가능성이 내포되어 있다: "지불에 문제가 있었고, 그것은 저스틴의 팀 잘못이다." 자, 그것은 사실일 수도 있고, 어쩌면 우리가 잘못된 코드를 보냈을 수도 있습니다. 그러나 그것은 사실이 아닐 수도 있고, 어쩌면 종속성이 다운되었을 수도 있습니다. 어느 쪽이든, 우리를 비난하는 것은 아무것도 해결하지 못할 것이며, 미래에 아무것도 배송하지 않으려는 의향을 떨어뜨릴 뿐입니다. 항상 좋은 의도를 가져야 합니다. 아무도 고의로 물건을 부수지 않습니다.

효과적인 팀은 비난하기보다는 다음과 같은 질문을 할 수 있습니다.

• 도대체 무슨 일이 있었던 걸까요?
• 신속하게 알림을 받았습니까?
• 이것이 어떻게 테스트를 통과 할 수 있었습니까?
• 어떻게 해결되었습니까?
• 앞으로 이런 일이 다시 발생하지 않도록 하려면 어떻게 해야 합니까?

내가 참여했던 가장 효과적인 팀은 이 프로세스를 생산 사고 후에 열리는 의무적인 사후 분석 회의로 공식화했습니다. 그 회의에도 한 명의 소유자가 있었고, 회의가 끝나기 전에 모든 후속 작업이 개인에게 할당되었습니다.

모든 것이 실패할 것이고, 그것은 불가피합니다. 코드가 완벽하더라도(결코 완벽하지 않음) 종속성이 줄어듭니다. 유능한 팀은 각각의 실패를 다른 사람을 탓할 기회가 아니라 개선할 수 있는 기회로 여깁니다.

모집

시작할 적절한 사람이 없으면 이 게시물의 다른 어떤 것도 불가능합니다. 올바른 기술과 태도를 가진 사람이 필요하며, 한 번의 잘못된 고용은 팀을 망치기에 충분합니다. 스티브 잡스가 자신의 가장 중요한 직업을 채용하는 것을 고려한 데는 이유가 있다.

채용은 정말 잘하기가 어렵습니다. 채용 및 면접 과정에 많은 시간을 투자할 가치가 있습니다. 제가 본 최고의 채용 프로세스는 매우 잘 정의되어 있었습니다: 각 모듈의 각 레벨에 대한 성과 기대치를 구분하는 철저한 기준표가 있었고, 면접관은 모듈에 대해 사전에 교육을 받았고, 채점은 독립적으로 수행되었으며, 프로세스에 관련된 모든 사람들이 마무리 토론을 했습니다. 이 프로세스는 이전에 일한 위치에 따라 테이블 스테이크처럼 보일 수 있지만 그렇지 않습니다.

회의

엔지니어는 회의에 특히 민감합니다. "메이커 타임"은 적어도 2009년부터 논의되어 왔으며 매우 실제적인 것입니다. 고품질 소프트웨어를 작성하는 것은 오랜 시간 동안 중단 없이 집중해야 하는 딥 워크입니다. 문제의 전체 범위를 맥락화하는 데 30-60분이 걸리지만 90분마다 회의가 있다면 아무 것도 할 수 없습니다. 그런 일이 충분히 자주 발생하면 방해가 온다는 것을 알고 있기 때문에 일을 끝내려고 노력조차 하지 않을 것입니다.

내가 있었던 최고의 팀들은 이것을 명시적으로 인정했고, 개별 기여자가 회의에 추가되지 않는 요일 전체를 차단하기까지 했다. 물론 하루 종일 차단하는 것이 모든 곳에서 현실적이지 않을 수 있지만 최소한 팀은 회의에 진정으로 필요한 사람만 포함하도록 노력해야 합니다. 피자 두 판 규칙의 일부 맛은 아마도 대부분의 비즈니스에 적용될 수 있습니다.

관리자에 대한 간략한 설명

저는 매니저가 된 적이 없기 때문에 이 섹션을 간략하게 유지하겠습니다.

좋은 매니저는 당신의 새끼손가락과 비슷하다. 모든 것이 순조롭게 진행되고 있다면 거의 눈치채지 못할 수도 있습니다. 그러나 무언가 잘못되자마자 생각할 수 있는 것은 그것뿐입니다.

사람들은 문제에 대해 매니저를 탓하는 것을 좋아하지만, 내 경험상 나쁜 매니저는 신뢰 부족이나 조직 정렬 부족과 같은 더 큰 문제의 원인인 동시에 더 큰 문제의 증상이다5. 내가 만난 최고의 감독은 대부분 우리 팀을 내버려 두고 우리의 일을 했다. 그는 우리가 그를 필요로 할 때 항상 사용할 수 있었지만 우리는 양질의 작업을 안정적으로 제공할 수 있다는 것을 입증했기 때문에 그의 의견이 필요하지 않는 한 그는 우리가 할 일을 하도록 내버려 두었고 우리 모두는 정말 감사했습니다. 매니저의 삶을 더 쉽게 만들수록 모두가 더 행복해질 것입니다.

결론

이것은 결코 기준의 완전한 목록은 아니지만 효과적인 개발 팀을 구축하는 것이 왜 그렇게 어려운지 알기에 충분합니다. 위의 속성 중 하나라도 부족하면 팀이 어려움을 겪을 것입니다. 이것이 "엔지니어링 책임자" 또는 "CTO"와 같은 직함을 가진 사람들이 큰 돈을 받는 이유입니다. 위의 모든 것을 잘하고 그 이상을 수행하는 조직을 만들기 위해 노력하는 것이 그들의 일입니다. 그들이 그것을 할 수 있다면, 그들은 모든 페니의 가치가 있습니다.