2010년 11월 22일 월요일

[책] 체크리스트

비슷한 분야에서의 여러 종류 서적들을 읽다보면 대체로 다 거기서 거기까지인 내용을 담고 있다. 그럼에도 불구하고 혹시나 싶어 시간과 돈을 들여 책을 읽는 이유는 그나마 나름 가치있는 내용들이 가끔씩 나오기 때문이다. 아툴 가완디의 ‘The Checklist Manifesto, 체크리스트’는 그런 의미에서 근래에 보기 드문 책이 아닐까 싶다.

다만 기대한 바와 내용이 크게 다르진 않지만 결코 내용이 쉽지는 않다. 의사인 저자가 주로 의료 현장에서의 이야기를 다루다보니 일반인이 정독을 하려고 하면 이내 포기하기가 십상일 수도 있이다. 때문에 오직 저자가 주장하는 의도를 염두에 두고 생각하고 읽어 나가야 짧은 시간에 마무리할 수 있다. 이런 책을 하루나 이틀 만에 읽는 것이 효용성이 있는지 의문이지만, 잘못했다간 내용이 어려워 진도 나가기가 쉽지 않기 때문이다.

lpmJ07o.jpg

항상 그러하지만 이 책에서도 나무도 당연한 핵심을 적고 있다. 그러나 우리가 언제나 잊고 있는 내용이다. 업무나 기타 일상의 일을 정확하게 그리고 안전하게 진행하기 위해서는 사전에 확인해야 할 사안에 대한 점검표, 즉 체크리스트를 작성하고 매번 점검해야 한다는 주장이다. 이 사실을 모르는 이는 없을 것이다. 하지만 저자는 체크리스트가 필요로 했던 의도에서부터 작성 그리고 적용까지 나름 상세하게 그리고 친절하게 설명하고 있다(여러 분야의 예를 들고 있지만 단연 의료분야의 예가 많다). 비록 상황이 의학 관련한 내용이라 그냥 넘어가더라도 그 의도는 충분히 파악할 수 있다.

체크리스트 활용에서 가장 중요한 것은 어떠한 상황이 발생했을 때 충분히 인식할 수 있는 가치와 즉각적 효용성을 가질 수 있도록 만들어져야 한다는 것이다. 하지만 책의 후반부에서도 언급하지만 그런 체크리스트를 작성하고 나아가 매번 활용한다는 것은-작성의 단순함에 비해-결코 쉽지가 않다. 우리 모두가 알고 있는 사실이다. 그런 수준의 체크리스트를 만들기 위해서는 나름의 경험과 노력 그리고 시간이 요구될 수 있다. 실제 저자가 이를 위해 많은 노력을 했다는 것은 책을 읽으면서 어렵지 않게 느낄 수 있었다.

어쩌면 이 책을 덮고 나서 우리는 언제나 그렇던 늘 하던 실수를 반복하고, 또 그 실수에 대한 대책을 수립하지만 언제나처럼 실수는 다시 반복된다. 다행히 대부분 일상의 작은 일로 마무리 되기도 하지만 언젠가 감당 못할 큰 일이 될 수도 있다. 이 책을 읽고 느낀 바가 있다면 그것이 무엇이든 당장 실행해야 할 것이다.

PS. 책을 읽으면서 느끼는 또 다른 수확이라면 절대 아프거나 해서 병원이 가면 안될 것 같기 때문에 열심히 건강을 지키기 위한 노력을 해야 한다는 것이다.

2010년 8월 16일 월요일

Note Taker

OmniFocus나 iPhone과 같은 도구가 있지만 항상 지니고다닐 수는 있더라도 항상 사용하기는 쉽지가 않다. 아직까지는 회의 도중에 iPhone을 꺼내 입력하는 모습이 일상적이지는 않은 것이 사실이고, 아무래도 손을 직접 쓰는 그 자체가 여러모로 효용적이기도 하다. 하지만 A4 사이즈와 같은 큰 노트는 회의나 업무에는 필요하지만 이동 중에는 마땅치 않다. 때문에 손에 쥘 수 있는 작은 노트를 사용해야 하는데, 주머니에 넣을 수 있는 크기는 물론 쉽게 기록하고 뜯어 낼 수 있어야 기능적이라고 본다. 그런데 이러한 까다로운 요구 사항을 만족시키는 노트를 찾는게 생각처럼 쉽지는 않았다-아마 개인적인 취향의 차이에 따라 그렇지 않다 싶다. 여건이 된다면 David Allen의 Notetaker Wallet과 같은 제품을 사용하는 것도 좋겠지만 해외에서 구입 비용이나 가격대 성능비로 본다면 선택이 쉽지 않은 것도 사실이다. 문구점이나 전문점에 갈 때마다 한참을 뒤지기도 했지만 마음에 드는 것을 발견하지 못했다. 그러던 중, 몇 번 들렀던 HotTracks에 갔다가 꽤나 마음에 드는 Note Taker를 발견했다.

xJTV57H.jpg 3rIhxd5.jpg

가장 마음에 드는 점은 노트를 한 장씩 뜯어내는 것이 깔금하다는 점이다. 대개 노트를 뜯어낼 때 자국이 남아 눈에 거슬리는 경우가 많다. 또한 링으로 만들어진 노트의 경우 뜯어낸 자국이 상당히 보기 싫게 된다. 그리고 표지를 완전히 뒤로 젖혀 메모장처럼 두고 사용할 수 있다는 점도 마음에 든다. 가격은 1,000원.

2010년 6월 25일 금요일

OmniFocus - Ticklers

GTD 시스템이 다른 자기계발 시스템과 다른 기능적인 사항은 일의 실행 순서를 정함에 있어 가치보다는 실행 가능성을 우선한다는 점이다. 그리고 일의 실질적 실행 일자가 정해지거나 사용자가 설정한 일자를 GTD 시스템이 관리할 수 있게 됨에 따라 우리는 현재 할 수 없거나 할 필요가 없는 일에 대한 생각을 머릿 속에서 지워 버릴 수 있게 된다. GTD 시스템은 Tickler는 이상과 같은 수행하기 위한 단순하면서도 효율적인 방법의 하나로 사용된다.

