개발조직 빌딩

슈퍼 개발자에 대한 환상에서 벗어나라. 한 팀이 6달동안 일을 해결 못 한 일을 한명이 1달에 끝내더라. 이런 이야기를 듣다보면 슈퍼 개발자에 대한 환상을 품기 마련이다. 이 경우 어서 빨리 슈퍼 개발자를 구해야 겠다라는 생각을 하기 전에 그 팀과 회사의 시스템에 치명적인 문제가 있는지를 살피는게 합리적인 접근 방법이다.

1. 개발(코딩) 진도가 나가지 않는 것은 개발자 능력의(슈퍼 개발자가 있고 없고의) 문제가 아닌 기획과 방향의 문제다.
2. 개발자의 개발능력의 문제는 품질로 나타난다.

즉 슈퍼 개발자란 코드를 빨리 만들어내는 능력이 아닌, 팀이 개발을 잘 할 수 있도록 돕는데 뛰어난 능력을 가진 개발자다.

인간을 도구를 사용하는 동물이라고 하는데는 이유가 있다. 지게 이용하는 것과 트럭이용하는 것의 일의 효율을 생각해보자. 소프트웨어쪽도 마찬가지다. 수십배의 효율을 낼 수 있다. 과장이 아니고 사실이다.

개발은 팀이 하는 거다. 한 두명의 슈퍼개발자가 제품하나 뚝딱 만들어 내던 낭만주의 시대는 지나갔다. 운영체제 뚝딱만들고, 게임, 엔진 하나 만들어내던 전설의 프로그래머가 요즘은 뜸하다. 그런 시대가 아니다. 팀이 일하는 시대다.

팀, 팀과 팀이 협업하는 지금 소프트웨어 개발에서 문서는 옵션이 아니고 필수다. 문서만 제대로 만들어도 평균은 해낼 수 있다.

회의록, 기획, 설계 문서를 비롯해서 모든 것을 문서로 하고 모두에게 공개한다. 회의록은 내/외부를 막론하고 다 공개한다. 컨플루언스를 사용한다면, 회의에 주단위로 Labels를 달아서 매주 지난 주의 회의내용을 메일로 받아볼 수 있게한다. API 문서는 CI에 통합해서, 개발자/QA/운영자 가 모두 확인 할 수 있도록 한다.

모든 종류의 소외와 오해는 정보 불균형에서 발생한다.

팀 구성도 고민일 것이다. 이해가 상충하는 업무를 팀 단위로 분리하자. 보안과 개발은 이해가 상충한다. 기획과 개발도 이해가 상충할 것이다. 사일로 이펙트는 DevOps 활동등으로 관리하면 된다.

직접 개입해서 일을 잘(빨리) 끝내고 싶어하는 욕망은 이해할 수 있다. 그러지 말고 일을 잘하는 방법을 찾는 일을 해라. 개인이 열심히 해봤자 110% 효율을 낼 수 있겠다. 팀이 일을 잘 할 수 있게 만들면 300% 효율을 낼 수 있다. 무너저가는 프로젝트도 살릴 수 있다. 개발이 안되는 것은 개발자 수준이 떨어져서가 아니고, 목표와 기획이 명확하지 않아서다. 개발일정이 나오지 않는다면 그건 조직의 문제다.

• 미션과 목표를 수립한다. 목표는 구체적이어야 하고 현실적이어야 한다. 구체적이고 현실적일려면 토론이 필요함은 당연하다.
• 팀을 목표에 맞게 구성한다.
  • 이해 상충하는 업무를 팀으로 만들고
  • 사일로 이펙트를 관리할 활동을 수행한다.
• 팀을 목표에 align 시킨다.
• 팀 구성원의 업무도 목표에 align 시킨다.
• 목표에 align 되지 않는 팀이나 업무가 있다면, 그 필요성을 검토해야 한다.

중요한 점은 제품 혹은 서비스 개발에 관련된 모든 팀과 모든 구성원이 미션과 목표를 공유해야 한다는 것이다.

다른 툴들도 있겠으나 워낙 널리 사용하고 있는 툴들이다. 다른 툴들 사용해봤는데 이 만한 툴 찾기 힘든 것 같다. Jira의 경우 여러 팀이 각자의 보드를 만들 경우에도 일관된 뷰를 만들 수 있다.

1. Jira Portfolio 같은 툴을 테스트해보자.
2. Label로 보드들을 통합한다. 주단위로 Labels 정책만 통일해도 전체 프로젝트에 대한 진행 상황을 대략은 확인 할 수 있다.
3. Jira Epic으로 업무 마일스톤을 설계한다.

Confluence Jira 매크로를 이용해서 대시보드를 만들고 여기에 각 팀의 주간회의를 통합하면 프로젝트 진행에 대한 높은 수준의 뷰를 만들 수 있다. 예를 들어 2019년 11월 첫째주 스프린트를 위해서 Jira ticket에 "2019.11-1 Week" label을 붙이고, 2019.11-1 Week를 위한 confluence 페이지를 만든다. 이 confluence는 아래의 내용들을 포함한다.

1. 이번 주 팀의 주요 업무 목표
2. 이번 주 각 팀원들의 업무 목표
3. 이번 주 Critical 한 업무들 : label로 관리 할 수 있다.
4. 이번 주 의사결정이 필요한 업무들 : label로 관리 할 수 있다.
5. 이번 주 Jira Ticket을 출력하는 confluence Jira 매크로 사용

월요일에 이 페이지를 만들고, 금요일에 이 페이지의 내용을 리뷰하면 된다. 금요일에는 다음주 페이지를 (그냥 복사하면 된다.) 만들면 된다.

수직과 수평조직에 대한 생각이 모두 다르다. 내 생각은 아래와 같은데

1. 완전한 수평조직이라는 건 없다. : 가끔 기사에 완전한 수평조직이라고 나오는 회사들이 있기는 한데, 이런 기사가 나오는 이유는 이런 조직이 많지 않기 때문이다. 모험이 될 수 있는데, 완전한 수평조직 같은 것은 나중에 생각해도 된다.
2. 업무의 지시는 수직, 정보는 수평(모두에게 공개)가 내가 생각하는 수평적인 조직이다.
3. 수평/수직 신경쓰기 전에 일단 일이 잘 되게 하는 것을 목표로 한다.

리더는 다른 구성원이 일 잘하게 만드는 일을 하는 사람이다.

전체 구성원의 주요 일정이 스케쥴로 관리한다. 회의를 만든자는 회의에 대한 모든 책임을 지고 아래의 사항들을 체크해야 한다.

• 회의는 브레인스토밍이 아니다. : 브레인스토밍이 의제인 회의는 예외적이다.