이전 포스팅에서는 OmniFocus를 사용하면서 과다한 프로젝트의 계층 구조를 만드는 것은 좋지 않다고 적었다. 하지만 OF가 프로젝트 관리 도구는 아니지만 일에 따라 범위나 깊이가 일상적으로 다루는 수준이 이상일 경우도 드물지 않을 것이다. 그런 경우 하나의 프로젝트를 2 ~ 3 단계 수준으로 유지하게 될 때, 내부에 너무 많은 세부 프로젝트가 생성될 수 있다.
이런 경우에 대한 대응은 단순하게 하나의 프로젝트를 시간 기준으로든 내용 기준으로든 여러 개의 프로젝트로 분할하는 것이다. 그렇더라도 별도로 모아 순차적 관리가 필요하다면 폴더를 만들어 한 곳에서 관리할 수도 있다. 그러하다고 해도 한 화면에 수십개를 넘어 100 여개의 프로젝트가 쌓일 수도 있다. 시각적으로 결코 좋은 그림은 아니다.
이때 눈으로 보이는 화면을 보다 이쁘게 구조적으로 만들려고 과도한 정리를 해서는 안된다. 물론 충분히 계층화된 처리가 효과적인 업무라면 당연히 계층 구조를 이용하면 구성하는 것이 좋다. 다만 눈에 보기 좋도록 하기 위한 조치는 자제하는 것이 좋다. GTD 시스템으로 OF의 운용은 관리 기준에 따라 관리 대상을 점검하는 방식으로 진행하는 것이 전체 프로젝트 현황을 보고 관리하는 것 보다 백배 효율적이다.
OF에서는 각 프로젝트(세부 프로젝트에서는 불가하다)에 대한 검토 기간을 설정할 수 있기 때문에, 수정이 잦거나 자주 점검해야 하는 프로젝트라면 최소 1일 단위로까지 검토 기간을 줄일 수 있다. 때문에 분할된 각 프로젝트를 일일 검토 사안으로 관리한다면 전체 프로젝트에 대한 관리 수준에서도 큰 어려움이 없을 것이다.
하지만 계층화된 프로젝트를 여러 개의 프로젝트로 분할하기 위해서는 각자 나름의 요령이 필요하다. 물론 그 과정을 한번에 모두 완성 시킬 필요는 없다. 프로젝트에 대한 관리가 지속되면서 검토 단계에서 지속적으로 수정할 수 밖에 없다.
일반적으로 회사나 사업과 연관된 일의 프로젝트라면 상대적으로 양도 많고 복잡할 것이다. 이런 프로젝트를 분할하여 여러 프로젝트로 만든다는 것은 쉽지 않기 때문 내부 각 단계의 세부 목표를 명확하게 정하고 이에 따라 분할하는 방법을 적용하는 것이 좋다. 특히 프로젝트의 규모와 내용 그리고 기한 등이 상대적으로 크고 많고 그리고 길다면 분할의 기준을 잡기 모호할 수 있다는 점에서, 한번에 분할하려고 너무 애를 쓰는 건 좋지 않다고 본다.
반면 나의 경우는 전체 프로젝트를 일단 조각을 낸 후, 폴더 단위로 넣어 검토 기간을 짧게 지정한 후 여러 프로젝트를 검토 과정에서 일괄 관리하는 방법을 사용한다. GTD 시스템으로서 OF는 전체 프로젝트가 아닌 개별 사안을 검토 기간에 맞춰 관리하는 방식을 최대한 활용하려는 스타일을 취한다.
이전 포스팅에서도 언급했지만 OF의 모든 프로젝트를 일괄적으로-프로젝트 개요 중심으로-관리하는 방법과 검토 기간에 맞춰-검토 개요 중심으로-관리하는 방법으로 나눌 때, 어느 하나의 방법이 전적으로 우수하다고 하기는 힘들다. 결국 업무 내용과 범위에 따라 달라질 수 밖에 없다. 하지만 GTD 시스템이란 것이 자신의 업무 관리 스타일에 맞도록 시스템을 운용하는 것이기도 하지만, 자신의 업무 관리 스타일을 보다 GTD 시스템이 지향하는 바에 적응하는 식으로 활용할 수도 있다.