Tickler는 일의 마감일 혹은 마감 전 준비를 시작해야 하는 날을 지정하고 해당 날짜가 되기 전까지는 시스템에 나타나지 않다가, 지정한 날짜 조건이 부합되는 날에 시스템에 등장하여 사용자가 화인할 수 있도록 해 준다. 일반적인 방법으로 사용하는 달력과 비교한다면, 많은 일이나 정보가 기록되면 점점 달력을 보면서 일의 상세 내용을 확인하기가 쉽지 않게 되고, 달력에 적히는 항목들에 대한 기준을 따로 마련해야 하는 일도 생기기 된다.

OmniFocus와 같은 컴퓨터 기반 GTD 프로그램이 아닌 실제 물리적인 환경에서는 Tickler 폴더로 구성될 수 있다. Tickler 폴더에는 일, 월 별로 구분된 43 개의 파일 폴더를 구비한다. 1 ~ 13일 그리고 1 ~ 12 개 월로 구분된 각 Tickler 폴더에는 해당 일자 혹은 월에 해야 할 일에 대한 사항과 관련 서류들이 저장된다. 사용자는 매일 당일에 해당되는 Tickler 폴더의 내용을 확인함에 따라 잊지 않고 계획한 일을 실행할 수 있도록 해 준다. GTD 시스템을 구성할 때 사용자들이 가장 필요하다고 생각되는 도구가 Tickler 폴더인데, 사실 개인적으로는 몇 년간의 사용 경험에 비춰 여간 부지런하지 않고서는 기대한 성과를 얻기가 쉽지 않기 때문에 처해진 상황에 따라 무작성 사용한다면 그 유용성의 효과를 완전하게 기대하기 힘들다. 이러한 문제를 개선하기 위해서는 Tickler 폴더 자체를 가능한한 눈에 잘 뛰면서 쉽게 손이 갈 수 있는 장소와 위치에 배치하는 것이 가장 중요하다.

Sjpmiwi.jpg

co0Xrxi.jpg

OmniFocus와 Things를 비교할 때 OmniFocus가 상대적으로 복잡하고 어렵다고 하지만, 반면 OmniFocus의 여러 기능을 제대로 사용하는 경우도 많지 않다고 생각된다. 그리고 그 중의 하나가 Tickler 기능이기도 하다. OmniFocus에서의 Tickler를 사용하기 위해서는 그 대상이 되는 ‘미래(오늘 포함)의 일이 시작되는 날짜가 지정하는 것으로 시작한다. 즉, OmniFocus의 Action 혹은 Project에 대하여 Start date와 Flag를 지정한다. 그러면 일반적인 경우에는 나타나지 않다가 지정된 일자에 할 일이 화면에 나타나게 된다. OmniFocus를 사용하면서도 하루에도 몇 번이고 Due 화면이나 Project 화면을 보면서 앞으로의 일정을 확인하고 있다면 아직 제대로 Tickler 기능을 활용하지 못하고 있는 것이다.

아직 대형 문구점에서도 David Allen의 GTD System Folders와 딱 맞는 폴더 제품을 찾지 못했다. 때문에 일반적으로 사용하는 황색 폴더를 이용하여 직접(고생해서) 만들어 사용했다. 이후에는 Sysmax의 Handy Box 폴더를 사용하기도 했다.

PS. OS X 10.8 Mountain Lion의 캘린더와 OmniFocus의 Sync 기능이 해제됨에 따라 Tickler 기능을 더 이상 두 시스템 간에 연동해서 사용할 수는 없다.

GTD의 컨텍스트에 대한 착각

참고는 참고일 뿐, 컨텍스트는 자신의 것이다.

돌이켜 볼 때 GTD 시스템를 나름(!) 복잡한 삶에 적용하고자 나 역시 별의별 짓을 다했다고 생각한다. GTD 시스템의 현실적 운용에서는 항상 많은 것들이 의문스러웠다. 예로 컨텍스트라는 필요 조건이 만족되었고 일의 실행에 남은 것은 오직 나의 실천 의지 만이 있을 뿐이었다. 하지만 컨텍스트 조건의 충족 여부와 상관없이 일은 제대로도 원활하게도 실행되지 않았고 여전히 GTD 시스템이 아닌 머릿 속에 남아 있는 경우를 겪게 되었다. 이에 대하여 근본적인 원인과 해결 방안을 찾게되면서 나의 GTD 시스템에서의 컨텍스트가 너무나 형식적이지 않은 가에 대한 의문이 들었다. 이전 컨텍스트의 선택이라는 포스팅에서와 같이 나의 컨텍스트로 일반적인 구성에게 크게 벗어나 있지는 않다. 덕분에 생각해보면 일의 컨텍스트 지정을 이미 규정한 몇 가지 컨텍스트 구조에 맞추려고 애를 쓰는 것 같았다. 사실 그렇게 하는 것이 더 효율적이라고 생각했다.

그렇다면 현재의 컨텍스트 구조가 현실적이지 못하다 것인가? 물론 이러한 문제의 답이 멀티 컨텍스트는 분명 아니다. 멀티 컨텍스트를 사용하지 않는다면 가장 중요한 핵심 사안을 컨텍스트로 지정하게 된다. 이것은 핵심 컨텍스트가 되지 못한 많은 다른 부수적인 조건들의 충족을 전제로 한다. 하지만 GTD 시스템에서 컨텍스트가 지정된 일에 대하여 그 지정된 항목에만 집중하게 되는 경우가 많았다. 덕분에 컨텍스트의 충족에도 불구하고 일의 진척을 더디거나 시작도 못하는 경우도 발생했다.

