야근없는 프로젝트일정 만들기
한번하면 습관, 습관이 모이면 문화가되는 야근
프로그래머라는 직업이 야근이 많다는건 이제 일반상식이 되었다. 개발자 격언중에는 “The best coding happens after midnight.”(최고의 코딩은 자정 이후에 이뤄진다) 라든지 “A developer’s real work begins when the office turns silent.”(개발자의 진짜업무는 사무실이 조용해지고나서부터 시작이다)같은것들이 있다. 앞서 알아본것 처럼 적극적인 관리가 없다면 개발자는 야근할 수 밖에 없는 상황에 쉽게 몰린다. 하지만 야근은 프로젝트 운영을 하는데 필수 요소가 되선 안된다. 론 제프리가 쓴 “초과근무가 생산성에 미치는 영향” 글에 따르면 10%의 Overtime근무는 생산성을 2.4% 감소시킨다고 한다. 야근이 장기화되면 여기서 오는 생산성 저하는 제품에 영향을 주기 마련이다. 게임 업계에서 ‘크런치 모드‘라고 몇달동안 구성원들의 시간을 갈아넣어 출시한 게임이 출시 직후 버그가 쏟아지는 일은 결코 이상한 일이 아니다. 이런 상황에 구성원들의 창의적이 생각이나 아이디어가 감소되는건 자연스러운 현상이다.
야근은 한 번 하면 습관이 되고, 습관이 되면 문화가 된다. 기획자, PM의 입장에서 야근없는 프로젝트 일정으로 처음부터 야근을 예방할 필요가 있다.
현실적인 일정 추정의 기술
각자의 시간은 스스로 관리하는것이 원칙이다. 다만 구성원들 중 개발자만 야근을 하고 있다면, 우리가 그들의 작업에 드는 시간을 잘못 추정하지는 않았는지 점검해야 한다. 개발자의 편을 들자면 개발일정을 산정하는건 정말 어려운 일이다. 예상한 기간보다 길게 잡아도 문제, 짧게 잡아도 문제다. 개발자와 협의하여 적정기간으로 일정을 설정했더라도, 개발 진행 중에 전혀 예상하지 못한 부분에서 기술적 한계가 등장한다던가 도무지 이해가 안가는 버그가 발생하곤 한다. 그럼 일정은 자연스레 촉박해지고 실제보다 일정을 짧게 잡은 샘이 된다. 그럼 자연스럽게 개발자들의 초과근무로 이어진다.
전혀 예상치못한 기술문제나 버그는 단어 그대로 추정하는 시점에 예측이 불가능하기때문에 PM으로서 버퍼시간을 추가하는 것 외에는 뾰족한 방법이 없다. 개발자들뿐만 아니라 우리 모두가 '낙관적 편향'에 빠지기 쉽다. 이는 인간이 본질적으로 가진 인지적 오류로, 작업 완료에 필요한 시간을 실제보다 짧게 예측하는 경향을 말한다. 특히 새로운 기능을 기획하거나 익숙하지 않은 영역의 작업일수록 이러한 편향은 더 심해진다.
이러한 낙관적 편향을 극복하고 현실적인 일정을 수립하기 위한 몇 가지 방법이 있다. 첫째, '계획 오류'를 인식하는 것이다. 과거 프로젝트에서 유사한 작업에 소요된 실제 시간을 기록하고, 이를 새로운 일정 계획에 반영해야 한다. "지난번 로그인 기능 개발에 2주가 걸렸으니, 이번에도 최소 그 정도는 예상해야겠다."라는 접근이 필요하다. 잊지 말아야 할 점은, 적어도 이정도 시간은 필요하겠지 라는 생각으로 접근해야한다는 것이다. ”2주면 정도면 충분하죠?“라는 방식으로 소통한다면 구성원들의 영역을 침범하는 일이기에 주의해야한다.
둘째, 개발자와 함께 작업을 더 작은 단위로 분해하도록 유도하는 것이다. 큰 작업은 추정하기 어렵지만, 작은 단위로 나누면 각각에 대한 시간 예측이 더 정확해진다. 기획 단계에서 "로그인 기능 구현"이라는 큰 작업보다 "사용자 입력 폼 디자인", "입력 유효성 검사", "인증 로직 구현" 등으로 나누어 요구사항을 정리하면 개발자가 더 정확한 시간 추정을 할 수 있다.
셋째, 프로젝트 관리자 입장에서 불확실성을 고려한 버퍼를 설정하는 것이다. 모든 작업에는 예상치 못한 문제가 발생할 가능성이 있으므로, 전체 일정에 여유를 두는 것이 중요하다. 일반적으로 작업의 복잡성과 불확실성에 따라 20-50%의 버퍼를 추가하는 것이 권장된다. 예를 들어, 개발팀이 5주가 걸릴 것으로 예상하는 작업에는 전체 일정에서 7-8주의 시간을 할당하는 것이 현실적이다. 일단위의 일정을 계획한다면 일주일중 하루정도는 버퍼를 확보하고 이슈 발생시 시간을 할당해주면 좋다.
물론 반대의 경우도 고려해야 한다. 개발팀이 지나치게 안전하게 일정을 산정하여 프로젝트가 불필요하게 길어질 수도 있다. 이는 파킨슨의 법칙(작업은 주어진 시간을 채우는 경향이 있다)에 따라 실제 필요 이상의 시간을 소비하게 만들 수 있다. 그러나 실무에서는 일정을 과도하게 길게 잡는 경우보다 낙관적으로 짧게 잡는 경우가 훨씬 더 일반적이며, 이로 인한 야근과 품질 저하의 문제가 더 심각하다.
일정 압박의 근본원인 해결하기.
항상 일정은 타이트하다. 그리고 그 원인은 프로젝트 안팎으로 다양하다. 경영진이나 임원에게 보고한 납기를 준수하기 위함일수도 있고, 확보하기 어려운 마케팅 리소스를 미리 잡아둔 경우 마케팅 일정을 맞추기 위해 압박을 느끼기도 한다. 또 경쟁사의 서비스를 따라가기 위해서나 그보다 앞서 나가기 위해 무리한 일정을 강행하는 일이 다반사다.
이를 건설적으로 극복하기 위한 방법으로 투명하게 의사소통하는것을 생각해볼 수 있다. 일정 제약, 잠재적 위험, 그리고 기한을 맞추기 위해 필요한 트레이드오프에 대해 이해관계자들과 솔직하게 논의해야 한다. 현실적인 기대치를 관리하면서도 품질 높은 결과물을 제공하겠다는 의지를 보여주는 것이 중요하다. 또한 경영진에게 무리한 일정이 가져올 수 있는 위험성과 비용을 데이터와 함께 제시하여 더 현실적인 타임라인을 협상할 수 있다.
조직 안에도 일정을 타이트하게 만드는 요인들이 있다. 기술 부채는 시간이 지날수록 쌓여 새로운 기능 개발 속도를 늦추는 주요 원인이 된다. 또한 불충분한 문서화로 인해 함께 일하는 동료 개발자들이 코드를 이해하는 데 더 많은 시간을 소비하게 된다. 팀 간 의사소통이 원활하지 않으면 중복 작업이나 오해를 불러일으켜 일정 지연으로 이어진다. 리소스 할당이 최적화되지 않았을 때도 일정 압박이 가중된다. 개발자별로 해왔던 분야와 잘하는 영역이 있는데 이를 고려하지않고 단지 ‘한명’으로 판단해 업무를 배치하면 비효율을 낳는다.
내부의 요인들을 관리하기 위해 기술 부채를 해결하기 위한 일정을 분리해서 정기적으로 산정하는것이 좋다. 명확한 문서화 표준을 수립하고, 팀 간 정기적인 동기화 미팅을 통해 의사소통 문제를 해결해야 한다. 무엇보다 중요한 것은 작업을 더 작은 단위로 분해하여 진행 상황을 면밀히 모니터링하고, 문제가 발생했을 때 신속하게 대응할 수 있는 관계와 체계를 갖추는 것이다.
개발자 생산성 극대화 전략
건설현장에 가보면 메인 작업자 외에 속칭 ‘시다‘라는 보조 작업자를 붙여서 작업의 효율을 높인다. 최고의 생산성을 낼 수 있는 기능공을 ‘비싼 돈 주고’ 데려왔는데 불필요한 일들로 그들의 시간을 낭비하는건 프로젝트 단위에서 큰 낭비다. 실제로 프로그래머들의 임금은 높다. 그들이 최고의 작업물을 생산할 수 있도록 환경을 만드는 전략이 필요하다.
각 업무에 몰입해 ’플로우 상태’에 도달하기 위해서는 일정크기 이상의 덩어리 시간이 필요하다. 적어도 90분에서 120분 이상 집중해 몰입할수있는 시간을 확보해줘야 한다. 또 그 시간동안에는 말을거는 등 방해하는것을 지양해야 한다. 이는 즉각적으로 개발자들의 야근시간을 줄이고 코드품질로 나타날 것이다.
장인은 도구탓을 하지 않는다고하지만 개발자에게는 좋은 도구를 손에 쥐어주면 그만큼 성과가 올라간다. 그들이 선호하는 물리적인 작업환경, PC나 책상 그리고 주변기기 등은 현실적인 범위 안에서 반영할 필요가 있다. 이것만큼 중요한것이 비효율을 막는것인데 사내보안정책이 대표적으로 비효율을 선도한다. 법이나 규제를 벗어나지 않는 선에서 그들의 자율성을 보장하고 적극적으로 불편사항을 접수해 해결해나가야 한다. 말수가 별로 없는 샤이 개발자들은 불편해도 묵묵히 견디곤 하는데 걸림돌을 우리가 나서서 해결해주면 그들의 호감도 사고 생산성도 높일 수 있다.
지속가능한 야근없는 문화 구축
야근도 기업문화에 속한다. 2013년 SBS ‘리더의 조건‘ 프로그램에서 파주 헤이리마을에 위치한 제니퍼소프트의 사례를 다뤘다. 자율적인 기업문화를 보여줬고 회사는 꿈의기업 반열에 올랐다. 지속가능한 정시퇴근 문화는 개인의 노력만으로는 불가능하지만 각자의 노력없이는 달성할 수 없다. 각자의 업무시간 설정을 존중하고 서로 초과근무를 하고있지는 않은지 챙겨야한다. 시간이 지나면 퇴근을 독려할 필요도 있다.
성과 측정 방식을 업무시간이 아닌 결과로 재정의 해야한다. 정시에 퇴근하는 사람이 시간관리를 능숙하게 해내는 능력자로 평가받아야 한다. 상사나 조직원들에게 인정받기위해 오래 사무실에 앉아있는 고리타분한 조직원이 발생하지 않도록 조직을 관리해야 한다. 프로젝트 혹은 프로덕트 매니저로서 구성원들이 지치지 않았는지 모니터링하고 특정단계에서 진척이 되지 않는다면 조기에 개입해서 관리해주는 리더십이 필요하다. 데일리 스크럼 회의 10분은 이런면에서 유용하게 활용할 수 있다. 단지 그날의 할일을 서로 이야기하는것 만으로도 누군가 문제에 직면해있다는 것을 감지해 낼 수 있다.
결론
야근과 초과근무는 성실함의 지표가 아니며, 오히려 생산성을 떨어뜨리는 범인이다. 개발팀과 경영진 사이에서 현실적인 일정을 조율하고, 일정을 압박하는 대내외적인 요인들을 관리해 위협 요소들을 없애야 한다. 프로젝트에서 중요한 구성요소인 개발자들이 최고의 퍼포먼스를 낼 수 있도록 환경을 구성하고 우리 조직에서 지속가능한 행복을 이룰 수 있다면 오랫동안 능력있는 개발자와 함께 일할 수 있을 것이다. 게다가 기획자 여러분도 정시에 퇴근해서 저녁이 있는 삶을 살아야 하지 않은가? 프로젝트의 성공과 팀의 건강을위해 망설이지 말고 바로 실행에 옮겨야 한다.
