테크리드
테크리드
- 테크리드의 역할은 경력 사다리에서 특정한 지점이 아니라 모든 개발자가 시니어 수준이 되면 맡을 수 있는 몇가지 책무라고 정의 할 수 있다.
- '개발자 관리' 역할을 포함 할 수도? 포함하지 않을 수도 있다.
- '개발자 관리'를 포함할 경우
- 관리 표준인 RTR(Record to Report) 기술에 따라 팀 멤버를 관리해야 한다.
- 정기적인 원온원
- 경력성장, 목표진행, 개선된 영역 및 명시적인 칭찬 등에 대한 정기적 피드백
- 프로젝트 업무, 외부 교육 또는 멘토링 등을 통해서 팀원의 성장을 돕는 교육과 지원 보고서 작업
- 테크리드는 팀의 다른 사람들에게 멘토링을 하거나 도움을 주어야 한다.- 기술적인 부분은 시니어 개발자가 한다.
- 테크리드는 소통이 중요하다. 비기술과 기술 사이의 협력 가교 역할
- 사람을 다루는 기술
- 프로젝트 관리 기술
테크리드 되기
- 테크리드는 권한 없이 영향력을 행사하는 것을 연습하는 것이다.
* 예전에는 테크리드 == 매니저 라고 생각했는데. 책에서는 다른 역할로 보인다.
- 테크리드의 한가지 비결
- 균형잡기
- 프로젝트 관리업무와 기술적 결과물을 만드느것, 등 테크리드의 기본 역할
테크리드는 의사 결정도 하고, 코드도 작성해야한다.
- 하지만 이것이 제일 중요한 역할은 아니다.
[주요 역할]
- 프로젝트가 지속될 수 있도록 넓은 관점에서 프로젝트를 조망하는 것
시스템 아키텍트 및 비지니스 분석가
- 변경이 필요한 핵심 시스템과 프로젝트 결과로 제공하고자 하는 핵심 기능을 파악하는 것
프로젝트 기획자
- 프로젝트를 작은 단위로 나누어 대략적인 결과물로 정리
- 팀이 빠르게 작업할 수 있도록 업무를 작은 단위로 나누는 효율적인 방법을 찾고 배우게된다.
- 기획할 때 중요한것은, 생산적인 업무를 할 수 있도록 하는 것
소프트웨어 개발자 및 팀 리더
- 코드를 작성하고 문제를 공유하며, 권한을 위임한다.
- 테크리드 라는 역하은 코딩을 하지만 너무 많이 해서도 안된다.
- 우선 문제를 공유하자.
테크리드가 되는 과정에서 소프트웨어 개발자. 시스템 아키텍쳐, 비지니스 분석가, 팀리더 로서 직접 할 일과
다른 사람에게 위임할 일을 구분할 줄 알아야 한다.
연습을 하며 균형을 찾자
복잡한 프로젝트 관리하기
계획의 가치
- 합리적으로 예측하고 계획을 수립하는게 목표이지, 계획이 정확한지에 대해서는 중요하지 않다.
- 예상 되는 문제를 찾는다
- 작은단위로 업무를 분할한다프로젝트 관리에 도움되는 가이드라인
- 작업을 작게 나눈다
- 일을 어렵게 만드는 세부사항과 문제가 될 수 있는 부분을 끝까지 신경쓴다
- 프로젝트를 시작하고 진행하며 계획을 수정한다
- 계획 프로세스 에서 얻은 통찰로 변경된 요구사항을 관리한다
- 프로젝트 완료시점이 오면 세부사항을 다시 검토한다대부분의 회사에서 어느정도 시니어 레벨이 되면. 위와 같은 역할을 요구하는것 같다.
시니어 개발자로 남을지, 매니저가 될지 선택하기
시니어 개발자의 이상적인 생활
- 때로는 야크 털 깍기 같은 지루한 업무도 하지만, 재미있는 일을 선택할 수 있다.
- 주니어는 당신의 피드백을 기다린다
- 학습을 병행 하기도 쉽고, 대외적인 활동도 하면서 승승장구 한다
시니어 개발자의 실제 생활
- 지루한 업무를 반복할 수도 있다
- 능력을 뽐낼 적절한 프로젝트를 찾기 힘들다
- 매니저는 당신과 생각이 다를 수도 있다. 대외 적인 활동은 개인시간에 하길 바란다.
- 매니저보다 월급이 많을 수도 있다.
매니저의 이상적인 생활
- 매니저로서 결정을 내리고, 문화를 만든다
- 당신이 하는 일이 효율적임을 증명한다
- 승진도 빠르고 , 흥미로운 경력과 보상을 받는다
매니저의 실제 생활
- 팀을 컨트롤 하지만, 그들을 움직이는게 얼마나 힘든 일인지 알게 된다.
- 하루의 대부분을 회의로 보낸다.
- 코드를 볼 일이 많이 없다
- 우선순위 등 더 나은 결정을 하도록 도울수 있다.
- 팀원 스스로 결정하도록 도울수 있다.
- 다른 매니저 , 상위 매니저와 의견이 일치 하지 않을수 있다.
- 큰 팀을 움직이면 승진이 빠르다
원할 때 경력 트랙을 전활 할 수 있다.
- 매니저 트랙을 하다가 기술 트랙으로 전활 할 수 있다.
좋은 매니저 나쁜매니저 : 프로세스 독재자
체계화된 규칙과 프로세스로 통제할 수 있다고 믿는다.
- 방법론 들을 기반으로 하고
- 규칙을 따르지 않으면 싫어한다.
인간의 상호 작용은 모두 프로세스와 규칙으로 컨트롤 할 수 없다.
규칙을 잘 따르지 않는다면, 더 따르기 쉽도록 규칙을 바꾸려는 유연함이 필요하다.
* 책에는 내용이 더 많았지만. 내가 이해한 저자가 말하고자 하는 부분은 규칙은 단순히 보완제라는 느낌이었다.
동료와 프로젝트를 성공시키기 위한 보완제 일 뿐 강압적인 규칙을 따른다고 해서 프로젝트가 성공한다는 보장은 없다.
규칙이 필요한지, 따르기 어려운 프로세스는 아닌지 검토해야한다.
프로세스 독재자가 프로세스를 따르지 않는 사람을 체벌하지 못하게 하는것도 중요하다고 말한다.훌룡한 테크리드 되기
1.아키텍쳐 이해하기
2.팀 플레이어 되기
- 팀으로 움직여야한다, 효율적으로
- 시니어가 지루한 일을 하는것보다 역략에 맞는 일을 하게 하는게 좋다
- 다른 팀원이 전체 시스템을 배우고 역략을 키우는 기회일 수도 잇다.
3.기술 결정을 주도하기
- 기술 결정을 주도 해야한다.
- 강압적인 결정은 안된다. 일이 잘 처리되지 않을때 팀원은 당신을 원망한다.
- 팀원에게 넘겨버리면 결정이 지연된다.
- 직접결정, 팀원전체 회의를 통한 결정,팀 전문가에게 위임하는 것도 방법이다.
4.의사소통
- 좋은 문서를 쓰는 법을 익히자
- 말하는법 경청하는 연습을 하자
- 다른 사람과 의사소통하기 어렵다면 성장하기 어렵다.
이번 장은 쓸 얘기가 없다.
이전 직장에서 풀스택 팀에서 테크리드가 있었던것 같은데.
팀별로 만났던 사람마다 많이 달랐다.
어떤 분은 결정에 대한 도움, 개발에 대한 가이드도 없었고,
어떤 분은 애매한 부분에 대한 결정도 잘 해주고, 관계자와의 미팅을 주도했다.
당시 나는 담당자를 찾는 창구로써 주로 테크리드를 찾았던것 같다.
매번 진행하는 기능의 영역이 달랐고, 해당 영역의 오너십을 가진 팀을 찾아가 회의를 진행하고 기능 리뷰를 했다.
어떤 때는 테크리드가 리뷰에 참여하기도 했고, 어떤 때는 참여하지 않기도 했다.
나의 경험으로 테크리드에 대해정리하기는 애매하기 때문에.
쓸 얘기는 없다.
최근에 만난 대부분의 동료들은 어느정도 스스로 테크리드의 역할을 하고 있는것 같다는 느낌도 받는다. 동료에게 관심도 많고, 진행하는 프로젝트 전체적인 방향성도 잘 이해한다. 문서또한 잘 작성한다.
기술 결정도 본인이 결정할 수 있는 부분은 결정하고, 아닌 것은 이슈업을 하고 의사결정을 요구한다.
본인이 맡게되는 작업들도 상세한 서브태스크로 나눠서 단계적으로 처리한다. 이미 작은 프로젝트의 테크리드 아닌가?!
차이는 스스로를 관리하냐 다른 사람을 관리하냐의 차이인것 같다.
끝