이에 대한 나의 해결책은 크게 몇 가지로 구분하였다. 우선 가장 일반적인 방법으로써 하나의 일을 가능한한 최소 단위로 구분하여 컨텍스트를 지정하는 것이었다. 물론 이러한 방법은 일을 세부화하는 과정에서 너무 비효율적인 구분까지 진행되기고 했다. 분명 단순하고 쉬우면서도 어렵고 복잡한 일이기도 하다. 또 다른 방법은 프로젝트로 운용하는 것이다. 내부적인 방법이야 동일하다고 보겠지만 하나의 프로젝트로 만들고 컨텍스트 조건으로 세부적인 일을 구분하는 것이었다. 시각을 달리하여 컨텍스트를 구체적으로 세분화하는 방법도 있다. GTD 시스템의 운용을 시작하게 될 때, 컨텍스트의 구성과 구조를 너무 정형화하는 실수를 저지르기도 한다. 즉, 이미 GTD 시스템을 사용하면서 이에 대한 소개를 한 웹 사이트나 블로그 등의 컨텍스트 구조를 참고가 아닌 그대로 자신의 시스템에 적용하려고 하는 경우가 있다. 여기에서 컨텍스트에 대한 우리의 착각이 시작된다. 컨텍스트란 자신의 업무 범위에 따라 스스로 설정하는 것이 핵심 임에도 레퍼런스에 집중하므로 써 컨텍스트에 자신의 시스템이나 업무 스타일을 맞추려고 하는 일을 벌이게 된다. 더 나아가 컨텍스트를 장식하려는 경우도 있다. 일의 수행에 솔직한 전제조건이 아니라 우아한(?) 구성에 억지로 맞추려고 하는 것이다. 마치 부모가 읽을 것을 아는 어린 아이의 일기처럼.

결국 GTD 시스템을 접하게 되면 컨텍스트라는 조건이 마치 일을 완료시켜주는 사안인 것처럼 착각하는 경우가 많다는 것이다. 마치 컨텍스트가 GTD 시스템 내에서 만들어져 있는 것처럼 생각하는 경우로 볼 수 있다. 자신을 삶을 투영하는 컨텍스트를 만드는 것은 자신이 가장 잘 할 수 있는 일임에도 대부분의 사용자들은 무언가 확실하고 명쾌하면서 만족할만한 컨텍스트의 예를 찾기위해 애쓰는 모습이 보인다.

PS. 하나의 일을 여러 개의 일로 나눈 것과 프로젝트로 만드는 것의 차이는 의외로 간단한 것이 프로젝트는 그 자체로서 마감일을 가진다. 만일 하나의 일을 굳이 여러 개로 조각을 냈다고 해서 이를 프로젝트로 만들 필요는 없다.

2010년 4월 20일 화요일

MindNode Pro

브레인 스토밍을 위한 마인드 맵핑 어플리케이션으로 뭘 살까 고민하다가 오늘 질렀다. MindNode Pro의 매력은 여러 마인드 맵 가운데 가장 이쁘거나 혹은 귀엽다는 점이다. 마인드 맵이 다소 업무적인 측면에서 운용 이미지가 크다보니 마인드 맵 자체가 직선화되고 구조화된 플로우 챠트를 보는 듯한 경우가 있다. 그리고 비용 역시 만만치 않은 것도 사실이다. 그런 점에 비춰 MindNode Pro는 마인드 맵을 가볍게 시작하는 용도로 적합하며, 또한 메모장처럼 부담없이 운용할 수 있는 용도로 적당하다.

사실 마인드 맵 프로그램 사용에 있어 가장 어려운 점이 맵핑 그 구성 자체에 완벽성이 요구되는 듯한 복잡하고 어려운 기능을 제대로 활용하기 쉽지 않다는 부담감이다. MindNode Pro는 그런 부담이 상대적으로 적도록 만드는 가볍고 쉬운 인터페이스를 제공한다. 아니 제공하는 인터페이스가 가장 기본적인 차원이다.

ragIzgH.jpg

하지만 다른 상용 제품에 비해 맵핑 외 주변 기능이 많이 부족하다니 다양한 기능을 기대하는 분들에게는 적극 비추하고 싶다. 물론 MindNode Pro 자체가 오랫동안 경쟁에서 생존한다면 그 사실 자체가 부족한 기능을 충분히 보완하고 있다는 사실을 의미하지는 않을까 싶다.

2010년 4월 2일 금요일

마인드 맵핑

마인드 맵핑은 놀랍게도 1970년대 등장한 20세기의 기술이다. 종종 마인드 맵핑의 일상적 표현 덕분에 고대 사회부터 이어져온 전통적 방안이라고 오해하는 경우도 있다. 그만큼 마인드 맵핑의 기능적 방법은 특별한 것이 아니라고도 할 수 있다. 다만 이러한 기능적 표현을 생각의 정리나 업무 진행의 도구로 적용했다는 점에서 차이 혹은 개발자의 역량을 미뤄 짐작할 수 있다.

일반적으로 마인드 맵핑의 창시자로 토니 부잔이라 하지만, 그의 개발 이전에도 유사한 관리 기법들은 많이 존재했다고 볼 수 있었다. 하지만 토니 부잔은 현대 사회의 일상에서 수 많은 일 그리고 일의 계획과 진행에 고민하는 이들의 문제를 해결하과 도움을 주는 기술로서 마인드 맵핑을 하나의 새로운 관리 기법으로 변화시켰다는 것에서 그의 공헌이 칭송받을만하다. 하지만 이후 수 많은 사람들이 마인드 맵핑 자체를 가지고 고민하는 것을 보면 역시 천재는 아무나 될 수 없는 것이 분명하다.

마인드 맵핑의 최대 효용성은 그 기술적 방법의 이해가 매우 쉽다는 것이다. 아무리 좋은 업무 관리 기술이나 일 처리 방식을 이전까지 접하지 않은 이에게 온전히 전달하기란 쉽지 않은 일이다. 그에 반해 마인드 맵핑은 처음 접하는 경우에도 쉽게 기능적 구현이 수월하고, 바로 적용이 가능하다는 점에서 다른 어떤 관리 기술보다 효과적이라고 하지 않을 수 없다. 또한 마인드 맵핑을 접하는 많은 이들이 그 기술적 효용성에 감탄을 하지 않을 수 없다는 것도 특별한 점이다.

그러나 마인드 맵핑은 누구라도 접근이 쉬운 반면, 운용 목적에 비춰 제대로 된 혹은 기대한만큼의 효과적 운영이 만만치 않는 것도 사실이다. 마인드 맵핑의 운용 목적이 현재 머리 속을 가득 채운 복잡한 생각의 정리 그리고 불명확한 계획의 객관적 진행을 사전 점검하고 관리하기 위함이라고 볼 때, 단순한 기능적 접근에 비해 기대하고 추구하는 목표의 달성을 위해서는 보다 깊은 기술적 접근이 필요하다.

