간결한 태스크 관리 고민

간결한 구조를 가지고, 어떠한 프로젝트에도 대응할 수 있는 사상을 매번 고민한다.

계속 체계를 갖추고 포스트 내용을 업데이트 할 예정.

사상

짧은 시간에 너무 많은 일을 벌이면 결과물과 만족감이 모두 떨어진다.

중요한것은 어떤일 이든 제대로 하는 것. 그리고 해야할 일만 하고, 그외에 부가적인 일은 버리는 것.

용어

프로젝트

여러 태스크로 이루어져 있는 것
대략 한달에서 여섯달 사이의 시간을 요구
한 번의 작업으로 해결하기 어려움

세부 목표

프로젝트를 간결한 모듈로 나눈 것.
여러 태스크로 이루어 져 있음
태스크 보다는 단위가 크고 추상적이며, 프로젝트 보다는 단위가 작고 구체적

태스크

하나의 작업 단위. 대략 15분에서 한 시간 정도가 필요
시간 단위를 너무 넓게 잡으면, 태스크를 수행 완료하는데 까지 너무 지침
완료 기준이 모호해도 달성도를 평가하기 힘들어서 지침.

작은 태스크

태스크를 더 잘게 쪼갠것.
너무 오래걸리는 태스크는 사람이 지치기 때문.

프로젝트와 태스크 모두 완료 여부를 구체적으로 확인할 수 있어야 한다. 모호한 프로젝트는 작은 태스크로 나눈다.

큰 목표를 작은 단위로 나누지 않으면 버겁고 모호한 목표를 좇는 과정에서 쉽게 지칠수가 있다. - 리오 바바우타 (저서: 단순함이 너의 모든것을 바꾼다)

싱글태스킹

가장 중요한 원칙은 한 번에 하나만 하는 것이다. 이것저것 시작하다 아무것도 마치지 못하지 않도록, 지금 할 일을 분명히 선택한다.

트랠로 사용하기

일반적인 사항에는 애플 리마인더를 사용하지만, 개발과 직접적으로 관련있거나 협업해야 하는 경우 트랠로를 사용한다.

나는 보통 애자일에서 가장 흔히 사용되는 포스트 잇 보드를 그대로 그냥 옮겨서 무조건 한 프로젝트 보드에 3~4가지 섹션을 만든다.

츤데레 아가씨 개발할때 썼던 보드.

처음에는 프로젝트를 태스크로 잘게 나누는 데 익숙하지 않았다. 개발을 마칠 때쯤에는 성취감을 느낄 수 있는 작은 단위로 나누는 법을 익혔고, 모든 태스크를 마쳐 프로젝트를 완수했다.

아래는 동아리 친구와 같이 개발을 할때 썼던 보드. 이번에도 의사소통에 도움을 많이 줬다. 두명이 동시에 진행했기 때문에 진행중 섹션에 태스크가 동시에 두개 있다.

보통 섹션을 나는 이렇게 나눈다.

To Do 할것
In Progress 하는 중
Done 다 한거
Delayed 잠시 보류 (경우에 따라 이 섹션은 없기도 함)

간단하지만, 제약이 있기 때문에 쓸데없는 사족이 들어갈 여지가 없이 지금 눈앞의 작업에 집중할 수 있어 굉장히 훌륭한 방법.

To Do 에서 가장 우선순위가 높은 태스크만 하나 가져와서 In Progress 로 옮겨놓고 다 하면, Done 으로.

만약 다른 후속 태스크를 방해할 정도로 병목현상이 생기면, In Progress 에 있는 작업을 임시로 Delayed 로 옮겨 놓고 To Do 에서 다른 작업을 하나 골라 진행하고, 완료후 다시 Delayed 에 있는 작업을 In Progress 로 가져와서 점검.

중요한 건 두가지.

무조건 한번에 단 하나만 동시에 진행할 것
- 즉 한 사람 당 In Progress 에 들고와서 진행 가능한 태스크는 단 한개 뿐
  - 개발자가 두명이 있으면 In Progress 는 최대 두개의 태스크만 존재 가능하다.
