칼럼 | 업무를 계획하라, 계획대로 업무하라

생산성
2019 데브옵스 현황 보고서(State of DevOps Report)는 생산성을 “...최소한의 산만함과 방해로 시간이 소모되고 복잡한 작업을 완료할 수 있는 능력”으로 정의한다. 이 정의에 따르면, 생산적이기 위해서는 충족되어야 하는 몇몇 조건들이 있다.

- 시간 블록 (우왕좌왕하는 15분이 아님)
- 최소한의 산만함 
- 복잡한 작업 

피터 드러커는 1967년 자기경영노트(The Effective Executive)에서 “그저 바쁜 것에서 성과를 거두는 것으로 바꿀수록, 지속적인 노력(결실을 맺기 위한 꽤 많은 시간이 필요한 노력)에 집중할 수 있게 될 것이다”라고 적었다.

앞서의 인수 사례로 돌아가보자. 이들 조건 중 어느 것도 충족되지 못하는 상황이다. 그 팀은 끊임없이 호출되고 있었는데, 이는 곧 집중적으로 일할 수 있는 시간 블록이 없다는 것을 의미했다. 호출 자체가 끊임없이 주의를 산만하게 하는 원천이었다. 

호출 이후 해야 할 조치는 결코 복잡하지 않았다. 경고를 끄기 위해 간단한 조치만 필요했다. 엔지니어들은 항상 그들이 얼마나 많은 일을 해야 하는지에 대해 이야기했지만, 그것은 모두 ‘고생’에 불과했고, 결코 생산적인 일이 아니었다. 

생산적이 되기 위해서는 일을 계획하고 계획한 대로 실행해야 한다. 눈앞의 일에만 매달린다면 결코 생산적이 될 수 없다. 사실 위와 같은 상황을 벗어날 수 있는 유일한 방법은 생산적이 되는 것이다.

시간 블록
시간이 많이 걸리는 일을 하려면 시간을 확보해야 한다. 드러커는 다음을 관찰했다.

“유능한 경영진들은 시간이 제약 요인이라는 것을 알고 있다... 다른 주요 자원 중 돈은 사실 꽤 풍족한 편이다... 세 번째 제약 자원인 사람의 경우에는 고용하면 된다. 비록 좋은 인재를 충분히 고용할 수는 없더라도 말이다. 그러나 더 많은 시간을 얻기란 까다롭다. 시간은 빌릴 수도 살 수도 고용할 수도 없는 존재다.” 

시간을 더 만들 수 있는 능력이 없다면, 가진 시간을 가지고 최대한 효과적이어야 한다. 

애자일
시간을 효과적으로 활용하는 방법 중 하나는 일을 구조적으로 처리하는 것이다. 스크럼에서 많은 의식(ceremony)을 갖는 이유 중 하나는, 팀의 산출물에 대해 최대한 예측 가능하도록 하기 위해서다. 

이 중에서 스프린트 플래닝은 아마도 생산적인 일에 가장 중요한 것일 것이다. 이 회의에서는 과거의 실적에 근거해 얼마나 많은 작업을 맡아야 하는지, 그 구체적인 작업 항목은 무엇인지에 대해 합의한다. 이 예측 가능한 결과물은 정의상 생산적인 결과물이다. 또한 다음에서 논의하는 우선순위 백로그를 기반으로 한 결과물이기도 하다. 

스크럼팀이 성과를 내기위해서는 생산적이어야 한다. 속도가 극도로 낮거나 스프린트에서 스프린트까지 크게 변화하는 팀이 생산적일 가능성은 거의 없다. 

20% 시간    
구글의 20% 시간 아이디어에 대해 여러 이견들이 있지만, 새 아이디어를 탐구하기 위한 목적으로 시간을 따로 할당한다는 접근법은 고민해볼 가치가 있다. 

이 탐구(즉, 혁신) 시간의 산출물은 종종 복잡하며, 그것이 새로운 제품으로 이어지든 그렇지 않든 그것은 꽤나 생산적인 시간일 수 있다. 구글은 생산적이지 않은 일을 설명하는 용어를 하나 가지고 있는데, 이는 글 말미에서 살펴보도록 하겠다. 

최소한의 산만함 : 우선순위 설정 
산만함을 최소화할 수 있는 가장 좋은 방법 중 하나는 팀의 우선 순위가 무엇인지 명확히 하는 것이다. 각자의 일에 대해 어떻게 생각해야 하는지에 대한 전반적인 접근법을 제공하는 한편, 올바른 사고방식을 팀이 갖도록 한다. 

생산적이기 위해 해야 할 일은 구조화된 방식으로 우선 순위를 매기는 것이다. 이것은 이미 우선순위가 아닌 작업 항목에 대한 백로그를 준비하는 리더(스크럼에서는 프로덕트 오너다)와 함께 하는 팀들을 의미한다. 업무에 대해 토론하고 순위를 매긴다는 의미도 있다. 

한편 팀이 지도부와 백로그 우선순위를 협상할 때, 주의할 점이 있다. 반응적인 업무를 완전히 도외시해서는 안 된다는 것이다. 도입부에 있었던 상황을 예로 들자면 끊임없이 호출되는 상황에 대해 몇몇 팀원들을 반응적인 작업에 배정할 수 있었을 것이다. 이를 통해 팀원 전체를 소진시키는 것이 아니라 그러한 종류의 일을 처리하는 데 전념하는 다른 팀원들도 배정할 수 있을 것이다.

4가지 플로우 형태 
우선순위 지정 중에 작업을 할당하는 경우, ‘프로젝트에서 프로덕트로(From Project to Product)’에서 미크 커스텐 박사가 제시한 4가지 유형의 플로우 항목에 따라 그렇게 할 수 있다.

- 기능(Feature)
- 결함(Defect)
- 위험(Risk)
- 채무(Debt)