큰 기술 회사들은 어떻게 프로젝트를 진행할까
(blog.pragmaticengineer.com)- 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), 멘토링, 코칭은 각자 용도가 있음
- 지시는 그들이 스스로 할 수 있지만 할수 없을때 만 보조적으로 마이크로 매니징 하는 것
- 결정을 내리는데 필요한 사람이 적을수록 더 빨리 결정할 수 있음
- 보고하는 것에 최적화 하는 것은, 더 낮은 신뢰 환경에 최적화 하는 것
- 컨설턴트들은 측정하기 쉬운 결과를 제공하는데 편향되어 있음, 그게 그들의 가치를 입증하기 가장 쉬운 방식이기 때문에
- 직접적인 경쟁자들로 부터 배우는 것은 과소평가됨
- 최고의 엔지니어 중 일부는 마이크로매니징 되기 보다는 그만두는 것을 선호
"JIRA는 대부분 부정적인 응답이었음"
어떤 형식이든 이슈를 관리하는 것은 필요하다고 보는데, 저도 JIRA에 부정적이였어서 일부러 다른 툴을 시도해봤었습니다 (github issues, trello, asana등)
근데 구관이 명관이라고 결국 JIRA로 회귀했습니다...
다만 더 나은 방법이 있을지 계속 고민은 하고 있습니다.
네 장점이라고 느끼는 부분들은
- 가볍고 빠르다. - 앱의 속도, 숏컷, 제공되는 기능의 뎁스
- opinionated된 가이드라인이 있다.
- 러닝 커브가 낮다. 이슈 트래커에 익숙하지 않아도 배우기 쉬움.
- integration이 충분히 잘 되어있다.
이 정도로 저는 느끼고 있어요.