5장. 팀 관리

한 사람의 매니저 되기

• 좋은 매니저가 된다는 것은 기술적으로 가장 뛰어나야 한다는 의미는 아니었다.
• 사람들을 돕는 일이 매니저로서 성공하는 데 훨씬 중요했다.

기술 역량 유지하기

• 기술 팀에게 존경을 받으려면 팀원들이 기술적으로 신뢰할 수 있어야 한다.
• 기술적인 신뢰 없이는 힘든 싸움에 직면할 수 있으며, 한 회사에서 리더십의 위치에 오를지라도 향후 선택지가 넓어지기는 힘들다.
• 성공적인 기술 매니저가 되는 과정에서 기술적인 역량을 과소평가하면 안 된다.
• 매니저로 진로를 정한다고 하더라도 기술적 책임에서 완전히 손을 떼야 하는건 아니다. 작은 기능을 구현하고 버그 수정정도는 해야 한다.

문제 있는 팀을 디버깅하기

• 산출물을 제때 릴리스하지 못하고, 팀원들은 행복하지 않고 계속 회사를 그만둔다.
• 제품 매니저는 팀에 화를 내며, 팀은 제품 매니저에게 불만을 표현한다.
• 현재 업무를 하고자 하는 에너지가 부족하거나 현재 프로젝트에 대한 열정이 없어보인다.
• 무언가 잘못되고 있지만 정확히 무엇인지 모른다.

출시하지 못하는 상황

• 현재 상황을 충분히 이해하기 위해 담당 개발자와 협력하는 것도 좋은 방법
• 사용하지 않던 도구와 프로세스 때문에 작업을 빨리 완료하지 못해 출시하지 못하는 경우 → 병목을 줄여야 한다

어디에나 있는 문제 직원

• 똑똑한 ‘개자식’ : 똑똑하고 생산성이 높아서 대체 불가능하지만, 주변의 다른 모든 팀원을 괴롭게 한다.
  • 과감하게 싹을 잘라내야 한다.
  • 이런 상황을 처음 겪는다면 상사에게 도움을 요청하는 것이 좋다.
• 부정적인 사람 : 행동 변화를 요청하고, 명확한 예를 알려주고, 그런 일이 발생하면 빠른 피드백을 하겠다는 점을 분명히 한다.

과로로 인한 불행

• 프로덕션 시스템의 불안정성 때문에 과로를 하는 경우, 매니저가 할 일은 일정 기간 안정성에 집중할 수 있도록 제품 로드맵의 속도를 낮추는 것
• 이런 경우 계획을 세울때는 항상 20퍼센트의 시간을 시스템 지속성을 위한 업무에 할당하기를 하자. 기술 부채라는 흔한 표현 대신 지속성이라고 쓰자
• 긴급한 릴리스로 인해 과로하는 경우
  • 매니저가 응원단이 되어야 한다. 지원이 필요한 팀은 특별히 업무를 직접 돕는다. 저녁도 주문해주고, 힘든 업무에 대해 감사를 표시한다.
  • 긴급한 상황이 해결된 후에 공식 휴가가 있을 것이라고 명확히 알리고, 힘든 기간이지만 가능하면 즐겁게 일할 수 있도록 한다.
  • 위기의 시간은 팀이 더 결속하기 해주는 계기로 작용할 수 있다.
  • 팀원들은 스트레스가 심한 기간에 매니저가 함께 했는지 아니면 다른 곳에서 자기 일을 했는지 기억할 것이다.
  • 이런 위기에서 교훈을 얻어서 다음번에는 문제를 피할 수 있도록 준비한다.
  • 위기는 발생할 수 있지만, 자주 발생해서는 안 된다.

협업이 안 되는 경우

• 팀원끼리 협력이 잘 안 되면 팀이 업무와 무관하게 놀 기회를 만들어보자.
  • 다함께 점심을 먹거나 금요일 오후에 즐거운 행사에 참여 하고 채팅방에서 농담하거나, 어떻게 지내는지 물어보는 것 등
  • 소통을 통해 한 팀이라는 연대감을 느낄 수 있다.
  • 팀을 상당히 활기차게 만들 수 있다.

