'야근을 하지 말자'라는 과거 직장인 시절 작성한 아티클을 브런치에 올린 후 스타트업 지인 대표님께서 회사 사정상 빠르게 성과를 만들어야 하는 상황인데 직원들에게 전면 야근을 요청해야 할지, 어떻게 하면 좋을지 코칭을 요청해 주셨습니다.
야근은 경영진과 직원들의 영원한 딜레마이자 어려운 숙제인데요. 저는 법적 문제를 떠나 회사가 궁극적으로 원하는프로덕트 회사의목표 달성 관점에서 한번 풀어보고자 합니다.
고정적이거나 복잡도가 낮은 제품을 생산하는 전통적인 제조업에서는 야근은 생산성과 거의 직결되었기 때문에 효과적인 수단일 수 있었습니다. 그러나 IT 프로덕트를 만드는 일, 특히 고객의 피드백을 확인하여 효과적인 UX를 설계하고 복잡한 코드로 동작하는 제품을 만드는 경우에는 야근에 대해서 좀 더 세밀한 접근이 필요합니다.
먼저 고객향의 IT프로덕트 회사가 야근을 하면 성공확률이 높아질까요? 만약 그렇다면 야근을 가장 많이 하는 회사가 가장 큰 성공을 해야 할 텐데 현실에서의 결과는 꼭 그렇지는 않습니다. 그렇다면 프로덕트가 성공을 위해서 필요한 것은 무엇일까요? 간략히 얘기하자면 고객의 욕구에 맞는 경쟁력 있는 제품을 빠르고 완성도 있게 시장에 내놓는 것일 겁니다.
이 것을 또 분해해 보면 - 고객의 욕구에 맞는
- 경쟁력 있게
- 빠르게
- 완성도 있게
제품을 시장에 내놓는 회사가 성공을 할 텐데요.
위처럼 빠르다는 것은 하나의 요소일 뿐 빠르기만 해서는 성공을 담보하지는 않습니다. 이 프로덕트 성공을 위한 도미노 중 야근, 즉 시간의 추가 투입이 유효한 시점은 아래와 같습니다.
1. 피쳐 선정을 위한 데이터 분석작업
2. 유저스토리/정책 작성과 UI 작업
3. 개발/테스트 작업
4. 고객반응 데이터 분석 작업
그리고 다시 2번으로...
이렇게 나열하고 보니 대부분의 생산작업이네요. 문제는 이 것들이 동시에 이루어지지 않는다는 것입니다. 각 생산 단계에 맞춰 시간투입을 집중할수록 생산성이 높아지는 거죠. 따라서 프로덕트 회사는 일률적인 야근보다는 각 단계의 담당자들이 시간을 투입해 본인의 과업을 빨리 마치고 다음 단계에 있는 사람들에게 빨리 전달해 주는 것이 가장 효율적으로 생산과정을 단축하는 방법일 것입니다.
그런데 또 여기서 유의할 점이 있습니다. 각 담당자의 산출물에 퀄리티가 떨어지면 목표를 달성할 수 없다는 것입니다. 산출물의 퀄리티는 조직원의 능력과 집중도에 달려있습니다. 이 산출물의 퀄리티를 충분히 낼 조직원의 역량이 부족할 경우는 리더나 동료들의 도움이 필요합니다. 그리고 집중도는 피로도와도 직결되어 있습니다. 졸면서 짠 개발자의 잘 못된 함수나 코드 한 줄이 버그를 일으킬 수도 있으니까요.
결론적으로 얘기하자면 IT프로덕트 회사에서는 전 직원의 집중도를 일정 수준 유지하고 협업커뮤니케이션의 밀도를 올리면서 각 생산단계에 시간을 단축할 수 있는 생산 전략이 필요합니다.
이를 위한 생산전략은 크게 2가지를 예를 둘 수 있습니다.
1. 단기성일 경우 전사 프로젝트화
1~2달 정도 명확한 목표를 설정하고 프로젝트화 하는 것입니다. 목표와 스펙이 명확한 과제를 프로젝트팀을 만들어서 짧은 시간에 진행하여 생산과정의 투입시간과 커뮤니케이션 밀도를 높여서 생산 퍼포먼스를 극대화하는 것입니다. 다만 그 기간이 너무 길어지면 사람들의 피로도는 높아지고 집중력이 떨어지게 됩니다. 따라서 생산성에 역효과가 나서 후속 과제에 영향을 줄 수 있으므로 프로젝트 후에는 1~2주 정도의 안정화 기간을 주는 것이 좋습니다.
집중해야 할 목표와 결과가 불명확할 경우 사람들은 목표의식 없이 눈치 보는 야근을 하게 될 수 있습니다. 그에 따라 회사가 기대하는 실질적인 효과는 낮아지고 부정적인 여론이 형성되는 등의 역효과를 줄 수 있습니다.
만약 3~4달 정도의 과제라면 2~4개의 프로젝트가 연속적으로 있는 로드맵 형태로 진행하는 것도 방법입니다.
2. 중장기성일 경우는 효과적인 생산을 위한 프로덕트 조직의 문화와 룰 조성
과제가 몇 달로 끝나는 일이 아니고 지속적인 결과를 만들어야 하는 거라면 프로젝트보다는 문화나 룰로 접근하는 것을 추천드립니다. 이를 위한 접근 방법은 아래와 같습니다.
첫째, 각 담당자들이 본인의 과제를 완성도 높게 빠르게 끝내는 문화. 특히 시간에 맞춰 일을 하는 게 아니라 중요한 과제를 맡았을 때는 일에 맞춰 시간을 투입하는 문화를 자연스럽게 확립시키는 게 좋습니다. 또는 차기 과제 계획을 세워 미리 준비해 두는 체계도 좋습니다. 이런 문화와 체계를 만드는 건 리더들의 강압적이지 않고 자연스러운 리딩이 매우 중요합니다. (네이버 재직시절 커뮤니티팀 멤버들끼리 농담처럼 '일정은 생명, 품질은 자존심'이라는 얘기를 종종 했었던 기억이 나네요;;;)
자칫 위 이야기가 야근을 유도하는 것처럼 읽힐까 조심스러운데요. 제 이전 '야근을 하지 말자'라는 아티클에서 얘기한 것처럼 평소 개인적 준비 및 트레이닝을 통해 야근을 최소화하는 것은 중요합니다. 그러나 밀도 낮은 업무시간 활용으로 본인 때문에 전체 과제의 진행이 밀리거나 퀄리티가 떨어지는 건 지양해야 합니다.
둘째, 각자 작업을 하다 궁금한 것이나 문제가 생겼을 때 협업자에게 바로 물어보거나, 데일리스크럼 시간에 이슈공유를 하고 그러면 스쿼드팀이 바로 해결하여 담당자의 몰입도를 높이고 생산성을 올려주는 문화를 가지는 것이 중요합니다.
셋째, 리더는 각 조직원들의 생산속도나 퀄리티를 지속적으로 관찰하여 어려움을 파악하고 해결해 주는 노력을 해야 합니다. 제가 만난 테크리더는 번다운차트를 보며 해결속도가 늦어지면 해당 과제를 담당하는 팀원에게 혹시 도와줄 사항이 있는지 물어본다고 하더군요.
대표님들은 빠르게 소진되는 번레이트 앞에 직원들이 긴박하게 일했으면 하는 마음이 클 수밖에 없습니다. 그러나 복잡한 협업구조와 코드로 돌아가는 프로덕트를 가진 IT회사에서의 일률적인 야근은 자칫 독이 될 수 있습니다. 어려울수록 조직원들과 필요상황에 대한 공감을 얻고 더욱 전략적인 접근을 하면 좋겠습니다.
