OmniFocus(OF)의 경쟁 우위의 인기 요인 가운데 하나는 프로젝트 심지어 태그(컨텍스트)에 대한 계층 구조를 지원한 덕분이라고 해도 과언이 아닐 것이다. 물론 다른 GTD 어플리케이션에서도 계층 구조의 프로젝트를 지원하지 않은 것은 아니지만, OF와 경쟁 관계의 제품 가운데에서 전체적인 완성도면에서 OF는 단연 선택 우위에 있다.
GTD 시스템에서 계층화된 구조의 프로젝트는 업무 관리를 위한 매우 효율적인 기능 요소가 분명하다. 하지만 어플리케이션을 개발하는 입장에서는 프로젝트와 같은 요소를 계층화하는 것은 어려운 일이 아님에도, Things와 같이 프로젝트의 계층 구조를 지원하지 않는 경우는 나름의 목적이 있다고 생각해 볼 수도 있지 않을까 한다.
물론 OF의 계층 구조 프로젝트는 기능적으로 아무런 문제 혹은 단점이 없다. 반대로 계층 구조의 프로젝트가 지원되지 않은 GTD 시스템을 사용할 경우 그 답답함은 굳이 언급할 필요가 없을 것이다. 하지만 아마도 OF의 사용자 가운데 많은 이들이 프로젝트의 계층화 구조 함정에 빠져 곤란을 겪어본 경우가 적지 않을 것이라는 생각한다.
만일 OF의 프로젝트 구조가 3 단계를 넘어 확장된다면-일단 폴더 구조를 제외하더라도-관리의 문제가 발생할 위험이 매우 높다. 폴더 구조까지 사용한다면 대충 하나의 업무 사항까지 4 ~ 5 단계 수준까지 확장된 것이다. 경험에 비춰 3 단계 이상 확장되면 관리 자체의 부하가 급격히 증가하며, 그러한 경우가 대부분이라면 일이 아닌 관리 체계를 관리해야 하는 수준이라고 본다.
늘 강조하지만 GTD 시스템은 특정 업무에 집중된 프로젝트들을 관리하는 도구가 아니며, 더욱이 OF3를 비롯한 모든 GTD 어플리케이션이 그러한 기능을 제대로 갖추고 있지 못하다. 프로젝트라는 기능적 용어로서 업무 목록에 대한 계층화 구조가 지원된다고 하더라도 이것은 일반적인 프로젝트 관리 기능과는 애초부터 비교될 수 없다.
때문에 OF를 이용하여 GTD의 프로젝트를 관리한다는 것은 일반적인 목표가 분명한 프로젝트를 관리하는 것이 아니라, 단순하게 하나의 목표 달성을 위한 다수의 세부 항목을 포함하는 업무 그룹을 관리하는 방식을 뜻한다.
다시 말해 GTD의 프로젝트를 기대한 목표 달성을 위한 기준으로 필요한 모든 사항을 포함하는 완벽한 프로젝트 관리 구조로 구성하려고 한다면 매우 어렵고 험난한 일이다. 개별 업무의 실행 및 수정에 집중하는 것이 아니라 프로젝트 구조의 완벽성에 집중하게 되는 순간 GTD 시스템은 신뢰성을 잃게 된다.
GTD 시스템에서 관리 되는 프로젝트의 수가 많다고 걱정할 수도 있다. 현재 OF의 프로젝트 수가 100개가 넘어가서 화면에 제대로 보기 힘들다고 일부러 계층화된 프로젝트로 전환한다는 것은 GTD 시스템을 오해하고 있는 것이다.
물론 예전 포스팅에서 너무 많은 프로젝트 혹은 항목을 관리하는 것은 비효율적이라고 적었던 것으로 기억한다. 다만 GTD 시스템으로 관리해야 할만한 일이 아님에도 무조건 수집하고 프로젝트로 구성했다면 분명 프로젝트를 정기적으로 정리할 필요가 있다. 하지만 하나의 프로젝트가 3 단계 이하로 확장될 정도로 복잡해진다면 앞서 언급한 바와 같이 다수의 프로젝트는 분해하는 것이 더 효과적이다.
프로젝트의 구조가 너무 확장되면 GTD 시스템이 지향하는 개별 사안의 실행과 수정을 통한 현재 실행 가능한 일의 우선적 처리라는 기본 핵심을 제대로 운용하기 어려워 질 수 있다. 특히 계층화된 프로젝트의 세부 프로젝트와 프로젝트의 각 항목의 설정 요소를 제대로 지정하지 않았지만 실행 시기나 완료 시기에 대한 확인 역시 어렵게 된다.
단순하게 정리하자면 OF를 사용하면서 Things의 단순함이 가지는 효용성을 적절히 이용할 필요가 있다. Things에 대한 경험이 없는 경우라면 이런 점에서 사용해볼만 하다고 생각한다.
댓글 없음:
댓글 쓰기