[업무관리] 업무 나누기 - 육각형 개발자

하나의 일을 주면 처음부터 끝까지 책임지는 것이 기본이다. 개발자는 요구 사항 분석부터 구현, 출시까지 이어지는 일련의 과정을 관리하고 마무리해야한다.
여리서 책임은 혼자서 모든 일을 다 해야 한다는 뜻이 아니다.
일이 진행될 수 잇게 관리해야 한다는 뜻이다.

• 업무나누기
• 위험 관리
• 요구사항 이해 및 변경 대응
• 일정 관리 (또는 계획)

---

[업무 나누기]
경험이 쌓이면 더 큰 업무가 주어지는데 작은 기능 단위로 주어지던 일이 작은 서비스를 만드는 수준으로 커진다. 큰 서비스 개발에 참여할 때는 일부 기능 집합을 맡은 식이다.

개발 규모가 커졌을 대 하는 실수 중 하나가 생각나는 대로 개발하는 것이다. 작은 일을 만아서 할 때는 체계적으로 진행하지 않아도 일을 완료할 수 있다.
일을 진행하기 위한 정리 작업은 필요하지만 생각나는 대로 해도 잘못될 가능성이 크지 않다.
반면 일의 규모가 커지면 그냥 생각나는 대로 하면 안 된다. 즉흥적으로 일을 하면 제대로 끝내지 못할 가능성이 높다.
업무의 크기에 따라 일하는 방식을 배워야 한다.

주어진 일의 규모가 커졌을 때는 먼저 어떤 일부터 해야 할지 업무를 나눠보아야 한다.

일은 하루에서 수일 이내에 끝낼 수 있는 크기로 나누면 좋다.
필요에 따라 수 시간 내에 끝낼 수 있는 크기로 나누기도 한다. 만약에 요구 사항 분석 작업이 1주일 이상 소요될 것 같다면 이 작업을 다시 기획자 리뷰, 현업 리뷰 작업으로 나눈다.

 

일의 규모가 커지면 개발 계획도 세워야한다.

---

[중요 뽀인트!!]

계획을 세우려면 일의 규모를 파악해야한다.  작은 일은 대충 얼마나 하면 될지 감이 오지만 일이 커지면 얼만큼 일을 해야하는지 가늠하기 어렵기 대문에 규모를 먼저 알아야 한다. 규모를 파악하려면 해야 할 작업 목록이 필요하다.

 

작업목록에 넣어야 하는 항목 중 하나가 개발할 기능 목록이다.

기능 목록은 시스템 사용자 입장에서 구분되는 단위로 작성하면 좋다.

 

설문생성, 설문 목록 조회, 설문 시작하기, 설문 참여, 설문 결과 보기처럼 명확하게 구분되는 기능 단위로 작업 목록에 추가한다. 

 

'설문 관리'처럼 모호한 표현을 사용하면 안된다.

 

기능목록 외에 개발 자체에 대한 업무도 작업 목록에 넣어야한다.

예를 들어 개발 환경 구축, 운영환경 구축 같은 업무가 포함될 수 있다. 제품구매나 제약도 작업 목록에 들어갈 수 있다. 

작업 목록을 완벽하게 작성할 필요가 없다. 사실 완벽하게 작성할 수도 없다. 규모를 파악하는 데  필요한 만큼만 작성하면 된다.

 

직업 목록을 작성했다면 작업마다 대략 얼마나 시간이 걸릴지 추정하거나 0.2주, 0.5주, 1주 처럼 주 단위로 추정해도 된다.

 

이렇게 추정한 값을 모두 합하면 전체 업무가 대략 얼마나 걸릴지 감을 잡을 수 있다. 

어느정도 규모인지 파악할 수 있는 수칠츨 도출할 수 있다는 것에 중요한 의미가 있다.

 

개발뿐만 아니라 다른일을 할 때도 마찬가지다. 일이 크면 작은 크기로 일을 나누고, 필요하다면 나누어진 일을 더 작은 크기로 나눈다. 

이렇게 일을 나누면 어떤일을 먼저하고 어떤일을 나중에 할지 정할 수 있다. 즉 일의 순서를 정할 수 있다.

 

분업하는 방식도 고민할 수 있다. 이런점에서 일을 나누는 것은 업무를 효과적으로 진행할 수있는 작업 경로를 팡가하는 데도 도움이 된다.