47P by xguru 6달전 | favorite | 댓글 8개
  • 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로 회귀했습니다...

다만 더 나은 방법이 있을지 계속 고민은 하고 있습니다.

어떤 점에서 구관이 명관이라고 생각하신걸까요?

저는 YouTrack을 좋아한답니다. Jetbrains가 만든 PM툴인데 제가 필요한 만큼은 프로젝트를 관리할 수 있더라고요.

저희 팀은 Linear로 갈아탔고, 전체적으로 만족도가 많이 올라갔습니다. 한번 검토해보시길 추천드릴게요.

이 제품인가 보네요, https://linear.app/. 흥미로워보입니다.

네 장점이라고 느끼는 부분들은

  1. 가볍고 빠르다. - 앱의 속도, 숏컷, 제공되는 기능의 뎁스
  2. opinionated된 가이드라인이 있다.
  3. 러닝 커브가 낮다. 이슈 트래커에 익숙하지 않아도 배우기 쉬움.
  4. integration이 충분히 잘 되어있다.

이 정도로 저는 느끼고 있어요.