이번 글에서는 프로젝트를 진행하며 일정 분배의 어려움을 겪었던 경험, 이를 해결하기 위해 도입한 man day 프로세스, 그리고 이를 통해 기대했던 효과와 실제 진행 상황을 공유하려고 합니다!
문제 상황
우선 문제의 시작은 저로부터 비롯됐는데요! ㅋㅋ.
저는 원래 열정이 많고 프로덕트에 애정이 깊은 편이라, 프로젝트에 시간을 아낌없이 쏟아붓는 스타일입니다. 파트별로 비슷한 양의 일을 나눠 맡아도, 저는 일을 빨리 끝내는 편이어서 금방 새로운 작업을 찾아 나섰고, “더 기여할 수 있는 게 없을까?”를 늘 고민했습니다.
그러다 보니 프론트엔드 파트에서 제가 너무 많은 일을 하고 있다는 생각이 들었어요. 혹시 내가 처리한 작업 중에 다른 팀원이 하고 싶었던 건 없었을까? 하는 염려가 들었고, 실제로 2주 동안 제가 해결한 이슈는 60개로, 다른 프론트 팀원 대비 2~3배 이상 많았습니다.
해결된 이슈들을 보면서 3가지 생각이 들었는데요.
- 내가 너무 많은 일을 해서 다른 팀원이 할 일이 없는 것이 아닐까?
- 아니면 다른 팀원들이 나보다 시간을 덜 쓰는 건가?
- 욕심이 너무 많은 나의 문제인가?
라는 생각이 끊임 없이 공존했어요. 그리고 이건 프론트엔드 문제만이 아닌, 전체적으로 비슷하게 불균형하다고 느꼈어요.
제가 느낀 문제를 스프린트 회의에서 팀원들에게 공유했고, 주말 동안 어떻게 하면 이 문제를 해결할 수 있을지 고민했습니다. 제가 생각한 문제의 본질은 각자의 작업량이 고르게 분배되고 있는지는 알 수 없다는 점이었어요.
저는 주말 내내 어떻게 하면 일을 공평하게 나눌 수 있을까?, 작업량을 객관적으로 볼 수 있는 방법이 없을까?를 생각했습니다. 단순히 이번 주에는 이 기능을 내가 할게로 끝나는 게 아니라, 이 작업이 대략 얼마만큼의 시간을 필요로 하는지까지 사전에 공유하고 싶었어요. 그래야 팀원 모두가 비슷한 수준의 작업량을 가져갈 수 있고, 서로에 대한 오해나 불만도 줄일 수 있을 것이라고 생각했습니다.
Man Day 도입 - 해결 과정
저는 평소에 시각화의 힘을 믿는 편인데요.
머릿속으로만 생각하는 것보다, 펜을 잡고 직접 적어보거나, 눈에 보이는 형태로 만들어야 상황이 훨씬 명확해지더라구요. 그래서 이번에도 문제 해결의 첫걸음을 ‘눈에 보이게 만드는 것’에서 시작했습니다.
Man Day란?
man day는 말 그대로 1일 업무량을 뜻해요. 해당 프로세스를 이야기하는 시점이 월요일었는데요. 이번주에는 화수목금 총 4일의 시간이 있었고, 10~18시까지 캠퍼스에 머물고, 점심시간을 제외하면 하루 프로젝트에 쓸 수 있는 시간은 7시간이었어요. 저희는 1시간 = 1md로 계산했습니다. 즉, 한 사람당 이번 주에 28md 사용이 가능했어요.
이건 첫번째 레슨. 해야 할 일 모두 꺼내기
먼저 공통적으로 해야 할 일과 FE/BE별 작업들을 전부 리스트업했습니다. 머릿속에 흩어져 있던 모든 작업들을 테이블 위에 올려놓는 과정이었어요.
그다음, 각 기능별로 누가 해당 기능을 맡을지와 소요 md를 하나씩 적었습니다. 여기서 중요했던 건, 각 분야별로 우선시되어야 하는 핵심 작업들을 먼저 확정하는 것이었어요. (그렇게 프론트 공통 미션은 버려졌어요)
이렇게 정리하다 보니 어떤 작업을 누가 맡아야 하고, 각자 얼마나 바쁜지가 한눈에 보이기 시작했습니다. 만약 공통 기능이 생기면, 남은 md가 많은 사람이 가져가도록 자연스럽게 조정할 수 있었어요.
이건 두번째 레슨. 재조정하기
계산된 결과를 보니, 예상했던 대로 누군가는 너무 많은 일을, 누군가는 상대적으로 적은 일을 맡게 되어 있었습니다. 이 지점에서 재조정이 시작되었어요.
예를 들어, 저의 경우 다른 팀원들에 비해 현저히 적은 md가 할당되어 있었어요. 그래서 공통 작업 중 일부를 가져와서 전체적인 배분 균형을 맞췄어요. 이런 식으로 md 계산을 통해 실시간으로 작업량을 조정할 수 있었습니다.
(FE 공통의 디자인 변경 작업을 가져갔어요!)
이건 세번째 레슨. 버퍼 시간 추가하기
어느 정도 분배가 완료되면, 리뷰를 보는 시간과 반영하는 시간 (과 떠드는 시간)을 별도로 추가했습니다. 저희는 팀원이 맡은 하나의 테스크 당 +3md로 지정했어요.
개발만 하고 끝이 아니라, 서로의 코드를 리뷰하고 피드백을 반영하는 시간까지 고려해야 현실적인 계획이 된다고 생각했거든요.
실제 오프라인으로 팀원들과 적어가면서 진행한 화이트 보드에요!(이름 옆에 적힌 md는 버퍼 시간을 포함한 총 md이에요.)
각자의 의견을 실시간으로 반영하고, 서로가 납득할 수 있는 방향으로 조정해 나갔어요.
이 과정에서 재미있었던 순간은, 어려워 보이는 작업에 대해 낮은 md를 할당하려 할 때의 반응이었습니다. 자신 있어? 정말? 믿는다ㅋㅋ?라는 장난스러운 반응과 함께 현실적인 검토가 이뤄졌어요. 이런 과정을 통해 자연스럽게 더 합리적인 md 조정을 할 수 있었습니다!
전체적으로는 가능한 한 보수적으로 md 할당을 진행했어요. 낙관적인 예상보다는 여유를 두고 계획하는 편이 나중에 발생할 수 있는 문제들을 미리 방지할 수 있다고 생각했거든요.
그리고 팀 내에서 하나의 원칙을 정했습니다: 만약 할당된 md를 다 써도 이슈 해결을 못했다면, 그건 일과 시간 이후에 책임감 있게 마무리해 오자! 라는 룰이요. 단순히 압박을 주려는 게 아니라, 계획의 신뢰성을 높이고 팀 전체의 일정을 지키기 위한 약속이었어요. 각자가 자신의 예상에 대해 더 신중하게 생각하게 되는 효과도 있었고요.
기대 효과와 실제 변화
mad day 도입 후 너무 뿌듯해서 캡처해둔 화면인데요. 이제는 모든 팀원이 md라는 공통 기준 아래에서 자신이 어느 정도 시간을 투자했는지 명확히 파악하고 움직이고 있습니다! 목표한 md를 채우지 못한 부분이 있다면, 적극적으로 보완하려는 모습도 보입니다! (투다 칭찬해~)
외에도, 도입 이후 어떤 변화가 있었는지 개인적인 느낌을 공유하려 합니다!
1. 투명성과 예측 가능성 향상
가장 큰 변화는 시각적 투명성이었어요. 사전에 "이 작업에는 대략 이 정도 시간이 소요될 것"이라는 예상치를 공유하고 개발을 시작하니, 서로에 대한 오해가 현저히 줄어들었어요. 이전에는 "왜 저렇게 오래 걸리지?", "나만 바쁜 건가?"라는 생각이 들었다면, 이제는 각자의 작업량과 난이도를 객관적으로 비교할 수 있게 되었습니다.
2. 공평한 업무 분배
모든 팀원이 비슷한 수준의 일감을 할당받게 되면서 이전에 느꼈던 불균형 문제가 크게 개선되었어요. 더 이상 "누군가는 과로하고, 누군가는 할 일이 없는" 상황이 발생하지 않게 됐다고 느꼈어요.
3. 책임감과 주도성 증가
md라는 명확한 기준이 생기니, 각자가 자신의 진행 상황을 스스로 모니터링하게 되었어요. 목표한 만큼 진행하지 못했을 때는 자발적으로 보완하고, 노력하는 모습을 보였습니다.
가장 눈에 띄는 변화는 개인의 책임감이 명확해졌다는 점이에요. 이전에는 "내가 얼마나 일했는지"가 모호했다면, 이제는 md를 통해 구체적으로 파악할 수 있게 되었거든요. 그러다 보니 각자가 자신의 할당량에 대해 더욱 책임감을 가지게 되었습니다.
또 다른 팀원들의 작업량도 한눈에 보이게 되면서 서로의 상황을 이해하는 폭이 넓어졌어요. "저 사람이 지금 바쁘구나" 또는 "나는 지금 여유가 있구나"를 객관적으로 판단할 수 있게 된 것이죠.
이런 변화들을 보며, man day가 단순한 시간 관리 도구를 넘어서 팀 내 소통과 이해의 기반이 되었다는 걸 실감할 수 있었습니다!
끗
물론 해당 방법이 무조건 정답은 아니라고 생각하고, 도입 후에 문제가 생긴다면 유연하게 조정해 나갈 예정이에요! 더 좋은 방법이 있다면 제안해주셔도 너무 좋습니다!
문제상황에 대한 원인을 본인한테서 먼저 찾아보고 해결책을 바로 팀원들과 논의 후 도입해본 점이 인상깊네요! 확실히 협업이다보니 이런 부분은 특정 시스템을 도입하는게 효율 측면에서 좋은것 같네요:)