GTD에서도 복잡하고 난잡한 현재 상태는 물론 미래의 계획을 명확하게 설정함에 있어 마인드 맵핑 기법을 추천하고 있다. 마인드 맵핑은 GTD 사용자의 입장에서 보자면 현재 상태의 현황 파악에 매우 탁월한 관리 도구라고 할 수 있으며, 또한 GTD가 제공하지 못하는 장기적 관점에서의 프로젝트 관리나 인생 설계를 위한 기능을 보완할 수 있다는 점에서 함께 운용할 필요가 있는 시스템이다.

마인드 맵핑의 기술적 목적과 기능적 방법론은 이미 여러 서적이나 웹 사이트 그리고 블로그에 소개되었기 때문에 관련된 정보의 입수는 매우 용이하다. 하지만 마인드 맵핑은 운용하는 사안에 따라 그 구현 방식도 천차만별이라는 것도 특징이라고 할 수 있다. 즉 참고할 수 있는 수 많은 마인드 맵핑 사례 가운데 자신에게 적합한 경우를 찾아 활용하기가 쉽지 않을 수 있다. 그러므로 마인드 맵핑의 효과적 운용을 위해서는 다른 참고 사례를 찾기 위해 노력하는 것보다 마인드 맵핑에 대한 정확한 이해와 학습을 통해 자신에게 적합한 구현 방식을 찾아내는 것이 훨씬 효과적인 활용방안이라고 발 수 있다.

마인드 맵의 활용 분야

마인드 맵핑은 활용은 대개 서너가지로 구분할 수 있는데, 가장 일반적이며 기술적인 활용도가 높은 부문이 이른바 브레인 스토밍이다. 브레인 스토밍 기법은 20세기 초, 문제 해결을 위한 아이디어 도출 기법으로 소개되었으며 마인드 맵핑은 기능적인 표현에서 브레인 스토밍을 위한 매우 효과적인 도구로 평가받았다. 일반적으로 현재 해결 해야 할 문제나 프로젝트의 목표를 마인드 맵의 중심에 두고 전개해 나간다.

다른 하나의 정보의 수집 및 평가 그리고 관리 도구로서의 활용이다. 수집되는 수 많은 정보 가운데 중복되거나 반복되는 혹은 유사한 요소간의 관계를 시각적으로 한 눈에 파악하고 이를 정렬하고 관리하는 용도로서 마인드 맵핑만큼 탁월한 기능을 제공하는 기법은 없다고 본다. 일반적으로 대개의 관리 기법이 순차적 나열에 대한 각 요소 간의 비교라는 점에서 모든 정보를 같은 수준에서 동시에 파악할 수 있는 마인드 맵핑이 제공하는 시각적 평가 기술에 대응할 수 없다고 본다.

그 외 기존 수집 자료를 바탕으로 새로운 아이디어를 도출하는 용도로서도 매우 효과적이라 할 수 있다. 특히 기존 정보 간의 유사성 혹은 종속성을 파악하고 필요한 추가 요소를 도출하는 용도로서 사용할 수 있다는 점에서 다양한 분야에 적용될 수 있다.

한마디로 마인드 맵핑은 도구가 필요 없는 도구로서 다른 어떤 생각 정리 혹은 업무 관리 도구에 비해 기능적 접근성이 낮기 때문에 언제 어디서 누구와도 활용이 가능한 업무 처리 기술이라고 할 수 있다.

마인드 맵핑 활용 도구

종이와 연필만 있으면 완벽한 준비가 된다는 점에서 마인드 맵핑의 기능적 구현이 자유롭기는 하지만, 마인드 맵핑 작업이 일시에 마무리될 수 있는 경우는 드물기 때문에 이를 연속적으로 유지하고 관리해야 한다는 점에서 별도의 도구가 필요한 것 역시 충분한 근거가 있는 주장이다. 특히나 컴퓨터 시스템과 인터넷 활용이 일상인 시점에서 애써 종이 위에 쓰고 그려가면서 마인드 맵핑 작업을 한다는 것은 일반적인 운용 방법이라고 할 수 없다. 이미 수 많은 마인드 맵핑을 구현한 소프트웨어가 출시되어 있으며, 직접적이지는 않지만 간접적인 방식으로 마인드 맵핑을 지원하는 경우까지 본다면 선택의 폯은 매우 넓다고 할 수 있다. 그 결과의 선택의 고민에 빠지게 되어, 농담반 진담반 어떤 마인드 맵핑 소프트웨어를 선택할 것인지에 대한 마인드 맵핑을 하기도 한다.

마인드 맵핑 소프트웨어의 수십 개가 출시되어 있지만 기본적인 기능은 동일하다는 측면에서 어떤 제품을 선택해도 마인드 맵핑 도구로서의 활용도는 아무런 문제가 없다고 볼 수 있다. 단지 화면에 구현된 각 요소의 배치나 표현을 시각적으로 효과적으로 구현했다거나 여러 사용자들이 공유할 수 있는 기능을 제공한다거나 혹은 마인드 맵이 아닌 다른 그래프로 표현할 수 있는 기능 나아가 마이크로소프트 오피스나 인터넷 웹 브라우저 등과 함께 사용할 수 있는 기능 등의 차이로 가격과 규모의 차이가 발생한다. 때문에 마인드 맵핑은 무료로 제공되는 작은 프로그램에서 매우 비싼 덩치 큰 프로그램까지 다양하다. 또한 최근 스마트 패드나 스마트 폰에서의 운용을 위한 전용 앱도 적지 않은 실정이다.

개인적으로는 가볍고 빠른 프로그램을 선호하고 비용적인 면에서도 유리하다는 점에서 Mindnode와 Xmind를 주로 사용했지만, 최근에는 Xmind의 무료 기능 수준에서 모든 마인드 맵핑을 활용하고 있다. 유료 버전을 사용한 경우에도 실질적 기능 활용도는 거의 무료 버전이 제공하는 기능이 한정되었었다. 결국 마인드 맵핑 활용 도구로서 마인드 맵핑 프로그램의 선택은 특별한 제한이 없다고도 볼 수 있다. 프로그램이 제공하는 기능적 한계로 마인드 맵핑을 제대로 운용할 수 없는 경우는 없다.

