아래 GeekNews에서 본 글
https://news.hada.io/topic?id=6747&utm_source=slack&utm_medium=bot&utm_campaign=T13KRBZU4
https://blog.pragmaticengineer.com/project-management-at-big-tech/
요즘 들어 조직개편에 대해 많이 고민하면서 많은 도움이 되었다. 모든 것에 대해 이대로 따라할 필요는 없지만 다음 조직 구성이나 운영방식에 참고가 되었다.
100개 이상의 빅 테크 회사들을 설문 조사한 결과
- 빅 테크의 프로젝트 관리 방식을 정리하면 ⇨ "상황에 따라 다름(It Depends)"
당연한 이야기를...
- 대부분 정해진 방법론이나 업무 방식은 없고, 팀이 자신에 맞는 것을 선택
- 상장회사나 투자받은 회사들은 전담 PM이 있는 것에 대해서 만족도가 낮았지만, 투자 받지 않은 경우는 만족도가 높았음
- 팀의 자율성과 만족도는 상관관계가 높음
자율성과 만족도에 비례해서 결과를 제대로 뽑아주면 전혀 문제 될게 없을 듯
- 문제가 있는 팀들도 방법론의 문제라기 보다는, 비전을 제대로 보여주지 못하거나, 투명성이나 도구의 부족등이 안 좋게 되는 이유 였음
동감되는 부분들이다. 경영진에서 뚜렷한 비전과 그에 의한 목표, 구체적인 전략등을 보여주지 못하니 팀원들의 분위기는 「한다고 하는데 왜 하는지는 모르겠고, 일단 월급 나오니까 하고는 있는데..」 라는 딱 이정도의 수준밖에 되지 않는 것 같다.
- JIRA는 대부분 부정적인 응답이었음
jira, asana, monday.com 등 수많은 티켓관리 툴들이 있는데, 40개가 넘는 툴들은 분석한 결과 대부분 비슷비슷 하다는 것이고, 결국 유저들의 숙련도가 중요하다는 것을 크게 느꼈다.
- 잘 되지 않았던 프로젝트 관리 방법들
- 엔지니어들이 프로젝트 기간 산정에 참여하지 않음
- 전담 PM이 있음에도 요구사항이 변경됨
- 실패한 프로젝트 관리 방법을 변경할 자율성이 없는 팀은 낮은 만족도를 기록
- 빅테크 들이 프로젝트를 진행하는 방법
- 엔지니어들이 대부분의 프로젝트를 리드함
- 정해진 방법론은 없고, 팀이 자유롭게 선택 가능
- 팀 단위 프로젝트에는 전담 Project Manager 없음. 여러팀 또는 회사 전체가 참여하는 큰 프로젝트에는 Technical Program Manager를 둠. Uber의 경우 1:50 정도의 비율
- First-class 개발자 도구가 주어지고, 이게 짧은 이터레이션 주기에 큰 영향을 줌
프로젝트에 영향을 주는 빅 테크들의 조직 구조
- 기본적인 환경
- 엔지니어와 팀이 자율성을 가짐
- 무의식 자원(공장 노동자)이 아닌 호기심 많은 문제 해결사들
- 내부의 데이터, 코드, 문서가 투명하게 공개됨
- 엔지니어들도 비즈니스와 비즈니스 메트릭에 노출됨
- 계층적 커뮤니케이션이 아닌 엔지니어-대-엔지니어 커뮤니케이션으로 빠르게
- 덜 실망스러운 개발자 경험에 투자
- 더 높은 레버리지로 정당화 되는 더 높은 급여
- 더 훌륭한 인재들을 고용 가능
Product Manager 는 Yes, Project Manager 는 No
- 제품 관리자의 롤은 "What game we're playing" 과 "How we're going to play it" 을 파악하는 것
- 많은 경우, 빅테크 회사의 제품관리자들은 Project Management를 하지 않음
- 팀이 실행에 대한 책임이 있고, 대부분 기술 관리자(팀 리드)가 프로젝트 관리를 수행할 책임이 있음
- 권한이 부여되고 자율적인 팀에서는 프로젝트 관리가 하향식이 되는 경우는 드뭄 ⇨ 모두가 같이
- 전담 Project Manager가 없을 때 궁금한 점들
- 팀 단위 프로젝트 : 프로세스를 간단히 하고, 개인간 관계를 강화
- 복잡한 프로젝트 : 빅테크 들은 Techinical Program Manager(TPM) 를 둠
- 전담 Program Manager / Project Manager 가 존재하긴 함. 일반적으로 외부,고객 및 장기 실행 계획등에 연결 됨
- 제품 중심 환경과 스크럼을 하지 않는 이유
- 스프린트 단위로 실행되는 스크럼은 빠르게 배포하는 상황에 잘 맞지 않음
- 인프라 및 개발자 도구들이 많은 스크럼 액티비티들을 대신해 줌
- 빅 테크 회사들이 인프라 및 개발자 도구에 대한 투자가 생산성 향상을 가져온다는 사실을 알게 됨
- 페이스북, 구글, 넷플릭스 등은 스크럼을 사용하지 않음. 왜 ?
- 유능하고 자율적인 사람들은 이런 구조가 덜 필요함
- 유능한 팀에게 어떻게 운영할 지 자유를 주면, 그들을 레버리지 할 수 있음
- 엔지니어링 조직을 확장하는 것은 팀 레벨 프로세스를 훨씬 넘어섬
- 그렇다고 모두 빅테크를 따라서 스크럼을 하지 않는 것은 실수임→ 스크럼을 사용하는 것이 맞는 상황이 있고, 더 높은 생산성을 낼 수도 있음
- 키친 싱크 팀 : 한팀이 모든 것을 다 해결해야 할 때(초기 단계의 스타트업)
- 새로운 팀을 형성하는 시점에
- 몇주마다 한번씩 배포하는 경우
- 통일화된 형식의 프로젝트 진행 보고를 필수로 해야 하는 경우
어떻게 팀을 운영해야 할까 ?
- 반복적인 변경이 '빅 뱅' 변경보다 항상 좋음
큰 조직이라면 모르겠지만 스타트업이나 중소기업이라면 최적화 된 팀을 구성하기 위해 각자의 역할을 수시로 바꾸어 보는게 필요할 듯 하다. 시켜봐서 잘 할지 모르기 때문에 못 시키기겠다가 아니라, 잘 할 수 있을지 어떨지 일단 시켜보는게 중요한 마인드라고 생각.
- 물고기를 잡아주는 것 보다, 물고기 잡는 법을 알려주는게 더 힘듬
- 지시(Directing), 멘토링, 코칭은 각자 용도가 있음
- 지시는 그들이 스스로 할 수 있지만 할수 없을때 만 보조적으로 마이크로 매니징 하는 것
- 결정을 내리는데 필요한 사람이 적을수록 더 빨리 결정할 수 있음
- 보고하는 것에 최적화 하는 것은, 더 낮은 신뢰 환경에 최적화 하는 것
- 컨설턴트들은 측정하기 쉬운 결과를 제공하는데 편향되어 있음, 그게 그들의 가치를 입증하기 가장 쉬운 방식이기 때문에
- 직접적인 경쟁자들로 부터 배우는 것은 과소평가됨
- 최고의 엔지니어 중 일부는 마이크로매니징 되기 보다는 그만두는 것을 선호
조건은 「최고의 엔지니어」라는 거. 되도 않는 넘들이 불평/불만을 뱉어 내며 팀 분위기를 전체적으로 흐리게 하는 경우도 많이 있다. 어쨋거나 마이크로매니징에 대해서는 매니저들에게 영원한 숙제.
댓글
댓글 쓰기