병목 현상이 생기면 Delayed 에 가져다 둘 수 있지만, 절대 나중에 해야할 리스트를 쌓아 놓지 말것.
- 현실적으로 한번에 단 한가지를 지키기가 어려운 경우가 가끔 있다.
- 현재 진행중인 태스크가, 추가 정보나 지시 등이 없으면 다음 단계로 넘어갈 수 없어 잠시 정지해야 하는 경우가 현실적으로 생긴다.
- 병목 현상을 없애기 위해, 메모해놓고, 잠시 일시 정지하고 있는 동안 다른 일을 하기 위한 것.
- 절대 Delayed 에 일을 이것 저것 건드렸다가 쌓아두어선 안된다.
- 즉 Delayed 에 머무룰 수 있는 태스크 또한 한번에 단 하나 뿐

의사 소통

메신저 보다 전화를 애용할 것:

의사소통이 직관적
모바일 키보드 타이핑 하는 것보다 전화가 더 빠름
상대방의 수용치를 메신저에서는 알 수 없지만, 전화로는 목소리를 통해 직관적으로 느껴짐
- 필요한 말을 할 수 있을 확률이 더 높음
1:1로 직접 얘기하는 것은 더욱 훌륭함.

현실의 회의와 우연한 만남에서 오는 아이디어는 절대 메신저나 원격회의로 대체 불가

화상 원격 회의 프로그램이나, 메신저 세팅은 '집중적으로 짧은 시간 동안 온 정신을 다해 집중해서 대화'가 불가능.

어떠한 프로젝트든 절대 원격 작업에만 의존하지 말것. 가장 좋은 방법은 현실의 한 공간에서 다 같이 모여서 작업 하는 것.

나는 온라인으로만 서로 알고 있는 개발팀의 협업에는 한계가 있다고 본다. 그래서 직접 만날 수 있는 사람과 작업하는 것을 중요하게 생각한다.

메신저를 사용할때는 무조건 "선 용건, 후 대화".

인스턴트 메신저는 "확인 하는 즉시 답장을 줄 수 있는 것" 이지 "확인 자체를 즉시 해야 하는" 프로그램이 아님.
메세지를 늦게 확인 했을때
- 용건을 바로 첫 메세지에 보내지 않으면, 받는 측에서 메세지를 확인 한 다음 다시 구태여 용건이 무엇인지 캐물어야 함.
- 이렇게 서로 불필요한 사족을 주고 받는 동안 본론이 나오기 까지 매우 많은 지연시간이 걸림
질문을 보낼때는 첫 메세지에 바로 질문 내용 부터.
- 질문을 먼저 짧고 분명하게 보내면 상대가 필요한 답을 파악하기 쉽다.
- 답해주는 입장에서는 지금 당장하고 있는 일에 집중하고, 여유시간이 날때 바로 답해줄 수 있기 때문에 무척 편함
용건 부터 안보내면, 지금 하고 있는 일을 손에서 놓고, 용건을 되묻는 메세지를 다시 보내야 하기 때문에, 메세지를 받는 쪽의 집중이 끊김

제어 할 수 없는 의사소통 채널

페이스북, 트위터, 인스타그램, 유튜브, 각종 커뮤니티, 라인, 카카오톡, 이메일, 문자, 텔레그램 등등 기술이 발전하면서 한 사람이 사용가능한 의사 소통 채널은 정말 많다.

그런데 생각해보면 하나의 메세지 = 하나의 새로운 일감 을 뜻한다. 특히 메일의 경우 대부분 일 요청이기 때문에 하나의 메일 = 하나의 일 요청 이라 봐도 무방하다.

메일과 메세지는 답하지 못하더라도 읽는 시간이 필요하다. 읽지 않은 알림이 쌓인다는 것은 처리할 일이 쌓인다는 뜻이다.

이들의 양을 줄이는 것도 중요하지만, 이들 요청의 양을 제어하기 위해서는, 의사소통 채널 그 자체를 통제 가능한 수준으로 줄여야 한다.

단순히 생각해봐도 단일 서비스에서 오는 1000개의 메세지 vs 10개의 서비스에서 오는 100개씩의 메시지.

누가 더 정리하기 쉬울까? 단일 서비스에서 오는 1000개의 메세지는, 해당 프로그램 내부에서 일괄 처리가 가능하다.

그러니 메세지의 양을 줄이는 것 만큼, 의사소통 채널을 통제 가능한 수준으로 유지하고, 사용하기 불편한 서비스는 계속 붙잡지 않는 편이 좋다.

... 계속 작성중.