마인드 맵핑에 대한 오해

마인드 맵핑은 현재 생각에 대한 평가와 미래에 대한 사전 점검의 용도로서는 탁월하지만, 현재 진행형의 프로젝트나 업무를 관리하는 용도로서 사용하기는 부적합하다. 그럼에도 마인드 맵을 프로젝트 관리 도구로 활용하는 경우를 적지 않게 보는데, 기능적으로 불가능하다고 할 수는 없지만 시각적으로 매우 복잡하며 현재 진행 상황 파악에도 많은 어려움을 있어 별도의 도구 등을 활용해야 한다. 하지만 마인드 맵이 주는 시각적 우월성으로 인해 프로젝트 관리 도구로 고집하기도 한다.

- - - - -

개인적으로 경험에서 볼 때, 마인드 맵핑은 현재 복잡함 머릿 속을 명확하게 객관적으로 파악하기 위한 도구로서 그 효과가 매우 크다고 본다. 복잡한 머리에 가득한 온갖 생각과 계획을 시각적으로 표현하고, 그 가운데 관리 대상으로 되어야 할 것을 GTD의 수집함으로 이전한다. 하지만 너무 많은 요소들이 도출되게 되면 유사하고 반복적인 요소로 가득하게 되고, 전체 마인드 맵 자체가 혼란스럽게 된다는 점에서 협업이나 회의 도구로서의 전반적 활용에도 주의를 해야 하지 않을까 싶다. 즉 어느 정도의 구성이 갖추어진 마인드 맵을 가지고 회의를 진행하면서 의견을 검토하고 마인드 맵의 요소로 추가하거나 수정하는 등의 과정에서는 효과적이라고 볼 수 있지만, 회의 과정을 통해 처음부터 마인드 맵을 구성하기란 매우 번거롭고 비효율적이라고 느꼈다.

하지만 마인드 맵핑이 아무리 효과적인 아이디어 도출 기능과 현재 업무 파악 기능을 제공하더라도, 의도적으로 활용하기 위해 노력하지 않으면 역시나 지금까지의 수 많은 관리 기법처럼 그 사용도는 급격히 낮아진다는 것도 사실이다. 마인드 맵핑의 구현이 있어 또 다른 문제는 아직 대부분의 사람들이 문제를 하나의 중심 사안을 기준으로 병렬적으로 보고 평가하는 것에 익숙하지 않다는 점이다. 때문에 처음 접하게 된 이후 마인드 맵핑의 구현에 대한 부담 적지 않아 거의 대부분이 포기한다는 것이었다.

처음에 부서장으로서 마인드 맵핑을 직원들에게 반강요하여 보급하기는 했지만, 몇번의 평가를 거치면서 그나마 필요한 경우에라도 마인드 맵핑을 활용하는 직원은 한두명도 되지 않는 것이 현실이었다. 그렇더라도 마인드 맵핑이 절대적 위상을 갖는 도구가 아니라는 점에서 지나친 강요을 할 수는 없었고-제조기업 이라는 업무 분야에 따른 차이일 수도 있겠지만-결과적으로 부서 단위에서의 활용은 실패라고 보았다. 물론 개인적으로는 여전히 마인드 맵핑을 최고의 생각 정리와 업무 점검을 위한 도구로서 활용하고 있다. 부서에서의 가장 인상적인 마인드 맵핑 사례는 아이러니하게도 부하 직원의 다른 회사 이직을 위한 미래 계획에 관한 것이었다.

2009년 7월 14일 화요일

Start vs. Due

GTD 시스템을 구축하면서 아마 이런 의문을 가진 적이 있을 지 모르겠다. 현재 사용중인 OmniFocus를 비롯하여 The HitList, Things 등 여러 뛰어난 기능의 GTD 지향 어플리케이션을 사용하면서 하나 공통적인 기능 혹은 어색한 느낌 그렇지않다면 문제점이라고 생각되는 것이 모든 행동과 프로젝트의 기준은 시작(Start)가 아닌 끝 혹은 마감(Due)라는 것이다. iCal과의 동기화를 할 때에도 Due로만 단독 설정되어야 된다.

행동에 있어 시작과 끝을 비교하는 것이 어떤 의미가 있는지 잘 모르겠지만, 중요한 일은 대개 마감 시간이나 일자가 정해져 있다. 그리고 이런 일은 가능한한 빨리 시작하면 좋다. 심지어 시작이 가능한 일자가 정해져 있어 그 이후에나 가능하다고 할지라도 마감일에 완료되지 않는 다면 아무런 의미가 없게 된다. 덕분에 GTD 시스템에서 행동의 완료는 마감일까지로 정해져 있다. 물론 일에 따라 마감이후에도 진행이 되거나 혹은 마감 자체를 연기할 수도 있지만 이런 일은 지금까지 언급한 나의 의지에 의해 연장될 수 있는 마감일은 아닌 것이다. 그렇다면 여러 행동이나 프로젝트가 있을 때 그 우선 순위를 정함에 있어서도 마감일 기준으로 할 것인지 시작일 기준으로 할 것인지 결정해야 하는 경우도 있을 것이다; 아직 대부분의 GTD 어플리케이션에서는 이에 대한 지원이 매우 부족한 것이 사실이다. 만일 자신의 행동이 시작과 끝 중에서 기준으로 하는 경우가 비슷하다면 현재 GTD 어플리케이션에서는 매우 곤란한 상황이 일어나게 된다. 상대적으로 기준으로 정한 행동과 프로젝트 만이 눈에 띄이에 되고 심리적으로 매우 불안하게 된다. 비싼 돈주고 구입한 GTD 시스템이 반쪽짜리로 전락하게 되는 것이니 말이다.

