간결한 태스크 관리 고민

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

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

사상

적은 시간내에 많은 일은 결과물과 만족감 모두 떨어진다.

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

용어

프로젝트

• 여러 태스크로 이루어져 있는 것
• 대략 한달에서 여섯달 사이의 시간을 요구
• 한방에 해결이 불가능

세부 목표

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

태스크

• 하나의 작업 단위. 대략 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로 직접 얘기하는 것은 더욱 훌륭함.

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

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

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

SNS 나 인터넷에서 결성되어, 인터넷을 통해서만 서로 알고 있는 개발팀은 98%는 망한다: 익명을 통한 의사소통은 한계가 있으니, 절대 현실에서 당장 만날 수 있는 사람과 작업해야 한다.

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

• 인스턴트 메신저는 "확인 하는 즉시 답장을 줄 수 있는 것" 이지 "확인 자체를 즉시 해야 하는" 프로그램이 아님.
• 메세지를 늦게 확인 했을때
  • 용건을 바로 첫 메세지에 보내지 않으면, 받는 측에서 메세지를 확인 한 다음 다시 구태여 용건이 무엇인지 캐물어야 함.
  • 이렇게 서로 불필요한 사족을 주고 받는 동안 본론이 나오기 까지 매우 많은 지연시간이 걸림
• 질문을 보낼때는 첫 메세지에 바로 질문 내용 부터.
  • 문과라면 모를까, 프로그래머는 단문으로 질문 부터 보낸다고 화 안냄.
  • 답해주는 입장에서는 지금 당장하고 있는 일에 집중하고, 여유시간이 날때 바로 답해줄 수 있기 때문에 무척 편함
• 용건 부터 안보내면, 지금 하고 있는 일을 손에서 놓고, 용건을 되묻는 메세지를 다시 보내야 하기 때문에, 메세지 받는 측에서는 무척 짜증이 남

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

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

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

메일과 메세지는 답해줄 수 없다면 최소한 읽는 행위라도 해야 한다.

즉 이것들 모두 내가 처리해야 하는 하나의 일이 라는 것이고 메일함이나 메세지함, 알림 센터에 읽지 않은 메세지와 알람들이 쌓여있다는 것은 처리해야할 일이 쌓여 있다는 것이다.

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

 

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

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

그러니 메세지의 양을 줄이는 것 만큼, 의사소통 채널을 통제 가능한 수준으로 유지하고, "쓰레기 같은" 유저 경험을 제공하는 서비스는 구태여 붙잡지 않고 버리는게 좋다.

 

 

... 계속 작성중.