[스타트업] 작업 분할하는 방법

Contents

어떤 작업이 생겼을 때, 작업을 나누는 기준은 어떤 부분에 가치를 두는 지에 따라서 많이 다른 것 같다.

 

어떤 회사는 시간을 기준으로 나눌 수 있고, 어떤 회사는 난이도를 기준으로 나눌 수 도 있다.

 

나는 스타트업에서 일해오면서, 내가 생각했을 때 가장 효과적인 방법은 "시간"을 기준으로 나눈 것이라고 생각한다.

 

시나리오를 만들어보겠다.

 

이번 2주동안의 스프린트에는 "slack 운영 알림 시스템 개발"을 한다고 가정해보겠다.

 

요구사항은 서버 application에서 global exception이 발생하면, 운영용 slack 채널로 알림 메시지와 에러 메시지의 내용을 전송해줘야 한다고 해보자.

 

자 그러면, "slack 운영 알림 시스템 개발"에 도달하기 위해서 내가 해야하는 일을 큼지막하게 나누어 본다.

- slack 운영 알림 시스템 설계

- 설계에 따른 개발

- 문서 정리

- 배포

 

그리고 나누어진 일들을 또 다시 나누어 본다. 이 반복을 멈춰야 하는 경우는, 해당 작업을 끝내는데, 내가 생각하는 기준으로 2일 이하의 시간이 걸릴 것 같을 때, 멈춘다.

- slack 메시지 스키마 정하기(1h)

- 수집할 에러 종류 정하기(1h)

- 알림 전송 방식 선정(2h)

 

만약, 앞선 작업을 끝내야, 뒷 작업의 크기를 결정지을 수 있다면, 끝나고 작업 목록을 다시 만들어 내도 좋다.

 

너무 자잘하게 쪼갠 것 같다면 방금 정한 룰(2일을 넘지 않는다)에 위반하지 않는다면, 합쳐도 된다.

- slack 알림 전송 설계(4h)

 

 

위와 같이 하면, 정말 많은 장점이 있는데,

 

1. 작업을 작게 볼 수 있다. (작업 별로 고민, 생각하는데 충분한 시간을 할애 가능) 

2. 상황에 따라 작업을 다른 개발자에게 넘겨도, 인계 부담이 안된다.

3. 어떤 작업에서 오래 걸리는지 확인 가능하다.

 

 

반대로 단점도 있다.

1. 작성자 마다 예상 시간이 다르다.

2. 긴급하게 들어오는 업무로 인해 밀릴 경우, 실제 적힌 시간에 비해 오랜시간이 걸린다.

3. 업무평가에 사용하면, 과하게 시간을 설정하는 사람이 생긴다.

 

 

그러다 보니, 단점들을 해결하기 위해서는, 긴급하게 들어오는 업무로 진행중이던 업무가 밀린다면, 왜 해당 업무가 밀리게 되었는지 다른 팀원이 확인 할 수 있도록, 히스토리를 남겨두는 것이 좋고, 업무평가에 4h짜리를 2h만에 했는가? 이러한 평가는 사용하지 않는 것이 좋다.