중요한 일 먼저하기

고 득점 전략

여러 가지 일을 여러 명이 하는 2가지 방법

학창 시절 시험 시간을 생각해 보자. 시험지를 받아서 

1번부터 마지막 번 문항까지 그냥 순서대로 푸는 것이 맞나?
전체적으로 살펴보고 배점이 높고, 잘 풀 수 있는 문제를 먼저 푸는 게 좋은가? 

고 득점을 위해서는 전략이 필요하다. 업무도 마찬가지이다.

10가지 과제가 있다. 이 일을 동시에 진행하는 것과 중요한 과제를 먼저 진행하는 것의 차이를 보자. 10가지를 다 하는데 10개월이 걸린다고 가정해 보자. 5개월이 지났다. 

1. 10가지가 모두 50% 진행된 것과, 
2. 10가지 과제 중 중요한 3~4개의 과제의 완료된 경우

어떤 차이가 있을까? 

당연히 중요한 과제를 먼저 처리한 경우가 성과가 있을 것이고, 회사에 기여를 할 것이다. WIP(Work In Progress)를 줄여서 중요한 일을 몰입해서 처리해야 한다.

10개월이 되기 전에 나머지 일보다 더 중요하고, 더 높은 성과가 기대되는 새로운 과제가 생길 수도 있다. 그렇다면 나머지 과제를 미루고 높은 성과가 기대되는 중요한 과제를 먼저 하는 것이 맞다고 생각한다. 새로운 과제, 요구사항이 생긴다고 지금하고 있는 중요한 일에 방해가 되지 않아야 한다. 새로운 요청은 기록만 하고 현재 수행 중인 중요한 일이 그런 요청으로 밀리지 않도록 해야 한다.

변동성의 시대

지금과 같이 변동성이 크고, 예측 가능성이 적은 상황에서는 계획된 일 중에서 제일 중요한 일부터 해야 한다고 생각한다. 모든 일을 다 해야 할까? 할지, 말지를 두고 논쟁하면서 시간을 소비해야 할까?

모든 일을 다 해야 한다고 생각하는 사람은 일의 우선순위가 중요하지 않다. 어차피 다 할 테니... 아주 소소한 일도 중요한 일보다 먼저 해달라고 요청하기도 한다.

열심히 노력해서 결과를 만든다. 하지만 성과로 연결되어 회사에 기여하지 않는다면 그러한 노력과 결과는 가치가 매우 낮다.

이 그림은 Kent Beck이 Tidy First 블로그에 올린 글 중에 나오는 그림이다. 개발자의 생산성을 측정하는 방법에 대한 글이었는데 여기서 "노력/결과"와 "성과/기여"의 차이를 주목하자. 성과/기여를 하려면 주어진 일을 그냥 해서는 안된다. 중요한 일을 먼저 해야 한다.

이전에 어떤 현업 구성원으로부터 

"2년 전부터 요청한 사항인데 아직도 처리되지 않았다"

는 불만을 들은 적이 있다. 

이 이야기를 들은 사람들 중 어느 분은 저 구성원의 일도 중요한 일이니 빨리 해줘야 하지 않냐고 했다. 나는 반대로 이야기했다. 2년을 이야기했는데도 안된 것은 다른 중요한 일에 밀렸기 때문이다.

일이 생길 때마다 TODO 리스트, 백로그에 일을 추가한다. 그 일로 주의를 전환해서 방해받지 말아야 한다. 그리고 지금하고 있는 중요한 일을 마쳤을 때 다시 중요도를 감안해서 다음에 할 일을 정해야 한다. 원래 계획된 대로 무조건 진행해서는 안된다. 변동성이 너무 큰 세상이다.

계획은 실행 전에 완성되는 것이 아니라  "계획 → 실행 → 피드백/회고를 통한 추적  → 보정"의 과정을 반복하다가 실행이 완료되었을 때 비로소 계획도 완성된다

는 생각이 많이 드는 요즘이다. Speculation(추측)과 Specifications(명세서)가 같은 어근을 가지고 있다고 한다. 계획의 결과로 나오는 명세서도 추측인 것이다. 즉 변동 가능성이 높다는 것이다. 그러니 계획한 대로만 무조건 실행하는 것은 맞지 않는다.

회사에서 중요한 것은 중요한 일을 중요하게 대우해서 우선적으로 처리되도록 해야 한다. 그게 큰 성과로 이어져야 한다. 경영진/관리자는 그런 중요한 업무를 챙겨야 한다. 주간 회의 등의 업무 공유를 통해서...

일을 맡겼으면

프로젝트 관리 삼각형

프로젝트 관리의 삼각형에는

범위(기능, what)

시간(납기, when)

비용(cost, resource)

등이 존재한다. 이 3가지는 삼각형이 깨지지 않는 범위에서 사용자/경영진 등에서 정할 수 있다. 경영진은 사업의 성공을 위해 어떤 기능(범위)을 언제까지(시간), 어느 정도의 리소스(비용)를 사용해서 완성해 달라고 요청할 수 있다.

하지만 어떻게(how) 개발할지는 개발자가 제일 잘하는 영역이고, 개발자가 정해야 하는 영역이다.

비개발자가 개발에 대해서 어떻게 할지를 정해주려는 경우가 있는데, 이건 월권이라고 생각한다. 이러한 월권은 내가 사회생활을 하면서 절대 양보하거나 참을 수 없는 경우이다. 그냥 무엇(기능)이 언제까지 필요한지 알려주면 어떻게 할지를 아는 개발자들이 최대한 회사를 위해서 요구사항을 준수해야 한다. 그리고 모두 함께 좀 더 높은 성과로 회사에 기여할 수 있는 일에 집중해야 한다.

아들이 운전을 배우고 얼마 되지 않았을 때 조수석에 앉아서 이리가라 저리 가라, 이렇게 해라, 저렇게 해라 참견한 적이 있다. 그럼 아들은 

그냥 내비대로 가면 안 돼요?

라고 한다. 맞다 운전은 아들이 하고 있다. 내비대로 간다고 위험하거나, 그렇게 많이 느려지지도 않는다. 그렇다면 매우 긴급하고, 위급한 일이 아니라면 다소 부족하더라도 믿고, 맡겨주는 것이 맞다.

업무도 그런 것 같다. 그 업무를 수행할 사람들에게 맡겼으면 믿고 맡겨야 한다.