간만의 휴식에 한일들

 3월 1일부터 새로운 회사에 입사하게 되어서 2월은 약 한달 정도 쉬게 되었다. 쉬기 전 까지는 이것도 하고 저것도 하고 계획도 많았지만 막상 쉬게 되면 이런 저런 제약 때문에 생각대로 되지 않는다. 특히 꼬맹이 학교에서 돌아오는 시간이 있으니 그에 맞춰 집에 있으려면 할 수 있는 것도 그렇게 많지 않은 것 같다. 그나마 한 것 들이라고는 영화본 것 밖에 없는 듯. 슬램덩크, 아바타2, 앤트맨&와스프 퀀텀 매니아. 요렇게 3개의 영화를 보고 왔다. 슬램덩크 추억의 만화책을 애니화 한 만화 영화. 뭐 나쁘지 않은 영화 였다. 전체적으로는 약간 루즈한 느낌이 들지만 마지막 클라이막스 부분에서는 음악과 함께 좋은 연출을 본 듯 한 느낌이다. 두번 본 사람도 있다고 하는데 그 정도 까지는 아닌 듯. 아바타2 볼까 말까 고민한 영화. 이미 뒷편 들까지 어느정도 촬영이 끝났다는 이야기를 듣고 보기로 결정. 처음으로 4dx 영화관에서 보았는데 의자의 흔들림 등 그 외 효과들이 그렇게 효과가 있다고는 생각을 못하겠다. 가~끔씩 타이밍이 딱 맞을 때도 있지만 오히려 신경이 쓰여서 영화에 집중 못하는 경우도 꽤 있었던 듯 하다.  화면에 집중하고 싶어서 더빙판으로 관람 했는데 더빙 판은 4dx밖에 없드라.. 내용도 괜찮고 그래픽도 괜찮고 눈도 즐거웠다. 다음 편이 나오면 또 보러 가고 싶다. 앤트맨&와스프 퀀텀 매니아 인터넷의 평가는 좋은편이 아닌 듯 하다. 이것도 4dx로 관람 하고 왔는데 나쁘지는 않은 듯 하다. 딱 거기까지. 양자 세계에 또하나의 우주가 존재한다는 가설은 이전부터 있었던 이야기. 결국 우리가 살고 있는 지구도 누군가의 양자 세계 일 수도 있다는 것.  하지만 양자 세계의 묘사가 뭐랄까 스타워즈 짝퉁이라는 느낌이 강하게 든다. 스타워즈를 본 적 없는 사람에게는 신선한 충격으로 다가 올지도 모르겠다. 영화를 볼때는 개연성같은걸 신경 쓰면 지는 거다. 그냥 무지성으로 생각하지 말고 시간 때우기로만 본다면 나쁘진 않은 듯 하지만 하나씩 따지기 시작

큰 기술 회사들은 어떻게 프로젝트를 진행할까

 아래 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), 멘토링, 코칭은 각자 용도가 있음
    • 지시는 그들이 스스로 할 수 있지만 할수 없을때 만 보조적으로 마이크로 매니징 하는 것
  • 결정을 내리는데 필요한 사람이 적을수록 더 빨리 결정할 수 있음
  • 보고하는 것에 최적화 하는 것은, 더 낮은 신뢰 환경에 최적화 하는 것
  • 컨설턴트들은 측정하기 쉬운 결과를 제공하는데 편향되어 있음, 그게 그들의 가치를 입증하기 가장 쉬운 방식이기 때문에
  • 직접적인 경쟁자들로 부터 배우는 것은 과소평가됨
  • 최고의 엔지니어 중 일부는 마이크로매니징 되기 보다는 그만두는 것을 선호

조건은 「최고의 엔지니어」라는 거. 되도 않는 넘들이 불평/불만을 뱉어 내며 팀 분위기를 전체적으로 흐리게 하는 경우도 많이 있다. 어쨋거나 마이크로매니징에 대해서는 매니저들에게 영원한 숙제.

댓글

이 블로그의 인기 게시물

curl 명령어 옵션

CISCO 2960s 초기화 후 기본 설정

AWS에서 zabbix를 이용한 autoscaling ec2 자동등록/자동삭제