이 글은 이렇게 활용하세요
- 비효율적인 업무 프로세스를 뜯어고치고 싶은 관리자: 열심히 해도 성과가 안 나서 업무 프로세스의 효율을 높이고 싶다면, 이 아티클을 읽어 보세요. '스프린트' 도입 후 3년 동안 개선해온 퍼블리의 사례가 담겨 있습니다.
- 스프린트가 그저 짧은 시간에 더 많은 일을 하도록 팀원들을 쥐어짜는 제도라고 생각하는 실무자: 짧은 기간에 해야 할 일만 왕창 주어지고 실무자가 모든 부담을 지고 있다면, '스프린트'를 잘못 활용하고 있기 때문입니다. 이 아티클을 읽고 '스프린트'를 제대로 써먹어 보세요.
'스프린트'를 도입한 퍼블리의 3가지 고민
제가 퍼블리 콘텐츠 '문제를 효과적으로 해결하기: 퍼블리 제품팀의 스프린트'*를 쓴 지 거의 3년이 지났습니다. 그동안 퍼블리의 스프린트에는 많은 변화가 있었는데요. 퍼블리 팀원들의 고민과 시도를 공유하고자 합니다.
* 이 아티클을 읽으면서 스프린트에 더 관심이 생겼다면, 이 글도 읽어보실 것을 권합니다.
먼저 '스프린트'에 대해 말씀드릴게요
'스프린트'라는 개념이 가장 처음 만들어진 건 소프트웨어 엔지니어링 분야였습니다. 스프린트라는 개념이 없었을 때는 대부분 다음과 같이 일했습니다.
1) 누군가가 1년짜리(또는 그 이상의) 제품 로드맵을 만든다.
2) 로드맵에 따라 엔지니어가 1년간 그대로 구현한다.
3) 1년 뒤에 만들어진 제품을 짠 하고 공개한다.
하지만 이렇게 일하다 보니 문제가 생깁니다. 처음에 만들어진 제품 로드맵이 1년 동안 자꾸 바뀌는 것입니다.
- 왜 이런 문제가 생길까요? 1년은 긴 시간입니다. 고객에 대한 가설이 달라졌을 수도 있고, 아니면 회사의 전략이나 외부 상황이 바뀌었을 수도 있겠죠. 제품 구현을 위해 열심히 일하던 엔지니어는 자꾸 바뀌는 로드맵을 보면서 화가 납니다. 특히 엔지니어는 오랜 시간 집중해서 일을 해야 하는 직무이기 때문에 이렇게 저렇게 바꿔 달라는 요청이 잦아지면 생산성이 급격히 떨어집니다.
