개발 7년차 매니저 1일차
카미유 푸르니에. 『개발 7년차, 매니저 1일차』. 권원상, 한민주(역). 한빛미디어, 2020.
테크리드는 팀의 규모를 키울 수 있는 능력 있는 기술 프로젝트 매니저가 되기 위해 노력해야 한다. 관리 및 리더십이 필요한 상황을 다루는 방법을 배운다. 그리고 제품, 분석 및 다른 비즈니스 담당자들과 효과적으로 협력하는 방법을 배운다.
테크리드에게는 기술 전문성 이상으로 사람을 다루는 기술이 필요하다. 그리고 또 다른 중요한 기술인 프로젝트 관리 기술이 필요하다. 프로젝트를 세분화하는 작업은 시스템을 설계하는 것과 유사점이 많다.
테크리드가 된다는 것은 소프트웨어에 대해 많이 알고 있으며, 프로젝트에서 더 큰 책임을 질 수 있을 만큼 성장했다고 인정받았다는 의미다.
프로젝트 관리 업무와 기술적 결과물을 만드는 일 사이에서 '균형 잡기' 기술을 배워야 한다. 자율성을 가지고 언제 일할지 선택하고 싶다면 시간을 잘 다룰 줄 알아야 한다.
테크리드가 가장 우선시해야 하는 것은 프로젝트를 계속 진행할 수 있도록 넓은 관점에서 업무를 조망하는 것이다.
- 시스템 아키텍트 및 비즈니스 분석가
- 변경이 필요한 핵심 시스템과 프로젝트 결과로 제공하고자 하는 핵심 기능을 파악
- 업무에 대한 예측과 우선순위를 근거로 대략적인 구조를 만드는 것이 목표
- 시스템 전반의 아키텍처를 이해하는 감각과 복잡한 소프트웨어를 설계하는 방법
- 프로젝트 기획자
- 프로젝트를 작은 단위로 나누어 대략적인 결과물로 정리
- 팀이 빠르게 작업할 수 있도록 업무를 작은 단위로 나누는 효율적인 방법을 찾아야함
- 소프트웨어 개발자 및 팀 리더
- 코드를 작성하고 문제를 공유하며, 권한을 위임한다.
- 테크리드가 새 기능을 개발하기 위해 과로하기 십상인데, 이는 때로 팀이 실패하는 원인이 되곤 한다.
- 직접 빌드하고 싶은데 시간이 없다면 그 일을 다른 사람에게 위임할 줄도 알아야 한다.
지원해야 할 아키텍처에 관해 충분히 이해하지 못했다는 느낌이 든다면 시간을 투자해야 한다. 다음 세 가지를 해보자.
- 첫째, 아키텍처에 대해 학습하여 감을 잡고 시각화해본다.
- 둘째, 데이터가 어디에 있고, 어떻게 흘러가는지 파악한다.
- 셋째, 제품의 핵심 로직은 어디고, 이 부분이 어떻게 반영됐는지 이해한다.
충분한 역량이 있는 시니어 개발자가 다른 어려운 작업을 맡는 게 더 합리적이다. 다른 팀원이 전체 시스템을 배우고 역량을 키울 수 있도록 배려하는 의미에서라도 늘 혼자서 감당해서는 안 된다. 업무를 잘 처리할 시간적 여유가 있다면 때때로 즐거운 일도 맡아서 하라.
팀의 가장 중요한 기술적 결정을 주도해야 한다. 하지만 팀을 배제하고 혼자서 모든 결정을 내려도 된다는 의미는 아니다. 팀원의 의견을 구하지 않고 모든 기술적 결정을 혼자 내리기 시작하면, 일이 잘 안 될 때 팀원들은 테크리드를 원망하고 비난할 것이다. 반대로 기술적 결정을 하지 않고 모든 것을 팀원들에게 맡기면 신속하게 결정할 수 있는 것도 해결되지 않고 지연될 것이다.
이제는 팀의 생산성이 당신의 생산성보다 더 중요하다. 많은 경우에 의사소통으로 인한 비용이 든다는 의미다. 모든 팀원이 회의에 참석하는 대신 당신이 팀을 대표해서 팀원들의 요구사항을 전달하고, 회의 결과를 공유해야 한다. 성공한 리더에게 보편적인 특성 중 하나는 의사소통 능력이다.
회의에 주의를 기울이고 자신과 팀의 지식 한계를 끊임없이 시험한다. 다른 사람과의 의사소통과 경청을 잘못하면 더 이상 성장하기 어렵다.
- 매니지먼트 업무로 전환하는 과정에서 중점을 두어야 할 것
- 자신의 매니지먼트 스타일을 깨닫는 것
- 팀은 팀원 개개인의 상태만큼 건강하며
- 팀원 하나하나를 관리하는 매니저로서 당신이 각 팀원들에게 큰 영향을 미치기 때문
- 다음은 사람 관리에 필요한 주요 업무다
- 새로운 보고 체계 만들기
- 정기적으로 원온원 미팅하기
- 경력 성장, 목표 달성, 개선된 영역 및 근거 있는 칭찬 등 정기적인 피드백 하기
- 팀원이 학습할 영역을 찾고 프로젝트 업무, 외부 교육이나 멘토링 등을 통해 성장 돕기
어떻게 해야 새로운 사람을 빨리 파악하고 잘 관리할 수 있을까?
한 가지 전략은 새로운 관리해야 하는 사람의 개인적 특성을 파악하기 위한 질문을 하는 것
- 칭찬은 어떻게 받고 싶습니까? 공개적으로 아니면 비공개적으로?
- 진지한 피드백을 어떻게 하면 될까요?
- 피드백을 받아들일 시간이 필요하면 문서로 할까요? 아니면 비공식적인 구두 형태의 피드백이 괜찮을까요?
- 왜 이 팀에서 일하기로 했나요? 어떤 점이 흥미가 있었어요?
- 기분이 나쁘거나 짜증 나면 어떻게 표현하나요? 당신의 기분을 상하게 하는 것 중 제가 알아야 할 것이 있나요?
- 당신이 싫어하는 '팀장의 행동'이 있나요?
- 당신의 경력 목표 중 제가 도울 수 있는 것은 무엇인가요?
- 팀에 합류한 뒤 좋은 의미든 나쁜 의미든 놀랐던 점 중 제가 알아야 할 것은 무엇인가요?
생각: 최악의 방법인듯.
노련한 개발 팀장들은 어떤 방법으로 관리할까? 그중 하나로 각 팀원들이 30/60/90일 계획을 세우도록 하는 방법이 있다.
- 계획의 기본적인 목표
- 코드 생산성 향상
- 버그 수정
- 릴리즈
- 채용된 팀원에게 도움 될 만한 정보
- 성과를 내는 시점에서 적절한 것을 학습하고 있는지 확인 가능한 목표
...생략
- 실제로 많은 개발 팀에서 신규 직원이 팀에 적응하는 과정의 일부로 신규 팀원용 기존 문서를 갱신하도록 한다.
- 신규 팀원은 팀에서 관련된 프로세스와 도구에서 변경된 부분을 파악하여 기존 문서에 반영한다.
- 이 과정을 통해 팀원 모두 프로세스를 다시 숙지하는 계기를 만들 수 있다.
- 신규 직원도 팀장이 기대하는 바와 팀장의 스타일을 이해할 필요가 있다.
- 직원도 팀장이 무엇을 기대하는지 알지 못하면 어떤 결과를 얻어야 할지 알 수 없다.
- 상대에 대한 기대 사항에는 구체적인 내용이 포함되어야 한다.
- 얼마나 자주 만날 것인지
- 서로 정보를 어떻게 공유하고 신규 직원의 업무를 얼마나 자주 검토할지
- 신규 직원의 시각으로 관찰한 팀에 대한 피드백을 가능한 한 많이 받으라는 것
- 기존 팀원의 눈에는 보이지 않는 팀의 모습을 새롭고 다른 시각에서 볼 수 있는 아주 귀한 시간이다
- 기존 팀원에게 공격하는 것처럼 들리지 않도록 팀의 프로세스와 시스템 비판은 장려하지 않도록 한다
정기적인 원온원은 자동차의 엔진 오일을 바꾸는 것과 비슷하다. 귀찮다고 건너뛰면 고속도로 갓길에서 옴짝달싹 못하는 최악의 상황에 대비한 계획이 필요할 것이다. - 마크 헤드룬드
- 원온원은 매주 하는 게 기본이다
- 일주일에 한 번 원온원을 하되 지나치게 많다고 동의하는 경우에만 주기를 조율한다
- 면담을 할 팀원의 일정을 존중하고 가능하면 집중해서 생산성 있게 일하는 시간도 피해 원온원 시간을 잡자
- 일주일 동안 팀원과 얼마나 자주 상호작용을 하는 가?
- 특정 팀원과 상호작용하는 빈도가 높다면 같이 앉아서 이야기할 시간을 특별히 잡지 않아도 된다.
- 팀원에게 얼마나 많은 코칭이 필요한가?
- 신입 팀원은 업무가 익숙한 시니어 팀원보다 더 많은 시간을 들여 원온원을 해야 한다.
- 시니어 팀원이더라도 어려운 프로젝트에 투입됐다면 업무의 세부 사항에 관해 이야기하는 시간이 필요하다.
- 팀원은 내게 얼마나 많은 정보를 보내는가?
- 정보 전달에 익숙하지 않은 팀원과는 원온원을 더 자주 하자.
- 팀원과의 관계가 좋은가?
- 어떤 팀원과 관계가 좋으면 관심을 덜 기울이고, 상대적으로 관계가 좋지 않은 팀원에게 시간을 더 쓰는 경우
- 어떤 팀원과 관계가 좋다는 것은 혼자만의 착각일 수 있기 때문에, 문제가 있는 팀원하고만 많은 시간을 보내는 실수는 하지 말자
- 팀이나 회사의 상황이 얼마나 안정적인가? 또는 불안정한가?
- 회사에 급격한 변화가 있거나 불확실한 상황이면 충분한 시간을 내서 팀원의 질문에 성실히 답하자
- 불확실한 상황에서 진행하는 정기적인 원온원 미팅은 팀을 안정시키고 루머 확산을 막는 데 도움이 된다
원온원 미팅은 몇 가지 유형으로 나뉜다.
- 팀원이나 팀장 한쪽 혹은 양쪽 모두 업무 목표를 정리하여 논의하고 우선순위에 따라 각 업무 목표를 다루는 방식