- 100개 이상의 빅 테크 회사들을 설문 조사한 결과
- 빅 테크의 프로젝트 관리 방식을 정리하면 ⇨ "상황에 따라 다름(It Depends)"
- 대부분 정해진 방법론이나 업무 방식은 없고, 팀이 자신에 맞는 것을 선택
- 상장회사나 투자받은 회사들은 전담 PM이 있는 것에 대해서 만족도가 낮았지만, 투자 받지 않은 경우는 만족도가 높았음
- 팀의 자율성과 만족도는 상관관계가 높음
- 문제가 있는 팀들도 방법론의 문제라기 보다는, 비전을 제대로 보여주지 못하거나, 투명성이나 도구의 부족등이 안 좋게 되는 이유 였음
- JIRA는 대부분 부정적인 응답이었음
- 잘 되지 않았던 프로젝트 관리 방법들
- 엔지니어들이 프로젝트 기간 산정에 참여하지 않음
- 전담 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), 멘토링, 코칭은 각자 용도가 있음
- 지시는 그들이 스스로 할 수 있지만 할수 없을때 만 보조적으로 마이크로 매니징 하는 것
- 결정을 내리는데 필요한 사람이 적을수록 더 빨리 결정할 수 있음
- 보고하는 것에 최적화 하는 것은, 더 낮은 신뢰 환경에 최적화 하는 것
- 컨설턴트들은 측정하기 쉬운 결과를 제공하는데 편향되어 있음, 그게 그들의 가치를 입증하기 가장 쉬운 방식이기 때문에
- 직접적인 경쟁자들로 부터 배우는 것은 과소평가됨
- 최고의 엔지니어 중 일부는 마이크로매니징 되기 보다는 그만두는 것을 선호