하지만 이러한 고민에 대한 다시 한번 행동과 프로젝트의 시작과 끝에 대한 자신의 기준을 명확히 할 필요가 있다고 생각된다. 일반적으로 하나 혹은 둘 이상의 연관된 행동(프로젝트)에 있어 시작과 끝이라는 항목에 더 중요한 것은 끝이라는 점이다. 끝은 다음 시작과의 연결점이기 때문이다. 또한 시작은 가능한 때에 대한 선택의 폭이 상대적으로 넓은데 비해 업무나 대외적인 행동에 대한 마감은 선택의 여지가 없다. 때문에 시작과 끝의 비교에서는 끝이 당연히 주요하게 되고 결과적으로 GTD 어플리케이션에서는 모두 끝이나 마감을 기준으로 시스템을 관리하게 된다. 그런데 문제는 하나의 행동이 아닌 프로젝트와 같은 경우에서 발생한다. 하나의 행동은 시작이든 끝이나 그 하나로 종료되니 시스템에서 큰 문제를 야기하지 않는다. 마감이 정해진 프로젝트의 경우에도 내부에는 여러 행동들이 존재하게 되고 그 행동들간의 시작과 끝의 선택에 대한 문제가 발생하는 이는 사람에 따라 다르겠지만 나의 경우에는 종종 매우 머리를 복잡하게 한다. 일이나 행동이라는 것인 하나가 완료되고 다음으로 이어지는 경우도 있지만 여러가지 일이나 행동이 동시에 혹은 거의 비슷한 시기에 시작해야 하는 경우도 많다. 더불어 시작하는 순서가 정해져 있는 경우도 허다하다. 상식적으로 이런 일들은 시작과 끝 모두가 중요하기 때문에 둘 모두를 기준으로 삼는다면 별 문제가 없을 것이다. 그러나 앞서 언급했듯히 지금의 GTD 어플리케이션들은 이 점에서 있어 너무 유연성이 없다.

OmniFocus의 경우 하나의 행동에 대하여 시작과 끝을 모두 입력한다고 할 때, 앞서 언급했듯이 iCal와 동기화가 되지 않는다. iCal의 Mac OS X 및 그 환경에서의 GTD 어플리케이션에서 차지하는 절대적 비중을 고려할 때 이것은 매우 심각한 문제라고 여길 수 있는 사람도 많을 것이다. 당연히 시작만 지정된 경우에도 마찬가지 결과를 보여준다. TheHitList의 경우 나는 @iCal 태그로 지정된 모든 행동을 iCal로 동기화하도록 했다. TheHitList는 이 덕분에 시작과 끝에 대한 지정없이 동기화되지만 마찬가지로 끝이 지정된 경우에만 iCal의 To do 리스트에 날짜가 나타난다. 결국 시작이 중요한 일의 경우에는 역시나 반쪽짜리 기능으로 전락하게 된다.

이상에서 문제는 명확하다고 볼 수 있다. iCal의 To do에서 시작일과 마감일의 지정에 관한 사항이 없으며, 예정일과 완료 표시만이 있다. 그리고 iCal의 예정일은 모든 GTD 어플리케이션에서 마감일로 자동적으로 연결된다. 행동의 시작과 끝에 모두 예정이 있을 수 있음에도 사용자들은 iCal의 예정일을 GTD 어플리케이션의 시작과 끝에 연결되도록 선택할 수 없다. 사실 이것이 너무나도 당연하다도 생각하면 지금까지의 이런 저런 언급은 별 영양가없는 잡담이라고 치부할 수도 있다. 또한 내가 사용하는 환경이 Mac OS X가 아니며 iCal에 대한 비중이 이 정도까지 아니라면 이런 글은 시작도 하지 않았을 것이다. 그렇다면 해결책은?

답은 간단하면서도 단순하게 생각해 볼 수 있다. 모든 행동의 시작은 가능한한 빨리 실행한다라고 정하는 것이다. 그리고 각 행동들 간의 우선 순위 만을 고려하는 것이다. 모든 행동은 어떤 식으로든 결과를 낯게 된다. 만일 결과를 예측할 수 없거나 무한정 시간이 소비되는 경우라면 이는 GTD에서 다루는 행동의 범주에 들어 가지 않는다. 때문에 GTD에서 행동의 원하는 결과를 기대하기 위해서는 반드시 정해진 기한 내에 완료되어야 한다. 이 점에 있어 마감이나 끝은 매우 중요하다. 또한 결과의 진행은 매우 순차적으로 구조적이다. 이에 반해 행동의 시작은 병렬적일 수도 있으며 덜 순차적이며 덜 구조적일 수 있다. 때문에 하나의 프로젝트 내의 행동들은 시작일을 지정하지 않는다. 그리고 하나의 행동이 다른 행동에 영향을 미치는 경우에는 순차적인 행동들의 정렬을 구성한다. OmniFocus에는 프로젝트 내의 행동들의 순차적 및 병렬적 수행을 강제적으로 지정하는 옵션으로 실행 여부를 파악하게 해준다. GTD에 관한 모든 의문의 답이 그렇듯 간단하게 단순하게 생각하고 처리하는 것이 결론적으로 효율적인 답이다. 억지로 iCal의 항목을 시작일로 인식하기 위해 행동의 이름이나 내용을 어렵게 구성하지 않는 편이

2009년 4월 11일 토요일

The Hit List

CultureCode의 Things가 Mac OS X 어플리케이션다운 깔금하고 세련된 인터페이스로 현재(?)까지 높은 인기를 만끽해 왔지만 베타 테스트 기간이나 발매 초기 당시 거의 열광 수준에 비하면 상당히 정체된 느낌을 받는 즈음 최근 PortionFactory의 The Hit List가 정식 버전으로 발표되었다. 특히 MacHeist3의 최종 번들에 포함되므로 써 사용자들의 상당한 관심을 확인할 수 있었다. 기능적인 면의 비교에서 The Hit List는 계층적 관리 구조와 멀티 태그를 지원하므로 써 Things의 부족한 면을 완벽하게 보완해줄 수 있는 제품이라고 할 수 있다.

1. The Hit List의 구조

The Hit List는 Lists(리스트)와 Tags(태그)라는 별개의 주요 화면으로 구성되어 있고, 일상적 업무 관리는 리스트 화면에서 진행된다. 리스트 화면에서는 Inbox, Hit Lists 그리고 Folders로 구분된다.

Hit Lists는 개별 항목을 Today와 Upcoming으로 구분하여 오늘 및 향후 일의 목록으로 보여준다. 그리고 Folders는 List(리스트), Folder(폴더) 그리고 Smart Folder(스마트 폴더)를 가진다. 폴더는 항목 간을 구분하는 역할 만을 한다. 때문에 프로젝트로서 폴더내 리스트를 사용하는 경우에는 완료 상태가 적용되지 않는다.

