[개발 7년차 매니저 1일차] 정리
https://product.kyobobook.co.kr/detail/S000001810222
[개발 7년차, 매니저 1일차 | 카미유 푸르니에 - 교보문고
개발 7년차, 매니저 1일차 | 경력이 쌓이면 누구나 겪게 될 ‘개발 관리’의 모든 것을 한 권에!- 사수, 멘토, 팀장, CTO까지 직책별 관리 기술 대백과 - 개발자도 꼭 알아야 하는 소프트 스킬, 사람
product.kyobobook.co.kr](https://product.kyobobook.co.kr/detail/S000001810222)
읽은기간 : 2023.01.10 ~ 2023.01.14
개발을 시작한지 이제 6년차가 되었고 작년 말부터 테크리드를 맡게 되었다.
내가 테크리드를 할만큼 뛰어난 기술 실력을 갖추고 있다고는 전혀 생각하지 않기 때문에, 나는 우리 팀이 더 일을 잘할수 있는 환경을 구축 하는데 힘을 써야 겠다고 생각하고 있다. 물론 기술적으로도 성장하기 위해 노력할것이다.
몇달 안되는 기간동안 하면서 느낀건 그냥 개발하는게 쉽다였다.
여러 프로젝트들의 현황을 대략적으로라도 파악하고 일정을 조율하고 각종 회의에 참여하다 보니 정작 내가 집중하여 개발을 할 시간은 많지 않게 되었다.
그리고 팀원 개개인들에게 신경을 쓰고, 좋은 문화를 만들고, 일을 더 효율적으로 하기 위해서 내가 생각해왔던것들을 공유하고 문화와 프로세스를 만들어 나간다는게 여간 쉬운 일은 아니었다. 지금도 잘 되고 있다고는 말하지 못하고 계속해서 발전해 나가야 할것 같다.
책 내용에서도 나오지만 이것간의 균형을 잡는게 쉬운일이 아니고, 계속 시행착오를 겪어가며 나에게 맞는 환경을 만들어야 겠다고 생각했다.
인상깊었던 내용
1장 IT 관리 101
원온원 미팅
- 좋은 업무 관계를 맺는데 꼭 필요하다
- 팀원과 매니저 사이의 인간적인 연결, 어떤 주제라도 개인적으로 이야기 하는것.
- 신뢰가 바탕이 된 인간적인 연결은 좋은 팀의 뼈대다
- 프로젝트 상황을 확인하는 시간이 된다면 미팅은 쉽게 지루해진다
- 팀원도 좋은 원온원 미팅을 만드는 책임을 함께 져야 한다.
피드백
- 성과 평가 떄만 하는것보다는 업무 피드백을 하는게 좋다
- 잘못된 습관을 빨리 알수록 쉽게 고칠수 있고, 칭찬으로 이어질 수 있다.
- 일상적이고 사소한 업무 중 잘하는 점을 알아차리고 인정해주자
- 피드백에서 칭찬은 공개로, 비판은 비공개로 하는 것이 이상적이다
- 매니저는 팀원이 성장하고 새로운 것을 배우는 데 도움이 되는 도전 과제를 찾아서 알려줘야 한다.
- 프로젝트가 재미없고 매력적이지 않아도 그 일의 가치를 이해시켜야 한다. 팀 목표라는 큰 그림에 일이 어떻게 연결되는지 보여주고 목적의식을 갖도록 해야한다
2장 멘토링
주니어 팀원 멘토링의 중요성
- 건강한 조직에서 신입사원 멘토링은 멘토와 멘티 모두에게 한 단계 성장할 기회가 된다
- 멘토는 책임감, 멘티는 자신에게 신경 써주는 사람이 생긴다
알파 긱
- 알파 긱은 팀에서 인정받는 최고의 개발자로, 늘 정답을 말하며 어떤 어려운 문제도 풀어내는 사람이다.
- 기술력에 최고의 가치를 두며, 실력이 의사결정에 영향을 미쳐야 한다고 믿는다.
- 보통 탁월하고 효율적으로 일하는 개발자다. 이들은 등 떠밀려 매니저가 되거나, 가장 똑똑한 사람이 매니저가 돼야 한다는 통념에 따라 매니저가 된다
- 타인의 실수를 얕잡아 보고, 팀원의 작업을 직접 다시 하는 최악의 행동을 하기도 하고, 팀원의 노력을 인정하지 않고 성과를 독식하기도 한다.
- 알파 긱이 좋은 매니저일 경우 두려운 존재이기도 하지만 많은 영감을 주고, 남들이 어렵게 하는 일도 별다른 어려움 없이 해낸다.
- 나쁜 매니저일 경우 자기 의견이 반영되지 않은 결과는 인정하지 않는다.
- 자기가 아는 것을 모든 개발자가 정확히 알아야 하며 모른다면 무지를 지적한다.
- 자신이 개발한 것에 대해 불평하거나 기술적 결정을 비판하면 공격적으로 반응한다
멘토의 매니저를 위한 팁
- 멘토링은 팀에 새로 합류한 팀원이 속도를 내서 일하고 생산성을 높이는 것이 목적이다
- 경력 개발이나 기술 성장을 위한 멘토링도 있다. 하지만 대개 이런 멘토링은 짝을 지어줬단 것 외에 별다른 지침을 주지 않아 큰 도움이 되지 않는다
- 멘토링은 멘토에게 책임이 추가된다. 멘토링 기간에는 멘토의 생산성이 떨어질 수 있다
멘토를 위한 핵심 요약
- 호기심과 열린 마음 갖기
- 멘토링은 호기심을 키우고 새로운 눈으로 세상을 바라볼 기회다. 이해했다 여겼던 것에서 명확하지 않은 부분을 찾고 가치 있는 것이 무엇인지 다시 의문을 던질 기회를 준다
- 상대방의 언어를 듣고 말하기
- 매니저가 될 생각이 없더라도 멘토링 경험은 소통 기술을 익히는 데 도움이 된다.
- 멘토링은 경청을 연습할 좋은 기회다. 질문을 잘 듣지 않으면 좋은 대답을 할 수 없다.
- 인맥 관리하기
- 경력은 인맥의 힘이 중요하다. 멘토링은 인맥을 쌓는 좋은 방법이다. 미래에 직장을 소개해줄 수도, 함께 일을 할 수도 있다.
3장 테크리드
테크리드는 매니저는 아니지만 리더십이 필요한 자리다
대개 테크리드는 가장 복잡한 기술을 다루고 최고의 코드를 작성하는 개발자에게 맡겨야 한다고 생각하지만 코드의 세부 사항에만 집중하고 싶은 사람에게 적합한 역할은 아니다
테크리드를 한마디로 정의하는 말은 없고 경험을 통해 직접 정의해야 한다. 다음은 저자의 회사에서 정의했던 역할이다
정기적인 원온원 미팅
경력성장, 목표 진행, 개선된 영역 및 명시적인 칭찬 등에 대한 정기적 피드백
프로젝트 업무, 외부 교육 또는 멘토링 등을 통해서 팀원의 성장을 돕는 교육과 지원
직접 관리 업무를 하지 않더라도 멘토링을 하거나 도움을 주어야 함
테크리드는 팀 전체의 성장을 위해 기술 프로젝트 리더로 활동하면서 대규모 프로젝트에서 자신의 전문성을 살려 기여한다
기술은 시니어 개발자의 역할이다. 따라서 테크리드의 역할을 팀에서 가장 경험이 많거나 실력 있는 개발자로 연결지어 생각하는 것은 잘못된 생각이다.
테크리드에게는 기술 전문성 이상으로 사람을 다루는 기술이 필요하다. 또 다른 중요한 기술인 프로젝트 관리 기술이 필요하다
모든 훌륭한 테크리드가 아는 한 가지 비결
- 기술적으로 뛰어난 것과 좋은 테크리드가 되는 것은 직접적인 관련이 없다
- 균형잡기가 핵심적인 도전 과제중 하나가 될 것이다
- 프로젝트 관리 업무와 기술적 결과물을 만드는 일 사이에서 균형을 맞추는 것은 쉽지 않다.
- 어느 날에는 개발자 일정을, 또 어느 날에는 매니저 일정을 수행한다. 시행착오를 거치면서 적절한 양의 작업에 드는 시간을 관리하는 방법을 배워야 한다
- 일정을 꼼꼼하게 관리하더라도 코딩 문제에 며칠씩 집중할 시간을 내기는 어렵다
- 테크리드가 발휘해야 할 리더십 중 하나는 상사나 프로덕트 매니저 같은 다른 이해 관계자가 팀의 업무 몰입을 방해하지 않도록 회의 일정을 잡는 것이다
테크 리드의 기본 역할
- 테크리드의 주요 역할
- 프로젝트를 계속 진행할 수 있도록 넓은 관점에서 업무를 조망하는 것
- 시스템 아키텍트 및 비즈니스 분석가
- 변경이 필요한 핵심 시스템과 프로젝트 결과로 제공하고자 하는 핵심 기능을 파악하는 것
- 프로젝트의 모든 요소를 완벽하게 파악할 필요는 없지만 프로젝트와 관련된 외적인 효과와 이슈를 고려하는 건 쓸모가 있다
- 시스템 전반의 아키텍쳐를 이해하는 감각과 복잡한 소프트웨어를 설계하는 방법을 이해해야 한다
- 비즈니스 요구사항을 이해하여 소프트웨어로 바꿔 내는 능력도 중요하다
- 프로젝트 기획자
- 팀이 빠르게 작업할 수 있도록 업무를 작은 단위로 나누는 효율적인 방법을 찾고 배우게 된다
- 소프트웨어 개발자 및 팀 리더
- 테크리드는 코딩을 해야 하지만 너무 많이 해서도 안 된다
- 건강한 조직은 문제를 제기하는데 어떤 부끄러움이나 불이익도 없다
- 테크리드도 필요할 때에는 개발자의 도움을 받아들일줄 알아야 한다
- 테크리드는 새 기능을 개발하기 위해 과로하기 십상인데 이는 때로 팀이 실패하는 원인이 되곤 한다. 일을 다른 사람에게 위임할 줄도 알아야 한다
테크리드가 되는 과정에서 위의 역할을 수행하는데, 직접 할 일과 다른 사람에게 위임할 일을 구분할 줄 알아야 한다
프로세스 독재자
프로세스 독재자는 올바르게 구현된 설계를 따르면 팀의 모든 문제를 해결할 수 있는 '프로세스'가 있다고 믿는다.
애자일, 칸반, 스크럼, 린, 폭포수 방법론 등에 집착한다.
'업무를 위한 적절한 도구'가 있다고 믿는 개발자가 테크리드가 되면 계획, 집중, 시간 관리, 우선순위 설정 등 모든 이슈를 해결할 도구를 찾는 과정에서 프로세스 독재자로 변해간다.
신임 테크리드라면 팀의 의사소통이나 리더십 차이로 인한 문제를 해결해야 할 때 프로세스에만 의존하는 것은 주의해야 한다.
훌륭한 테크리드가 되는 방법
- 아키텍처 이해하기
지원해야 할 아키텍처에 관해 충분히 이해하지 못했다는 느낌이 든다면 시간을 투자해야 한다.
- 아키텍처에 대해 학습하여 시각화 한다
- 데이터가 어디에 잇고, 어떻게 흘러가는지 파악한다
- 제품의 핵심 로직은 어디고, 어떻게 반영됐는지 이해한다
팀플레이어 되기
까다롭고 지루하고 성가신 작업이 무엇인지 살펴보고 해결할 수 있는지 고민해야 한다.
이런 부분을 검토한다면 개선할 부분을 분명하게 파악할 수 있다.
다른 팀원이 역량을 키울수 있도록 배려하는 의미에서라도 늘 혼자서 감당해서는 안된다.기술 결정을 주도하기
팀의 가장 중요한 기술적 결정을 주도해야 한다. 팀을 배제하고 혼자서 모든 결정을 내려도 된다는 의미는 아니다.
모든 결정을 혼자 내리기 시작하면 일이 잘 안될때 팀원들은 테크리드를 원망하게 된다.
반대로 기술적 결정을 하지 않고 모든 것을 팀원들에게 맡기면 신속하게 결정할 수 있는 것도 해결되지 않고 지연된다.
직접 결정할지 팀의 전문가에게 위임할지, 팀원 전체가 모여 결정할지를 정해야 한다.의사소통
팀의 생산성이 테크리드의 생산성보다 중요하다.
모든 팀원이 회의에 참여하는 대신 팀을 대표해서 요구사항을 전달하고 회의 결과를 공유한다.
경청을 꼭 기억해라. 다른 사람에게 발언 기회를 주고 그 사람의 말을 귀담아 듣는다