팀 관리
팀 관리는 개인을 관리하는 것과 다르다.
엔지니어링 리드 (저자의 팀매니저 역할 설명의 직무 기술서)
엔지니어링 리드는 코드 작성에 상대적으로 적은 시간을 쓰지만.
팀의 작업을 방해하거나 작업 속도를 떨어뜨리지 않는 정도의 버그를 수정하고, 작은 기술 산출물에 관여한다.
코드 작성 말고도 팀의 성공을 위해 개발 프로세스의 병목 지점과 장애물을 찾고 이를 제거하는 챔임을 맡는다.
- 팀의 업무 집중을 위해 엔지니어링 리드는 제품 리드와 긴밀한 협력 관계를 유지하고,
프로젝트 범위를 관리하고 , 기술 산출물이 요구 사항을 충족하도록 한다.
- 팀의 필요인원을 파악하고 이를 충원할 수 있는 계획을 세우고 채용할 수 있어야 한다.
- 엔지니어링 리드는 독립적인 매니저다. 자신과 다른 기술을 가진 팀원을 관리하는 데 익숙해야 한다.
- 모든 팀원에게 기대하는 바를 명확하게 전달하고, 팀원들과 수시로 피드백을 주고 받아야 한다.
- 제품 그룹을 위해서도 기술 로드맵에 관한 리더 역할을 해야한다.
- 일정, 범위, 위험에 대해 파트너 들에게 명확하게 전달하고,일정에 맞춰 주요 계획에 따른 산출물을 전달해야한다.
- 기술 부채의 전략적 영역을 파악하고, 이를 해결하기 위한 비용과 편익을 분석해 우선 순위에 따른 일정을 경영팀과 소통할 수 잇어야 한다.
처음 매니저가 되면 사람 관리에만 집중하기 쉽다.
팀 관리에 필요한 기술적, 전략적, 리더십적인 영역을 살펴보자.
한 사람의 매니저 되기
좋은 매니저가 된다는 것은 기술적으로 가장 뛰어나야 한다는 의미는 아니었다.
사람들을 돕는 일이 매니저로서 성공하는데 훨씬 중요했다.
- 베서녜이 블런트
기술역량 유지하기
- 성공적인 기술 매니저가 되는 과정에서 기술적인 역량을 과소평가 하면 안된다.
- 일단 조금이라도 코딩에 참여하는 것이 좋다.
- 한 팀의 매니저로서 시스템에서 가능한것과 불가능한것을 구별하는데 도움이 된다.
- 뛰어난 기술 매니저는 새 기능을 구현할 수 있는 가능한 최단 경로를 찾아낼 수 있다.
- 복잡한 프로젝트 관리의 핵심은 기능 구현에 필요한 최적의 방법을 결정할 수 있을정도로
시스템의 각 부분을 충분히 이해하는 것이다.
문제 있는 팀을 디버깅하기
출시하지 못하는 상황
- 프로젝트가 초기 단계라도 목표와 산출물을 정의한다.
- 팀이 산출물을 만들수 있도록 돕거나 지연되는 부분을 깊이 분석하는 것도 좋다.
- 현재 상황을 충분히 이해하기 위해 담당 개발자와 협력하는 것도 좋은 방법이다.
- 도구와 프로세스 때문에 작업이 오래 걸리는 경우, 이런 병목 현상을 제거하기 위해 노력해야 한다.
예) 팀의 릴리스 속도를 높일 수 있도록 모든 팀원이 함께 코드베이스 자동화를 개선.
어디에나 있는 문제 직원
- '똑똑한 개자식' : 똑똑하고 생산성이 높아 대체 불가능 하지만, 다른 모든 팀원을 괴롭힌다.
- 해당 직원과 상사가 대화를 할 기회를 마련하거나 타른 팀으로 직원을 보내서 문제를 해결할 수도 있다.
- 부정적인 사람 : 행동변화를 요청하고, 명확한 예를 알려주고, 피드백을 하겠다는 점을 분명히 한다.
- 좋은 조건으로 팀을 떠나도록 도와주는 것이 최선일 수 있다.
- 부정적인 사고 방식으로 팀에 오래 두지 말자, 빠르게 처리하자.
과로로 인한 불행
예) 프로덕션 시스템의 불안정성 때문에 과로하는 경우
- 매니저가 할 일은 일정 기간 안정성에 집중 할 수 있도록 제품 로드맵의 속도를 늦추는것이다.
- 경고, 장동 중단시간, 사고를 명확하게 측정한 다음에 줄이도록 노력해야 한다.
- 계획을 세울때 항상 29퍼센트의 시간을 시스템 지속성(기술부채)을 위한업무에 할당하기를 추천.
예)긴급한 릴리즈로 과로하는 경우
- 매니저는 응원단이 되어야 한다.
- 지원이 필요한 팀은 업무를 직접 돕는다. 힘든 업무에 대한 감사도 펴시한다.
- 힘든 시간이지만 즐겁게 일 할 수 있도록 한다.
- 이런 위기 상황에 대한 교훈을 얻어서 다음번에는 문제를 피할 수 있도록 준비한다.
- 제품 기능을 줄일 수도 있고, 비현실적 일정이라면 연기해야 한다
위기는 발생할수 있지만 , 자주 발생해서는 안된다.
협업이 안되는 경우
- 제품팀, 디자인팀 혹은 다른 기술팀과 협업이 원할치 않아서 팀원이 지치는 상황이 온다.
- 문제를 해결하기 위해 적절한 동료들과 정기적으로 접촉해야 한다.
- 팀에게서 실행 가능한 피드백을 수집하고, 개선책을 찾기 위한 생산적인 대화를 나눠야 한다.
- 팀원끼리 협력이 잘안되는 경우
- 팀이 업무와 무관하게 놀 기회를 만들어보자.
- 팀의 단합을 도모.
바람직한 방패막이 역할
팀을 효과적으로 관리하기 위해서는 매니저가 방패막이 역할을 해야 한다고들 한다.
- 사내정치 및 변화에 팀원들이 흔들리지 않고 해야할 일에 집중할 수 있게 도와야 한다.
- 팀이 산만하지 않도록 보호 해야 한다는 의미.
때로는 스트레스의 일부를 팀에 전달하는 것이 좋다.
- 팀이 처한 상황을 함께 이해하자는 것.
- 전후 사정에 대한 적당한 정보는 팀이 어디에 어떻게 집중해야 하는지를 결정하는데 도움이 된다.
- 매니저로서 모든 결정을 직접 내리는 것은 당신의 업무가 아니다.
문제점
- 외부세계의 모든 드라마를 거부하는 것
- 팀원이 회사내의 어떠한 사건을 다른 사람에게서 듣게 된다면.
팀원은 불편함과 이해할 수 없는 상황에 놓이게 된다.
- 이런 사건에 직접적이고 감정이 덜한 방식으로 소통하면,
불필요한 소문은 줄이고 팀에 미치는 영향을 빠르게 줄이게 된다.
- 매니저는 부모가 아니다.
- 팀원은 적절하게 존중해야 할 성인이다.
- 존중은 팀원들뿐 아니라 매니저의 정신건강에도 중요하다.
좋은 의사결정을 내리는 방법
기술 매니저의 책임
- 기술매니저는 보통 로드맵과 기술사항을 고려해 팀 업무를 진행할 책임을 진다.
- 리더십의 본질은 팀원에게 명령하는 것이 아니라 팀원들이 결정할 수 있도록 돕는 것이며,
사람들은 팀원들의 결정이 잘 되었는지를 기준으로 기술 매니저를 판단한다.
데이터 중심의 팀 문화 만들기
- 팀에 제품이나 비즈니스 책임자아 있다면, 올반른 결정을 위해 비즈니스,
고객 및 상태, 데이터 사용에 익숙해야 한다.
- 예를 들어 , 팀 생산성 데이터나 품질 측정 데이터를 담당자에게 제공할 줄 알아야 한다.
- 이런 효율성 및 기술적 데이터 점수는 제품 기능과 기술정 변화에 관련된 결정사항을 평가할때 사용.
제품 역량 강화하기
- 강력한 리더십은 성공적인 프로젝트를 인도하는 팀을 만들어내는데 관심을 기울인다.
- 성공적인 프로젝트?
- 고객 입장에서 고객에게 중요한 것을 이해하기 위해 노력한 끝에 결과물을 내는 것
- 고객(외부고객, 다른 개발자, 지원 팀)을 공감할 수 있는 시간을 확보하는 것이 중요하다.
팀의 개발자들이 고객의 업무 맥락을 이해하 필요가 있기 때문.
미래 내다보기
- 제품 로드맵의 감을 잡는 것이 기술 로드맵에 지침이 될 것이다.
- 새로운 기능을 더 쉽게 구현할 수 있는 기술 역량이 있을 때, 기술 프로젝트를 잘 수행할 수 있다.
- 제품 팀과는 앞으로 어떤 방식이 좋을지 질문해야 하며,
소프트웨어 개발이나 운영방식을 어떻게 바꿔야 할지도 고민해야한다.
의사 결정과 프로젝트 결과에 대해 검토하기
- 프로젝트에 동기를 부여하기 위해 사용된 가설이 실제로 사실이었는지에 대해 논의한다.
- 검토하는 과정을 생략하기 쉽지만 매니저 스스로 가설을 검토하는 습관을 드리면
언제나 자신의 결정에서 무언가 배우게 될 것이다.
프로세스와 일상 업무에 대해 회고하기
- 애자일 프로세스는 보통 스프린트가 끝나고 회고를 진행한다.
- 애자일 방법론을 따르든 다른 방법론을 따르든, 정기적인 프로세스 회고는 패턴을 찾아내고
의사결정의 결과를 판단하는데 중요한 가치가 있다.
- 팀이 요구사항을 받는 방법은 괜찮은가? 코드 품질에 만족? 회고를 통해서 매니저가 내린 결정이
시간이 흐름에 따라 팀의 운영에 어떤 영향을 미치는지 학습하는데 도움이 된다.
- 회고를 통한 접근 방법은 팀의 건강성에 관한 데이터를 수집하는 것보다 주관적이지만
여러가지 객관적 수치화에 비해 확실히 중요한데, 팀원들이 서로 이해하고 노력하고 축하하는 과정에서
얻어지기 때문이다.
좋은 매니저, 나쁜 매니저: 갈등 회피자, 갈등 조정자
갈등을 회피하는 매니저 제이슨이 나온다.
- 갈등을 해결하거나 어려운 결정을 내리는데 참여하는 것을 어려워한다.
- 리더가 팀의 방향을 제시하지 못하기 때문에 팀원들은 괴로워 한다.
갈등을 조정하는 매니저 리디아가 나온다.
- 팀의 매니저임을 명확히 인식하고 가장 중요한 프로젝트에 집중시킨다.
- 원온원 미팅을 통해 현재의 업무에 대해 설명하고 팀원의 도움을 구하며 충분히 인지시킨다.
- 팀원들에게도 충분히 이해할 수 있게 설명했다.
- 어떤 결정에도 책임을 지지 않으려는 리더의 무능함은 모든 팀원을 불안하게 한다.
갈등 관리에서 할 것과 하지 말아야 할 것
합의냐 투표냐를 양자택일 하지 않는다
- 투표에 참여하는 모든 사람이 공정한가?
- 다양한 결과에 대해 동일한 이해 관계를 가지는가?
- 전후 맥락에 동일한 지식을 가지는가?
- 이런 전제 조건들은 전문 지식이 다르고 다양한 역할이 있는 팀에서는 거의 충족되지 않는다.
- 나쁜 소식을 전해야 하는 매니저의 택임을 지지않으려고, 문제 될것이 뻔한 투표로 사람들을 몰아넣지 말자
* 한국어 맞나.. 합의 / 투표를 나눠서 생각하는 타이틀이지만 본문은 합의와 투표를 같은 맥락으로 설명하는 것 같아서 햇깔린다.
팀원 모두의 의견이 일치하는 "합의" 나 책임을 넘길수 있는 "투표"를 쉽게 선택하지 말자는 말로 이해했다.
- 충분한 맥락 설명을 통해, 합의를 이루어보고,
합의가 어려울 경우 투표 및 매니저 가 책임지는 방향의 제안을 해야할 것 같다.
객관적인 결정이 가능한 명확한 프로세스를 마련한다
- 의사 결정을 잘하려면 결정한 내용을 평가할 수 잇는 "명확한 기준"이 필요.
- 결정 전에 목표, 위험에 대해 공유하고, 질답 단계를 가져야 한다.
- 결정 권한을 특정 팀원에게 부여할 때는 피드백을 누구에게 받아야 할지,
결정 사항과 계획을 누구에게 보고해야 할지를 명확히 해둔다.
금방 터질 것 같은 이슈를 외면하지 않는다
- 갈등 회피가 드러나는 다른 형태로, 문제 해결을 방치 하는 경우가 있음.
- 매니저로서 부정적인 피드백을 해야한다면, 이를 즉시 실행해야 한다.
- 팀원이 문제를 알게 해야한다.
드라마를 만들지 말고 문제를 해결한다.
* 무슨 말을 하고 싶은건지 이해가 어렵다. ㅜㅜ
- 해결할 것과 그대로 둘것을 판단해야 한다.
- 계속 진행되는 문제인가?
- 개인적으로 신경 쓸 문제인가?
- 다수의 팀원이 힘들어 하는 문제인가?
- 힘의 역할이나 잠재적인 편한이 드러나는가?
- 이런 자문을 통해 팀의 효과성을 떨어뜨리는 문제를 함께 찾아내고 해결해야한다.
팀의 치료사가 되는 것이 아니다.
* 매니저가 팀내의 갈등등 문제의 성격을 파악하고, 개입할 문제라면 문제를 해결해야 한다는 의미인것 같다.
반대로 팀원 개인간의 어떤 사소한 대인관계문제등을 매니저가 개입할 필요는 없다.
정도로 이해했다.
다른 팀에 화풀이하지 않는다.
- 갈등 회피형 매니저는, 자신을 팀과 동일시하며, 위협으로 인식하는 외부에 대해 공격적으로 대응한다.
- 골목대장처럼 변신해서, 자기팀을 위해 형평성을 주장하고, 다른 팀의 문제점을 비난한다.
- 감정 발산?!
친절하게 행동한다.
- 매니저 입장의 친절한 것은 일상적인 것과 다른다.
- 승진할 준비가 되지 않은 사람에게 준비가 필요하다가 알려주는것 어떤것이 필요한지 알려주는 것
- 어색하고 불편하지만 해당 직원을 위해 어려운 대화(예: 팀에 안좋은 영향을 주는 행동에 대한 지적)를 나누는 것
두려워 하지 않는다.
- 갈등회피는 두려움에서 기인하는 경우가 많다.
- 지나치게 요구하는 것 일까봐, 부정적 피드백으로 회사를 그만둘까봐
- 어떤 두려움은 자연스러운 것이고, 갈등의 결과에 민감한 것도 현명한 습관이다.
* 두려워 하라는건가 말라는건가... 두려움은 자연스러운 부분이지만 위축되어 갈등을 회피하지 말라는 의미같다.
도전 상황 : 팀 결속력 파괴자
성공하는 팀의 토대
- 팀원들이 다른 팀원들 앞에서 기꺼이 위험을 감수하고 실수를 할 수 있어야 한다는 것
- 심리적 안전과 우호적인 분위기를 만드는 것이서 시작한다.
'독성'이 있는 직원, 팀원들이 안전함을 느낄수 없도록 행동한다.
- 이들에 대해서는 빠르게 대응하는것이 중요한다.
똑똑한 바보
똑똑한 바보
- 개인적으로 엄청난 성과를 만들어내지만, 너무나 자기중심적이어서 주변사람들에게 두려움과 반감을 일으키는 직원
* 알파긱 이구나 + 불규칙적으로 바보가 되는
매니저로써는 관리하기 애매할것 같다
소통하지 않는 사람
소통하지 않느 사람
- 매니저와 팀 동료, 제품 관리자에게 정보를 숨기는 사람.
- 말하지 않고 커밋을 되돌리거나, 작업티켓을 가져와 업무를 하는 사람
- 큰프로젝트에 참여하면서 디자인리뷰도 하지 않는 사람
원인은 여러가지
- 매니저를 존중하지 않느다거나
- 자신의 부족한 능력을 알게하고 싶지 않거나, 관심 없는 업무를 맡게되는 것을 두려워함
-> 팀의 결속을 방해한다.
존중이 결여된 직원
존중이 결여된 직원
- 당신을 매니저로, 팀원들을 동료로 존중하지 않는 사람들
- 상급 매니저에게 도움을 요청할 수도 있다.
- 그 사람에게 팀에서 같이 일하고 싶은지 물어보자
- 일하고 싶어한다면, 매니저로서 기대하는 바를 분명하고 침착하게 말한다.
- 아니라면, 팀을 옮기거나 회사를 떠날 수 있도록 절차를 시작한다.
프로젝트 일정 관리방법
프로젝트 관리에 관한 경험 법칙
- 이 법칙 중 어느 것도 애자일 프로젝트 관리 방법을 대체하지 못한다.
- 분기별로 엔지니어당 10주의 샌산적인 에지니어링 주가 있다.
- 일상적으로 필요한 일반적인 유지 보수 업무를 하기 위해 20퍼센트 정도의 시간을 배정한다.
- 마감 시간이 다가오면 아니오라고 말하는 것이 당신 책임이다.
- 빠른 추정을 할 때는 두배 법칙을 사용하지만, 긴 작업을 추정하는 계획 시간을 따로 가져야 한다
- 추정을 통해 팀에 가져줄 내용을 선택할 수 있도록 한다.