2. 개선된 태그 기능

The Hit List는 별도의 Context 폴더를 제공하지 않고 Things와 같이 멀티 태그를 이용한다. 하지만 Things의 과도한 멀티 태그 사용으로 인한 문제를 해결하기 위해 일반 태그와 Context 태그로 구분한다. Context 태그는 @로 시작하고 일반 항목은 /로 시작하므로 써 간단히 구분할 수 있으며, 태그에서도 계층적 구조를 지원한다. Context에 관련된 일의 관리는 태그 화면에서 해당 Conetxt 태그를 선택하여 확인할 수 있다.

3. 스마트 폴더

The Hit List에서는 리스트 항목과 태그를 이용하여 사용자가 원하는 내용으로 스마트 폴더를 구성할 수 있다. 스마트 폴더를 사용한 필터 기능으로 유연한 관리 체계를 구성할 수 있다.

4. iCal 싱크

The Hit List는 여러 개의 Mac OS X의 Calendar와 동기화할 수 있다, 태그는 물론 폴더내 리스트와도 동기화도 두 개 이상의 항목을 캘린더에 지정할 수도 있다.

GTD 프로그램의 기능적인 면에서 The Hit List는 경쟁 제품에 대응이 충분하며 유연성도 높은 제품이다. 하지만 베타 버전이 공개된 이후 정식 버전 출시까지 거의 2년이나 걸려서 사용자들의 기대를 허무하게 만들었다.

2009년 3월 26일 목요일

iGTD2 개발 중단

최근 iGTD와 iGTD2의 업데이트가 공식적으로 중지되었다. 개발자가 직간접적으로 관심을 두지 못하는 상황에서 혹시나 하는 기대가 없지는 않았지만 아쉬운 결과가 되었다. 이렇게 멋진 GTD 소트프웨어가 그것도 한창 무륵 상태에서 사라지게 된다니. 그렇더라도 불안정한 하기는 했어도 iGTD2를 통하여 난 GTD 소프트웨어의 기능과 구성 그리고 활용에 대한 많은 경험을 하게 되었다. 절대 이루어 질 수 없겠지만 언젠가 iGTD의 후속 버전이 나올 수 있을까?

PS. 개발자가 Things를 개발한 CulturedCode로 들어갔다니~

2009년 2월 18일 수요일

iGTD 2

iGTD2에 대한 리뷰를 작성하고자 할 때 이런 저런 고민이 많았다. 일단 어플리케이션 자체가 알파 버전인데다가 향후 업데이트에 대한 기약이 불안하기 때문에, 과연 이러한 어플리케이션을 나 자신이나 GTD에 관심있는 다른 이들을 위해 추천할만한가에 대한 의문 때문이었다. 하지만 나를 포함한 iGTD 및 iGTD2 사용자들의 바램으로 조만간에 새로운 업데이트가 등장하든지 혹은 완전히 업데이트에 대한 기대를 포기하든지에 대한 결론이 날 것으로 기대(?)하고 있다.

iGTD2는 맥킨토시용 GTD 어플리케이션의 대표격으로 알려진 iGTD의 후속 버전으로 개발 진행중이었다. 하지만 개발자인 Bartel의 개인 사정으로 알파 버전이 공개된 이후 1년 이상 업데이트가 중지되고 있다. 또한 Inbox, OmniFocus, Things 등과 같이 새로운 GTD 어플리케이션의 등장으로 iGTD2는 더 이상 비교 대상에서 순위가 낮아 지고 있는 실정이다. 그럼에도 불구하고, iGTD2가 추구하는 GTD 기반 라이프-스타일이 내 취향에 맞다고 판단하여 시스템의 불안정성과 향후 지속성의 보장에 대한 우려에도 사용하고 있다.

iGTD2가 비록 iGTD의 다음 버전이기는 하지만 iGTD에 비해 많은 변화가 있었다. 가장 눈에 띄는 변화는 기존의 왼쪽 화면에서 사용하도록 지정된 Project와 Context라는 GTD의 고정된 영역이 좀더 유연하게 사용할 수 있도록 설계되었다. Context의 경우 동일하게 왼쪽 화면에 위치한다고 볼 수 있지만, 사용자가 Context를 일일이 구분하는 것이 아니라 주제(topics), 위치(places), 자원(resources), 시간(due dates) 등으로 대분류가 구성되어 있다. 원래 계획에는 사람(people)도 포함될 예정이었으나 현재는 따로 구분되어 있지 않다. 그리고 Project의 내용이 오른쪽으로 완전히 옮겨지면 iGTD의 고정 화면으로 인해 긴 프로젝트나 액션 이름이 제대로 보이지 않는 문제가 해결되었으며, iGTD2에서는 각 화면의 크기 조정이 가능하다. 단순한 화면이 개선이지만 이 부분에서 많은 차이점을 발견할 수 있다. 그 가운데 가장 새로운 점은 '탭'과 '포커스' 기능이다.

1. 웍플레이스/기능

iGTD2는 위에서 언급한 바와 같이 iGTD의 명확한 Context/Project 구분을 사용자에게 보다 많은 유연성을 주기 위한 방법으로 새롭게 설계되었다. 대표적인 것이 대상을 다루는 웍플레이스라는 새로운 '탭' 방식의 스타일이다. 이것은 개별 Project나 Action을 보다 심도 깊게 관리할 수 있다는 면에서 iGTD2를 단순한 GTD 어플리케이션에서 정보의 입력과 관리 도구로서도 운용할 수 있게 해 준다.

비록 사용자들에게 적극적인 활용을 기대할 수 있을 지는 의문이지만, 동시에 여러가지 Project나 Action을 관리해야 하는 경우에는 여러 화면이나 디렉토리를 헤매지 않고 작업을 진행할 수 있다면 면에서 큰 장점이 될수도 있다고 본다. GTD 어플리케이션의 운용에 있어 하나의 Project나 Action이 즉각적인 판단이 어려운 경우을 많이 접하게 된다. 이러한 경우 각 대상에 대해 이런 저런 판단을 위한 자료의 입력이나 분석 등을 별도의 도구를 사용하기도 하지만 매우 번거롭다. iGTD2는 여러 사안에 대하여 기본적인 메모, 노트 및 링크 그리고 사람 등에 대한 정보를 각 웍플레이스로 구분하여 다룰 수 있다.