바람직한 방패막이 역할

• 팀을 효과적으로 관리하기 위해서는 매니저가 방패막이 역할을 해야 한다(’헛소리 우산')
• 사내 정치 및 변화에 팀원들이 휘둘리지 않고 해야 할 일에 집중할 수 있게 도와야 한다.
• 팀이 산만하지 않도록 보호해야 한다.
• 때로는 스트레스의 일부를 팀에 전달하여 팀이 처한 상황을 함께 이해할 필요도 있다.

좋은 의사 결정을 내리는 방법

• 리더십의 본질은 팀원에게 명령하는 것이 아니라 팀원들이 결정할 수 있도록 돕는 것이며, 사람들은 팀원들의 결정이 잘 되었는지를 기준으로 기술 매니저를 판단한다.

데이터 중심의 팀 문화 만들기

• 팀 생산성데이터나 품질 측정 등의 데이터를 담당자에게 제공할 줄 알아야 한다.
• 효율성 및 기술적 데이터 점수는 제품 기능과 기술적 변화에 관련된 결정사항을 평가할 때 사용할 수 있다.

제품 역량 강화하기

• 개발자들이 고객의 업무 맥락을 이해할 필요가 있다.
• 고객을 공감하는 것도 고객에게 가장 직접적인 영향을 미치는 기술 영역이 무엇인지 이해하는 데 도움이 될 것이다.

미래 내다보기

• 제품 팀과 앞으로 어떤 방식이 좋을지 질문해야 하며, 다소 시간을 들여서라도 소프트웨어 개발이나 운영 방식을 어떻게 바꿔야 할지도 고민해야 한다.

의사 결정과 프로젝트 결과에 대해 검토하기

• 프로젝트가 끝나고 나면 가설을 검토하는 과정을 생략하기 쉽지만 매니저 스스로 가설을 검토하는 습관을 들이면 언제나 자신의 결정에서 무언가 배우게 될 것이다.

프로세스와 일상 업무에 대해 회고하기

• 팀원들이 서로 이해하고 노력하고 축하하는 과정에서 팀의 건강성에 관한 데이터가 수집된다.

좋은 매니저, 나쁜 매니저 : 갈등 회피자, 갈등 조정자

• 끊임없이 논쟁하고 반대 의견이 많은 팀에서 일하는 것은 고통스럽고 큰 문제를 일으키기도 한다. 하지만 거기에는 인위적인 조화라는 것이 있고, 갈등 회피형 매니저는 기능적 업무 관계 위에 있는 조화를 선호하는 경향이 있다.
• 업무에 관해 서로 의견 충돌이 가능한 안전한 환경을 만드는 것이 아무런 의견 충돌도 없다고 주장하는 것보다 훨씬 좋다.

갈등 관리에서 할 것과 하지 말아야 할 것

• 합의냐 투표냐를 양자택일하지 않는다.
• 객관적인 결정이 가능한 명확한 프로세스를 마련한다.
• 금방 터질 것 같은 이슈를 외면하지 않는다.
• 드라마를 만들지 말고 문제를 해결한다.
• 다른 팀에 화풀이하지 않는다.
• 친절하게 행동한다.
• 두려워하지 않는다.
  • 갈등 회피는 두려움에서 기인하는 경우가 많다.
  • 어떤 두려움은 자연스러운 것이고, 갈등의 결과에 민감한 것도 현명한 습관이다.
• 호기심을 가진다.
  • 갈등으로 인한 두려움을 극복하려면 행동에 대해 생각하는 것이 가장 좋은 방법이다.

도전 상황 : 팀 결속력 파괴자

• 조화를 이루며 일하는 팀을 구축하는 것에서 진정한 목표는 심리적 안전이다.
• 팀원들이 다른 팀원들 앞에서 기꺼이 위험을 감수하고 실수를 할 수 있어야 한다.
• 이렇게 하려면 시간을 들여서 팀원들이 인간적으로 친해지고 서로 업무 외의 삶과 관심에 대해 물어보도록 격려 하는 것이 좋다.

똑똑한 바보

• 개인으로서는 엄청난 성과를 만들어내지만, 너무나 자기중심적이어서 주변 사람들에게 두려움과 반감을 일으키는 직원이다.
• 똑똑한 바보 증후군을 피하는 가장 좋은 방법은 그런 사람을 아예 채용하지 않는 것이다.
• 똑똑한 바보가 있을 때 팀을 위한 최선의 방법은 나쁜 행동을 용인하지 않겠다고 공개적으로 거부하는 것이다.
  • “칭찬은 공개적으로, 비판은 개인적으로"라는 방법을 거꾸로 적용하는 몇 안되는 경우다.

소통하지 않는 사람

• 매니저와 팀 동료, 제품 관리자에게 정보를 숨기는 사람이다.
• 비밀스럽게 일하고 모든 것이 끝나고 완벽해졌다고 생각할 때 마법처럼 프로젝트 결과를 공개하고 싶어하는 사람이다.
• 소통하지 않는 사람의 매니저라면 이렇게 정보를 숨기려는 습관을 미연에 방지해야 한다. 필요하다면 그의 업무가 기대에 못 미친다고 분명하게 알려야 한다.
• 이런 행동은 보통 두렵다는 신호이며, 자신이 부족하다는 것이 알려지거나 관심 없는 업무를 맡게되는 것을 두려워한다.
• 가능하면 뭔가를 숨기는 근본적인 원인을 다뤄야 한다.
  • 팀에 해결되어야 할 가혹한 문화가 있는 것은 아닌가?
  • 심리적 안전감이 팀에 있는가?
  • 이런 팀원이 다른 배경이나 기술을 가지고 있어서 다른 팀원들이 아웃사이더로 취급하는가?

존중이 결여된 직원

• 당신을 매니저로, 팀원들을 동료로 존중하지 않는 사람들이다.
• 이런 사람을 두고 고심하는 것은 어려운 일이며 상급 매니저에게 도움을 요청해야 할 수도 있다.
• 팀에서 같이 일하고 싶은지 물어보고, 그렇다고 한다면 매니저로서 기대하는 바를 분명하고 침착하게 말한다. 그렇지 않으면 다른팀으로 옮기거나 회사를 떠날 수 있도록 절차를 시작한다.

프로젝트 일정 관리 방법

프로젝트 관리에 관한 경험 법칙

분기별로 엔지니어당 10주의 생산적인 엔지니어링 주가 있다.

• 일년에 52주가 있으니까, 분기마다 약 13주가 잇는 셈
• 휴가, 회의, 검토,생산 중단, 신규 직원 교육 등 이러한 모든 일은 팀을 몰입에서 벗어나게 한다.
• 분기별로 팀원이 주요 프로젝트에 10주 이상 집중할 수 있다고 기대하지 않는다.

일상적으로 필요한 일반적인 유지 보수 업무를 하기 위해 20퍼센트 정도의 시간을 배정한다.

• 기능 개발만으로 일정을 100퍼센트 채운 경우라면 과중한 일정의 결과로 기능 개발의 속도가 바로 떨어질 것이다.

마감 시간이 다가오면 아니오라고 말하는 것은 당신 책임이다.

• 매니저는 밀고 당길 때 팀에서 현실적으로 구현할 수 있는 기능이든 필요한 기능을 모두 구현할 때 걸리는 시간이든 선택할 수 있도록 하는 사람이 된다.

빠른 추정을 할 때는 두 배 법칙을 사용하지만, 긴 작업을 추정하는 계획 시간을 따로 가져야 한다.

• 인기 있는 소프트웨어 추정 방법인 두 법칙은 “시간 추정 요청을 받을 때마다 추측한 다음 두 배로 알려준다”

추정을 통해 팀에 가져줄 내용을 선택할 수 있도록 한다.

• 불확실성을 잘 다루어서 팀이 겪게 되는 불확실성의 정도를 제한하는 것이 매니저의 책임이다.