태스크 쪼개기
태스크 쪼개기의 목적
앞서 열심히 일하는데 필요한 몇 가지 방법에 대해 포스팅한 적이 있습니다.
오늘은 태스크 쪼개기 장점에 대해 설명하려고 합니다.
태스크 쪼개기의 목적
개인의 관점에서...
목표 지향적
태스크를 쪼갤수록 목표 지향적으로 일 할 수 있습니다.
태스크가 클수록 목표가 커지고 추상적이기 마련입니다. 이 경우 집중력에 붕 뜰 수 있습니다.
그리고 마감일이 다가와야만 제대로 일을 시작하는 학생 증후군의 발동 트리거가 되기도 하죠.
이런 식의 러프한 일정 수립은 지양합시다.
PvP 매칭 시스템 1주 차(5d)
PvP 매칭 시스템 2주 차(5d)
PvP 매칭 시스템 3주 차(5d)
사내에서 매칭 시스템의 일정을 3주를 잡았고 주마다 1, 2, 3 넘버링하면서 수립한 일정입니다.
이 일정은 각 태스크마다 무슨 일을 하는지 의도가 명확하지 않습니다. 추상적이고 진행률을 알아보기도 어렵죠. 이런 식으로 사내의 일정 시스템에 등록될 수 있습니다만 가급적 쪼개진 상태의 일정도 같이 공유하는 것이 좋습니다.
최소한 담당자 자신은 좀 더 해야 할 목표를 그릴 수 있는 세부 일정을 가지고 있어야 합니다.
예를 들면
매칭 시스템 1
- 문서 스펙 확인 및 피드백 : 2h
- 일정 산출 : 2h
- Maching Group, Mached Team, Team Maker 주요 클래스 정의 : 2.5h
- elo 기반 매칭 리스트 분할(리스트 개수 동적으로) : 2h
- 매칭 리스트 분할 스크립트 스펙 정의(회의 필요) : 3h
- 시간 별 매칭 매칭 완화 룰 변경 기능(몇 가지 추가 확답 필요) : 3h
...
...
이런 식으로 세부 태스크로 쪼개는 것이 좋습니다.
이 경우 오늘의 목표는 주요 클래스 정의까지 처리라가 되겠네요. 데일리 목표가 생겼습니다.
심리적 장점
태스크가 작을수록 목표도 작고 하루하루 미션을 클리어 해나 가는 업무 프로세스를 띄게 됩니다.
즉, 목표 달성의 느낌을 가진 채 퇴근이 가능합니다.
작은 태스크는 임무 완수를 하고 퇴근하는 심리적 장점이 있습니다.
미션 클리어 퇴근, 미션 클리어 퇴근, 이 반복 루틴 성공에서 오는 심리적 장점은 회사 생활과 생산성에 긍정적인 영향을 준다고 생각합니다.
근거 있는 일정
위의 쪼개진 일정을 보면 시간 단위의 일정이 나오며 최종 일종이 더 근거 있는 일정이 됩니다.
개발실 또는 팀의 하루 일정상의 워킹 시간을 체크해 보세요. 9 to 6 회사의 경우 점심시간 1시간을 빼고 8시간이 실제 근무시간입니다만 일정상의 워킹 시간은 6.5 ~ 7h을 기준으로 하는 것을 추천합니다.
대신 이 시간만큼은 집중해서 일해 주는 것는 걸을 전제로 하죠.
중요한 것은 태스크의 일정 크기입니다. 1d 이상은 곤란합니다. 30m에서 1d 범위 안에서 적절하게 정하는 것이 권장합니다. 그렇게 최종 산출된 시간을 더해서 5.6d, 8.5 day 등 구체적인 일정을 나올 수 있게 합시다.
태스크의 모호한 부분은 팀 매니저와 상담하세요. 대부분의 매니저는 당신에게 도움 주는 것을 좋아합니다.
이유 있는 야근
작은 태스크는 억지 야근이 아닌 '이유 있는 야근'을 하는 이유를 만들어 줍니다. 이 태스크를 100% 만들고 퇴근해야지 라는 비교적 확실하고 자신도 납득되는 야근 사유를 만들 수 있습니다.
많은 개발자가 자신도 납득되지 않는, 또는 헐리웃 야근을 하고 있습니다.
(야근을 긍정적으로 본다는 것이 아닙니다. 야근은 개발자의 평균 생산량에 마이너스라고 생각합니다. 부득이한 경우에도 그나마 납득되는 이유를 가질 수 있다는 것이 포인트입니다.)
일정 관리 능력 향상
기본적으로 태스크가 주어지고 작게 쪼개진 세부 일정이 없다면 그 일정은 러프한 것입니다.
서브 태스크들의 완료 시점이 메인 태스크의 종료 시점과 맞아떨어진다면 개발자 스스로의 일정 산출은 성공적이라고 볼 수 있습니다.
이 반복되는 과정에서 일정 관리 능력이 향상됩니다.
일정 산출에 스트레스받는 개발자가 많습니다. 그럼에도 불구하고 우리는 일정 산출을 해야 하죠.
황당하게도 일정 산출의 팁 중 하나로 '예상 일정의 2배 부르기'를 당당히 말하는 분도 보았습니다. 개인적으로는 별로 같습니다.
아마도 이 태스크 쪼개기가 작은 도움이 될 것입니다.
완벽한 일정 산출 자체를 목표로 할 필요는 없습니다.
이를 통해 실질적 효율화를 끌어내는 것이 목표입니다.
사전 설계 강제
쪼갠다는 것 자체가 디자인에 대한 어느 정도 단편도를 필요로 합니다.
한달급 이상의 큰 일정은 세부적인 쪼개기 단계에서(일정 수립 단계) 앞으로의 몇 주를 예측해야하는 딥 다이빙을 경험 하게 될 것입니다. 이것은 삽질을 줄이는 좋은 다이빙이죠.
덮어 놓고 작업을 시작하는 경우를 미연에 방지하는 장점이 있습니다.
매니징의 관점에서...
팀 속도 산출
팀 매니저들의 경우 팀원들의 일정 관리 능력 향상을 통해 올바른 팀 속도(velocity)를 산출하는데 도움이 될 것입니다. 이것은 팀 관리 차원에서 장점입니다.
게임 개발에서 시즌 급 패치, 메인 컨텐츠 추가 등의 경우는 팀 속도를 기반으로 어느정도 일정을 산출할 수 있습니다.
진행 상황에 대한 구체적인 질문 가능
<태스크 설명이 러프한 경우>
팀 매니저 : XX님 진행 상황 어떠세요?
팀원 : 아, 예. 지금 이 부분 진행 중인데, 여기서 뭐 하고 있고 어쩌고저쩌고
팀 매니저 : 아, 그거 왜 하는 거예요? or 엥? 그거 지금 하면 늦지 않나요?
팀원 : 아, 그게... 어쩌고저쩌고 저쩌고 어쩌고 (시간도 많이 뺏기고 컨텍스트 설명부터 해야 해서 답답함)
=> 요거 여러 번이면 짜증 납니다. 팀 매니저가 매니저가 아니라 브레이커가 될 수 있습니다.
<태스크가 쪼개진 것에 대한 흐름과 컨텍스트를 체크하고 온 매니저>
팀 매니저 : XX님, 진행 상황 어떠세요? 지금 작업 중이신 부분 이런 것들이 애매할 것 같은데
팀원 : 아 예, 딱히 일정 변동 없이 진행 중인데, 지금 이 로직이 좀 애매한 거 같은데
팀 매니저 : 안 그래도 그쪽 관련해서 예전에 블로그 링크해 둔 거 있는데 보내드릴게요.
팀원 : 아, 감사합니다.
=> 자칫, 스트레스 줄 수 있는 중간 점검을 생산적으로
좀 더 효과적이고 깊은 수준의 토의 진행이 가능합니다.
쪼개진 항목 별로 더 시간을 추가하는게 어떨지, 이런 테스트를 하는거가 필요하겠네요 등등 좀 더 일정에 대한 밀도 있는 대화를 할 수 있습니다.
일정의 탄력성 강조
일정의 탄력성을 강조하는 것이 좋습니다.
고정되어 있는 것이 아닌, 이유 있는 변동이 태스크 일정 내내 지속됩니다.
이유가 설명이 되어야 함이 중요합니다.
그 이유가 정말 간단하게, '완전 얕잡아 봤어요'가 될 수도 '생각보다 금방 끝났네요'가 될 수도 있습니다.
이 과정이 팀원의 잘잘못을 판가름하는 심판대로 삼으실 필요는 없습니다.
더불어 팀원이 일정의 탄력성을 악용해서도 안 되겠죠.
태스크 쪼개기, R&D 태스크에서의 애매함
R&D 작업의 경우는 태스크 쪼개기가 애매합니다.
태스크 성격 상 잘 알지 못하는 미지의 영역을 탐험하는 것이기 때문이죠.
이런 작업은 time-limited 성격의 태스크로(시간을 딱 정하고 그때까지 파 보는 작업) 아래처럼 진행합니다.
1차 개략적으로 훑어보기 : 1d (마무리 시점에 2차 진행할지 말지 매니저와 결정)
2차 좀 더 깊숙이 파기 : 3d (마무리 시점에 3차 진행할지 말지 매니저와 결정)
3차 테스트 코드 작성 및 공유 : 5d
이런 식으로 1차 작업 후의 2차를 미리 정하지 않고 점진적으로 스텝을 밟아 진행하는 것을 추천합니다.
요약
자신의 태스크를 쪼개서 관리하세요.
달성해야 하는 작은 목표들을 집중해서 클리어해 나가세요.
일일 퀘스트를 달성하고 퇴근하는 루틴을 유지하세요.
컴퓨팅 업계에서 이 오래된 격언은 여전히 유효한 것 같습니다.
divide and conquer.