문제는 현재로서는 워크플레이스의 생성은 가능하지만 삭제가 지원되지 않고 있으며, 워크플레이스 내에서 포커스로 지정된 사항들이 가끔씩 사라지는 경우가 있다는 것이다.

2. 포커스/필터 기능

iGTD2의 포커스 기능은 앞서 언급한 Context/Project의 명확한 구분이 가지는 문제를 해결하기 위한 방안의 하나이다. iGTD2에서는 포커스 기능의 구현을 위해 강화된 태그 기능을 사용한다. iGTD에서 태그 기능은 검색을 위한 키워드 수준으로 이용되는 정도였다면 iGTD2에서는 가장 주요한 역할을 한다.

수집함으로 모인 대상들은 필요에 따라 Project, Action 혹은 Reference로 분류된다. iGTD2는 각 대상들에 대하여 여러 개의 세부 태그로 필터를 지정할 수 있다. 이미 입력한 태그는 첫 분류 기준으로 자동으로 입력된다.

이어 context에는 해당되는 단일 혹은 복수 태그의 필터에 의해 Project, Action 그리고 기타 사항들이 자동으로 나타나게 된다. iGTD2는 이러한 각 context를 주제, 장소, 자원 그리고 시간별로 구분해 놓고 있다. 그리고 사용자는 이미 설정된 context 외에 다른 태그 조건으로 필터를 구성하여 새로운 context를 설정할 수 있다.

또한 각 context는 다른 context들과 조합으로 새로운 필터를 구성할 수 있다. iGTD2에서는 context 개별 혹은 조합으로 이루어진 사항을 task라고 한다.

일반적으로 GTD 어플리케이션에서 하나의 사안에 대하여 Context가 지정되게 되지만, 다른 Context와의 연관성이 있는 경우 두 개 이상의 Context를 필요로 하는 경우 가 있다. 예를 들어 CulturedCode의 Things는 새로운 멀티 태그 기능으로 이러한 유연성의 부족 문제를 완벽하게 해결한 사안으로 볼 수 있다. iGTD2에서는 각 Context 간의 조합(포커스)을 방안으로 제시했다. 즉, 각 사항이 가지는 주제, 현재 분류된 장소, 자원 그리고 시간에 대한 세부 Context에 대한 태그 필터를 이용하여 '이번 주 내로 집에서 맥북으로 새로운 기획안 작성하기'와 같은 새로운 포커스를 만들 수 있다.

하지만 현 단계의 iGTD2에서는 포커스 기능과 관련하여 몇 가지 문제(버그)들이 있다. 기본적으로 포커스 기능의 문제라기 보다는 Context들이 개별 Action에 대해서는 필터에 작동하지만 Project에 대해서는 아직 적용되지 않는 문제가 있다. 또한 새로운 포커스나 태스크 생성을 위한 인터페이스가 꽤나 번거롭다는 점이 아쉽다. 그럼에도 이러한 포커스/필터를 이용한 태스크 관리는 다루어야 할 내용이 많은 경우 매우 효과적이다.

이러한 포커스/필터 기능은 Inbox, Tasks, Note & Links 그리고 Archive와 같은 iGTD2의 모든 화면에서 동일하게 적용할 수 있다.

3. Project & Task

iGTD2는 다른 GTD 어플리케이션과 마찬가지로 단일 작업에 대해서는 task, 복수 작업에 대해서는 project로 지정할 수 있다. 차이는 project의 경우 폴더 형태로 나타난다는 것 이외에는 특별한 차이는 없고, task와 project 간에는 서로 전환이 가능하다. Task 윈도우에서 직접 생성된 task와 project는 서로 간이 전환이 되지 않는 문제가 있다. 하지만 어차피 두 사항에 대하여 계층 구조를 생성할 수 있기 때문에 사용에 문제가 있는 것은 아니다.

이처럼 iGTD2는 iGTD에서와 같이 task나 project에 대한 하부 사항으로 계층적 구조를 생성할 수 있다. 이때 계층적 구조에서 하부 사항들이 모두 완료되면 상부 사항은 자동으로 완료된다. 때문에 해당 작업 완료 후 다른 작업들이 있는 경우라도 미리 후속 작업을 지정해 두지 않으면 상위 작업이나 프로젝트가 모두 archived 윈도우로 이동할 수 있다. 때문에 계층적 구조를 제대로 구성하기 위해 각 작업 간의 우선 순위에 신경을 쓸 필요가 있다. 단순히 작업의 우선 순위는 각 작업의 순차적인 절차로 지정하면 되지만, 일반적으로 GTD 어플리케이션에서 계층적 구조를 지원하는 경우 애써 구조화를 시키려는 경향이 있기 때문이다.

이에 반해 아쉽게도 반복적인 작업을 위한 Repeating이 항목이 있긴 하지만 작동하지 않는다. 덕분에 불편하지만 일일이 작성하거나 아예 iCal에서 관리하도록 해야 한다.

4. iGTD2문제점

위에 개별적으로 언급한 사안들 외에 시스템이 불안정하다는 것이 가장 큰 문제이긴 하지만 이런 경우에도 데이터 자체에는 거의 손실이 없다는 점에서 별도로 언급할 필요는 없다고 본다. 어차피 알파 버전에서 시스템 안정성을 강요하는 것 자체가 큰 무리가 있다고 본다. 하지만 시스템이 가볍기 때문에 특별한 시간적 손실없이 재구동이 가능하다. 그리고 현재 iCal의 동기화가 정상적으로 지원되지 않고 있다. 프리퍼런스나 태스크 설정에는 iCal과의 동기화 항목이 나타나지만 이런 사항들이 실제로 적용되지는 않는 것 같다.

이외 가장 큰 문제는 특징으로 언급한 주요 기능의 세부 사항들이 완성되지 않았다는 점이다. 항목들의 폰트 형태나 색상 지정 등과 같은 사안들이다.