야근하지 않기

모든 프로젝트는 한정된 자원으로 정해진 시간내에 끝내는 것입니다.

프로젝트는 요구사항이 실행되는 과정을 의미합니다.

요구사항이 변경되면 구현할 시간이 늘어납니다.

여기서 부터 시작합니다. 요구사항이 변경되면 구현할 시간이 늘어난다는 의미를 꼭 기억해야 하고, 같이 일하는 사람들이 공감해야 합니다.

그래서 고객은 시간이 부족하면 야근을 하면 되지 않겠느냐라고 말을 합니다.

이 생각들을 고치는 것은 바로 거기서 일하는 사람들입니다.

먼저 개발자들은 요구사항을 잘 이해하고 정의해야 합니다.

문서를 쓰라는 것이 아니라, 이해할 수 있는 문장으로 고객을 설득해야 합니다.

경력이 아무리 많은 사람이라 할지라도, 요구사항을 분석하는 일은 매우 어려운 작업입니다.

그래서 그림을 그리면서 최대한 이해시킬 수 있도록 설득해야 합니다.

고객의 요구사항은 모두 다 해달라는 것입니다. 그러나 모두 다 할 수는 없습니다.

한정된 시간에는 한정된 요구사항만 할 수 있습니다. 즉 요구사항의 우선순위를 결정하는 것이 핵심입니다.

그래서 항상 시간과 자원을 이야기 해야 합니다. 요구사항이 변경되거나 늘어나면 시간이 늘어나는 것을 고객에게 인식시켜 주어야 합니다.

꼭 해달라고 한다면 우선순위를 변경해서 다른 요구사항을 제거 해야 합니다.

위에서 말한 논리를 고객에게 설득시켜야 합니다. 그것이 통하지 않으면 좀 더 논리적인 방법으로 진행해야 합니다.

- 회의에 들어갔다 나오면 모두 동의한 내용을 적어 꼭 회의록을 써서 메일로 보낸다.

- 회의록에는 결정된 사항과 일에 대해 "언제까지"를 꼭 명시하고 날짜를 지킨다.

- 변경된 요구사항은 이전에 결정된 메일을 첨부해서 기존에는 언제까지 할 예정이었다는 것을 꼭 명시하고, 변경되면 언제까지 할 수 있다고 다시 보낸다.

이 과정들을 왜 개발자나 엔지니어가 해야 한다고 반문할 수 있습니다. 이건 PM이 할 일이라고 생각할 수 있습니다. 누구든지 한명이라도 하고 있지 않다면 개발자던 엔지니어건 해야 합니다.

번거롭다고 생각할 수도 있습니다. 그러나 합리적이기 위해서는 번거로워야 합니다.

그리고 계속적으로 회사에서 혹은 고객이 무리한 야근을 요구할 경우에는,

이러면 제 건강을 지켜야 하는 관계로 프로젝트를 더 이상 진행할 수 없다고 명확히 의사를 밝힙니다.

본인의 건강을 본인이 지키는 것이지 시스템 탓만 하는 것 자체가 바보스런 생각입니다.

어차피 합리적인 사고방식은 꾸준히 요구 하고 저항해야지 변화되는 것입니다.

그래서 야근이 당연하다는 문화를 변화시키기 위해서는 요구사항을 잘 정리하고 체계적으로 문제를 정의하는 습관부터 들여야 합니다.

a little passion