GTD의 절차적 진행 단계로 볼 때 수집 이후는 수집된 대상에 대한 분류와 평가 그리고 조직화(구성) 단계가 이어진다. 절차적으로 분류 및 평가는 이후 조직화와는 별개로 구분되지만 하나의 어플리케이션에서 이를 명확하게 분리하여 개별 기능으로 구현하기는 쉽지 않다. 또한 어느 하나의 단계의 구현에 치중하게 되면 다른 단계는 기능적으로 유명무실해 질 수 있는 다소 경계가 모호한 부분이기도 하다. 때문에 OmniFocus(이하 OF)와 같은 컴퓨터 기반의 어플리케이션들에서는 기능 구현은 GTD의 절차적 단계 진행과 다소 차이가 날 수 있다.
우선 Porcess 단계의 첫 과정은 GTD의 관리 대상 여부의 판단부터 시작하게 된다. 다시 말해 수집함이나 Inbox의 대상에 대하여 ‘일’로서 ‘관리’해야만 할 대상인지를 평가하는 과정이다. 먼저 ‘일’은 행동과 결과를 모두 수반하는 대상이며 또한 단순하게 행동만 하므로 써 완수되는 간단한 대상이 아닌 나름 조건과 계획을 필요로 하는 수준이어야 한다. 예로 단순히 어느 지점으로 이동한다거나 뻔한 결과가 정해 진 정형화된 행동은 비록 일이지만 GTD에서 관리될 필요성까지는 없다고 본다; 물론 사안 마다 그리고 개인의 생각 마다 경우가 다를 것도 분명하다. 더불어 어렵고 복잡한 일처럼 보이지만 결과나 목표 그리고 목적 등이 명확하지 않거나 하는 대상 역시 GTD에서 모두 관리하기는 무리가 있다고 본다. 마찬가지로 수 년 후 미래의 바램 등과 같은 계획이나 기대 등도 동일한 경우로 볼 수 있다. 떄문에 이러한 일들이 GTD에거 관리되기 위해서는 명확한 일로 명시될 수 있어여 한다. 이러한 기준에서 OF의 수집함의 모인 대상에 대하여 다음과 같은 관리 단계를 적용한다.
- 대상이 일로 판단되지 않고 참고자료의 필요성도 없다고 판단되면 Inbox에서 삭제한다. OF의 Inbox에서 삭제된 대상들은 별도로 저장되지 않기 때문에 이후 View 설정에서 All을 선택해도 보이지 않는다.
- 물리적인 대상의 수집 과정에서 본의 아니게 일이나 업무와 무관한 개인적 범위의 대상이 수집되었다면 이는 반드시 GTD 적용과 무관하게 별도로 분류하여 보관한다.
- 일이 아닌(명확한 행동을 요구하지 않는) 참고자료로 활용될 수 있는 대상은 별도의 관리 폴더로 옮긴다. 레퍼런스를 위한 별도의 그룹 폴더를 사용하거나 @Reference 컨텍스트를 지정할 수 있다. 만일 그 판단이 명확하지 않은 대상이라면 @Someday/Maybe 등과 같은 향후 검토용 컨텍스트를 지정할 수 있다. OF에서 이 두 컨텍스트는 별도로 관리되며 또한 두 경우 모두 직접적인 일로서 관리되지 않으므로 프로젝트를 지정하지 않도록 한다.
- 기준 시간(2 ~ 5 분) 내에 실행이 가능한 일로 판단되면 즉시 처리한다. 하지만 현실적으로 OF와 같은 어플리케이션의 분류 작업 중간에 처리하기는 쉽지 않을 수 있기 때문에 상황에 따라 판단하도록 한다.
- 일은 개별 업무 혹은 그리고 진행 중인 프로젝트 내의 업무 그리고 새로운 프로젝트 중의 하나가 된다.
- 개별 업무나 기존 프로젝트 내의 업무지만 스스로 수행할 수 없거나 타인에 의해 수행되어 내 업무에 영향을 미치는 일이라면 위임 항목으로 별도 관리히다. OF에서는 @Delegated 컨텍스트로 지정할 수 있다.
- 일 임에도 특정 날짜나 시간에 진행되어야 하는 사안은 별도 관리 체계, 캘린더 시스템에서 관리하도록 한다. 예로 ‘A씨와의 미팅’이라고 적힌 메모지가 있다면 이것은 일이 아닌 일정으로서 달력으로 옮겨져야 한다. 명확한 행동과 목표를 지정할 수 없기 때문이다. 실제 달력에 기입하거나 Mac OS X의 캘린더를 이용한다. OF 2에서는 Forecast 화면이 추가되어 OF의 업무 일정과 함께 Apple Calendar의 항목을 함께 볼 수 있다. 유용한 기능이긴 하지만 시각적 표현은 적절하지 않은 듯 하다.
- 프로젝트가 아닌 개별 업무나 기존 프로젝트의 업무로 판단되면 해당 프로젝트와 컨텍스트를 지정 한다. OF에서는 프로젝트와 컨텍스트 중 하나 혹은 모두가 지정된 경우처럼 분류 작업의 완료 조건을 지정할 수 있다.
- 신규 프로젝트로 설정되는 경우에는 이미 존재하는 프로젝트 이름과 너무 유사하지 않도록 정하는 것이 좋다. 또한 다른 프로젝트와 구별될 수 있는 범위에서 가능한한 길지 않게 설정하는 것이 좋다. 프로젝트의 경우 별도로 컨텍스트를 지정하지 않거나 @Project라는 컨텍스트를 지정할 수도 있을 것이다.
- 추가로 OF의 각 항목에 대한 날짜 및 시간 조건을 입력할 수 있다. 일의 시작, 마감, 진행 및 반복 등과 같은 조건들의 입력은 OF에서 GTD의 Tickler 기능 구현을 위한 관리 요소이다. 만일 시간 조건이 명확하지 않다면 성급하게 지정하기 보다는 이후 Review 과정에서 설정할 수 있도록 한다.
- OF의 일과 업무에 대한 시간 정보에서 시작 일과 마감 일에 대한 기준을 실제 업무 마감일로 할 것인지 마감을 위한 업무 시작일로 할 것인지에 대한 기준을 정해야 한다. 예로 OF는 Tickler 기능의 수행을 위해 시작일에 해당 대상을 다음 업무 목록으로 올리게 된다. 그러므로 OF에서의 업무 시작은 실제 시작일로 마감일은 해당 업무 자체에 지정된 마감일로 설정할 수 있다. 이때 마감일이 실제 해당 업무의 절대적 마감 기준인지 사용자가 임의로 지정할 수 있는 기준인지에 대해서도 명확해야 한다. 기본적으로 특정 마감일이 지나 업무 수행의 의미가 없어지는 마감일이 아닌 경우라면 절대적 기준으로서 마감일의 역할을 의미가 없다고 볼 수 있다.
- Inbox의 전체 수집 대상에 대하여 위와 같은 조치가 완료되었으면 Clean Up 기능을 실행하여 각 항목은 대상 폴더로 이동될 수 있도록 한다.
이상과 같은 분류와 조직화 과정의 핵심은 수집된 대상이 ‘일’로서 어떻게 관리할 것인지를 평가하는 단계이다. 하지만 수집 대상을 일로서 판단하는 과정(분류 단계) 이후 그 일을 위임이나 프로젝트 내로 이동하는 과정 혹은 단일 업무 목록으로 지정하는 과정(조직화 및 평가 단계)을 구분하여 진행하기란 매우 어색하고 비효율적일 수 있기 때문에 OF에서는 이러한 두 절차적 단계를 동시에 진행 된다.
- OF에서 굳이 두 단계를 구분하여 적용하고자 한다면 분류 단계에서는 Inbox의 수집 대상에 대하여 먼저 일이 아닌 대상을 삭제하고 이어 참고 자료나 대기 자료로 먼저 판단된 대상을 별도로 이동하고 남은 일로서의 후보들에 대하여 즉시 실행할 수 있는 업무를 실행하고 그리고 남은 업무 목록을 위임 사항과 다음 업무 목록으로 구분한다. 이어서 조직화 및 평가 단계에서는 각 위임 사항과 업무 사항에 대한 세부 분류 및 평가 작업을 따로 진행할 수 있다.
추가로 프로젝트 내로 옮겨진 신규 업무의 순서를 점검하여 새로 정렬하는 작업은 별도 과정으로 진행하거나 이후 Review 단계에서도 수행할 수 있다. 하지만 Review 단계는 기본적으로 진행 중인 프로젝트의 관리라고 볼 수 있으므로 신규 프로젝트의 배치나 프로젝트 업무 간 순서 조정은 별도로 진행하는 것이 효율적일 수도 있다. 하지만 이상의 이러한 원칙(?)적인 방법과 달리 OF에서는 모든 것을 무시하고 Quick Input 단계에서도 프로젝트와 컨텍스트 그리고 시간 조건 심지어는 완료 여부까지 을 즉시 입력하여 분류와 조직화는 마무리까지 할 수도 있다. 앞서의 여러 상황 중 어느 경우를 선택하는 것은 사용자의 몫이라고 할 수 있지만 가능한한 일관성을 유지하는 편이 좋다.
이러한 과정을 iPhone이나 iPad에서 운용할 경우에도 크게 다르지 않다. 하지만 Mac OS X에서의 OF에 비해 키보드 운용이 불편할 수 있기 때문에 수정이나 이름 변경 등이 많은 경우 나름의 적응이 필요할 것으로 본다.
