[OmniFocus의 기본 운용] Review, 프로젝트 관리

GTD의 Review 과정은 단순하게 보자면 계획한 일들이 실행하기에 앞서 필요한 조건이나 상황을 수정 및 정리하는 검토 과정이며 또한 진행 중인 업무나 프로젝트가 계획한 대로 잘 되어가고 있는 지를 정기적으로 검토 및 관리하는 단계이다. 그리고 OmniFocus(이하 OF)에서의 Review 단계는 GTD 운용에 있어 핵심적인 역할을 하는 과정일 뿐만 아니라 OF의 절차적 기능의 핵심이다.

 OF와 비교할 때 Things나 Wunderlist 등은 Review 단계에서의 관리를 사용자가 유연하게(구분된 기능이 없다고 볼 수 있기 때문에) 운용할 수도 있지만 대상 업무 일정이 너무 많은 경우 프로젝트 간의 계획과 검토가 혼란스러워 질 수도 있다. 반면 OF와 같이 Review 기능이 규정되어 있는 경우에는 기본적인 기능에 대한 학습이 선행되고 익숙해져야 효율적 관리가 가능하게 된다. 이런 점에서 OF의 Review 기능은 대부분의 사용자에게 있어 상당히 어색하고 이해하기 힘든 절차로 다가올 수도 있다.

 사실 OF를 시작하면서 처음부터 Review 기능을 적절하게 사용하기는 쉽지 않다. 기능적으로 어렵다기 보다는 이해가 잘 되지 않기 때문이다. 특히 일상에서 진행되는 업무의 양이 많은 것도 문제이지만 각 업무 별로 검토할 시간이 너무 짧게 느껴지기 때문에 느긋(?)하게 업무 관리 기간을 정기적으로 가지기도 쉽지 않다. 그리고 계획한 일들은 개 주변의 변화에 휩쓸려 예측과 다른 방향으로 진행되고 결과적으로 언제나 몸과 마음이 지쳐 있다. 하지만 처음에도 의도적으로라도 정기적으로 차분한 상태에서 OF의 Review 기능을 이해하고 시간을 가지고 적응하여 노력이 필요하다.

1. Review 환경 설정

OF의 Review 기능을 수행에 앞서 생각해야 할 것은 사용자가 Review 기간을 얼마 만에-정기적으로-진행할 것인 가에 대한 결정이다. 사실 OF는-물론 GTD에서도-이 과정은 가장 혼란스러운 부분 중 하나인데 이는 현실에서 Review와 일상의(일일) 업무 관리의 방식과 기준이 명확하게 구별하기 어렵기 때문이다. 일상의 업무 관리는 오늘 혹은-조건이 맞는다면-지금해야 할 일의 목록을 확인하고 실행하고 그리고 한 일에 대한 확인 과정이라고 볼 수 있다. 이에 반해 Review 과정은 일주일 혹은 정기적인 기간 동안 계획한(GTD에서 관리 중인) 전체 프로젝트의 진행 여부를 확인하고 문제가 있는 대상을 조정하는 과정이다. 기능적으로 큰 구별은 없다고도 볼 수 있다. 때문에 두 과정에서 실제 겹치는 부분이 많이 발생하게 된다. 굳이 구분하자면 일일 관리는 개별 업무를 중심으로 그리고 Review는 프로젝트 중심으로 진행된다고 볼 수 있지만, 각 과정의 관리 내용이나 범위를 너무 획일적으로 적용할 필요는 없다. 예로 오늘 해야 할 일 과정에서 전체 프로젝트를 수정할 사안이 있다고 이를 반드시 Review 기간까지 미뤄두거나 반대로 Review 과정 중 일일 업무 내용에 대한 검토를 하지 못할 이유는 없다.

 OF의 Review 기간은 Preferences의 Data & Time 설정에서 지정할 수 있다. GTD에서 추천 혹은 권장하는 Review 기간은 딱히 정해진 것은 아니지만 1 주일 내지는 1 주일을 넘지 않도록 하고 있다. 나는 최근에 이런 저런 일이 많아 3 일에 한번 Review 기간을 설정하고 있지만 상황에 따라 적절한 간격이라고 생각되는 기간으로 설정하면 된다. 하지만 Review 기간을 하루나 이틀 정도로 반복하는 것은 앞서 언급한 일일 업무 관리 범위와 중복될 수 있고 이로 인해 계획한 프로젝트에 대한 필요없는 잦은 변경이 가해질 위험도 있다. 그럼에도 OF의 사용자들은 대개 새로운 업무와 프로젝트 구성 후 자주 진행 상황을 검토하고 픈 의지가 생길 수 있다는 것도 사실이다. 무엇보다도 상황에 맞도록 최적의 기간을 설정하고 일관성 있게 유지하는 것도 중요하다.

 그리고 정기적인 점검 기간은 예로 일주일 단위로 설정했다면 금요일 오후나 토요일 오전 등의 효과적일 것이다. 하지만 Review 과정 자체가 너무 길어지지 않도록 15~30분(일주일 간격 기준) 정도를 미리 염두에 둔다. Review 기간이 짧을 수록 Review 과정의 시간도 짧아 지게 된다.

 Review 기간 설정에서 주의할 점은 기본 설정으로 지정된 기간에서 시작된 프로젝트나 개별적으로 Review 기간을 따로 설정한 프로젝트의 경우에는 기본 설정 기간이 바뀌더라도 기존 설정이 그대로 유지된다. 만일 이러한 경우 해당 프로젝트의 Review 기간을 새롭게 설정하고자 하면 Project 화면에서 해당 프로젝트를 선택한 후 한꺼번에 Review 기간을 재설정해 주어야 한다. 때문에 이러한 조건을 이용하여 특정 프로젝트의 Review 기간을 별도로 설정하므로 써 프로젝트 관리에 효욜적으로 이용할 수도 있을 것이다. 예로 장기적인 프로젝트의 경우 Review 기간을 월 단위로 지정할 수도 있을 것이다.

2. Review 작업 수행

Review 단계의 진행은 OmniFocus의 Project, Context 그리고 Review 화면에서 수행하게 된다. Review 화면 뿐만 아니라 Project나 Context 화면도 함께 사용하는 것은 Review 완료 후 전체 계획에 대한 검토에 따라 프로젝트 및 각 업무의 컨텍스트 수정도 함께 진행할 수 있기 때문이다. 따로 컨텍스트 별로 내용을 점검하는 시간을 가지기 쉽지 않으니 Review 수행 시에 여유가 되면 함께 진행할 수 있으면 좋을 것이다. 혹시나 OF의 Review에 대한 무언가 새로운 기대 혹은 오해를 가진 사용자들이 많을 수 있겠지만, 기능적으로 볼 때 OF의 여러 기본 기능과 다를 바 없다.

 OF의 Review 화면에는 지난 Review 완료 후 정해진 Review 시간에 해당되는 프로젝트들이 나타 난다. 그리고 한번도 Review 과정을 거치지 않은 프로젝트들은 계속 드러나게 있게 된다. 왼쪽에는 Review 대상 목록이 오른 쪽에는 해당 프로젝트의 전체 항목들이 나타난다. 기본적으로 Review 대상의 프로젝트는 활성화된 경우만 보여지고, 내부 목록에서도 완료된 일을 제외된다.

 Review 과정은 프로젝트를 보면서 계획대로 진행 중인지를 먼저 확인하고, 개별 항목 중 완료된 일 중 완료 처리가 되지 않은 항목을 먼저 처리 한다. 이어 전체 진행 상황을 고려하면서 각 항목 간의 우선 순위와 항목의 날짜나 컨텍스트 변경 사항이 있는 경우 이를 수정한다. 필요 없게 된 일이나 이름이나 내용이 수정된 경우도 즉시 변경한다. 검토가 완료된 프로젝트는 Review 완료로 처리한다. 혹은 프로젝트 진행 중 문제가 없거나 실행 전 대기 상태로 인해 별 다른 조치가 없는 프로젝트도 마찬가지로 Review 완료로 처리한다. 필요한 경우 프로젝트 자체를 삭제할 수도 있다. 하나의 프로젝트에 대하여 Review가 완료되면 다음 대상의 프로젝트로 진행되게 된다.

 Review 완료는 프로젝트 내용을 나타나는 화면 상단의 오른 쪽에 있는 ‘Mark Reviewed’를 선택하므로 써 목록에서 글자 색상이 옅어지면서 완료 처리가 된다. 같은 위치에는 Review 대상으로 나타난 프로젝트나 업무 목록은 전체 대상 수와 함께 Review 기간, 지난 번 Review 날짜 그리고 다음 Review 날짜가 나타난다. 아래 예에서 Review 간격은 3일이며 이전 Review 일자는 3월 10일 그리고 다음 Review 날짜는 오늘, 3월 13일로 보인다.

 이러한 방식으로 각 프로젝트에 대하여 이상의 과정을 진행하게 되면 전체 Review 과정이 완료되고 ‘All projects reviewd’ 메시지가 나타난다.

3. Review vs. 프로젝트 관리

OF의 Review 작업에서 가장 의문스럽게 생각될 수 있는 점은 전체 프로젝트 관리를 위해 Project 혹은 Context 화면에서 각 프로젝트나 컨텍스트의 업무 내용을 수정하는 것과 별도로 Review을 수행하는 것의 차이에 관한 것일 수 있다. 앞서 일일 업무 관리와 Review 진행의 차이에서 간략히 적었지만 기능적으로 볼 때 전체 프로젝트 관리와 Review 작업 간에도 기능적으로는 큰 차이가 없다.

 하지만 GTD의 목적이 현재 진행중인 업무들과 향후 추진해야 할 업무들로 인해 발생하는 스트레스를 미연에 예방하는 것이라는 점에서, 시간이 날 때 마다 자주 그리고 전체적으로 진행 중이거나 계획한 프로젝트를 검토하고 수정하는 것은 시간적으로 정신적으로 매우 힘든-또 다른-일이며 스트레이스가 될 수 있다. 때문에 프로젝트 관리를 정기적으로 그리고 기계적으로 처리하므로 써 관리 과정에서 발생하는 스트레스와 이로 인한 프로젝트 관리의 오류를 방지할 수 있도록 하기 위해 별도의 Review 작업을 진행한다고 볼 수 있다. 실제로 OF든 다른 어플리케이션에서 별도의 Review 작업이 아닌 단순한 프로젝트 관리나 컨텍스트 점검 등을 진행해보면 상당한 시간이 소요됨은 물론 작업 자체를 종료하기 힘든 경우도 많이 겪게 된다.

 처음에 OF의 Review 기능의 효용성을 느끼지 못한 상당 기간을 사용하지 않았지만 어느 시점 이후 나름 일관성을 가지고 정기적으로 Review 작업을 수행 함에 따라 실제로 프로젝트 관리 시간이 현저하게 줄어들게 되고 또한 프로젝트 자체에 대한 고민이나 걱정도 상당히 적어지게 되었다고 생각된다. 특히 언제나 현재 진행 중인 프로젝트에 대한 점검이 필요한 가에 대해 불안해 하던 경우도 사라지게 되었다.

 프로젝트 관리에서 다룰 내용이기도 하지만 만일 계획한 프로젝트가 현재 제대로 진행되고 있지 않다면 이에 대한 조치가 반드시 필요하다. 그 조치로는 지연되는 프로젝트의 실행 가능성을 다시 높이기 위해 내용을 점검하고 수정하거나 혹은 조건이 만족 될 때까지 일단 대기 상태로 만들어 다음 Review 작업 시 까지 잊어 버린다 등 다양한 방법이 있을 수 있다. 또한 아직 실행 되지 못하거나 지연 되고 있는 프로젝트라도 정기적으로 검토하므로 써 일상에서 갑자기 머리 속으로 들어와 생각을 복잡하게 만드는 일을 현저히 줄일 수 있게 된다.

4. 새로운 프로젝트의 점검

Review 기능의 일반적인 진행 절차에 포함되면서도 약간 차이가 난다고 볼 수 있는 것이 새로 진행하기 위해 추가된 업무나 프로젝트의 관리에 대한 것이다. 원칙적으로 이러한 대상들도 정기적인 Review 절차에 따라 진행하면 되겠지만 새로운 프로젝트의 경우 초기 입력이나 수정 사항이 많기 때문에 또한 진행 상황을 예측하기 어렵다보니 정기적인 Review 시간까지 기다리기 조급할 경우가 많다.

 이러한 경우를 위해 정기적인 Review 단계를 수행할 시점이 아니더라도 즉시 해당 프로젝트를 점검할 수 있도록 한다. 진행 중인 프로젝트와 달리 새로운 프로젝트의 경우 초기에 설정한 내부 업무에 대해 추가되는 사항도 많으며 수정 혹은 삭제되는 사항도 많다는 점에서 빨리 대응하지 못하면 제대로 된 관리가 힘들어 질 수도 있다고 본다. 만일 프로젝트의 내용 자체가 너무 많거나 복잡하면 OF의 Focus 기능을 사용하는 것도 효율적일 수 있다. 이러한 내용은 실제로는 OF의 프로젝트 구성과 관리 측면에서 다시 언급해야 할 사안이기도 하다.

5. iOS 기반 OF의 Review

Review 작업을 iPhone이나 iPad 버전에서도 수행할 수 있다. 기능적으로 iPhone이나 iPad에서의 Review 작업도 Mac OS X에서와 크게 다르지 않다. 그리고 상대적으로 iPad 버전의 OF에서의 작업이 iPhone 보다는 손이 덜 가기 때문에 수월하다. iPhone에서는 프로젝트와 내부 항목을 한번에 볼 수 없기 때문에 상당히 불편할 수 있다. 다만 역시나 프로젝트 내용이나 이름을 수정하는 등의 작업이 실제 마우스와 키보드를 사용하는 것에 비해 불편하다보니 iOS 기반으로만 Review 작업을 진행하는 것에 대해서는 고민할 필요가 있다고 본다.

[OmniFocus의 기본 운용] Process & Organize, 업무 분류 및 조직화

GTD의 절차적 진행 단계로 볼 때 수집 이후는 수집된 대상에 대한 분류와 평가 그리고 조직화(구성) 단계가 이어진다. 절차적으로 분류 및 평가는 이후 조직화와는 별개로 구분되지만 하나의 어플리케이션에서 이를 명확하게 분리하여 개별 기능으로 구현하기는 쉽지 않다. 또한 어느 하나의 단계의 구현에 치중하게 되면 다른 단계는 기능적으로 유명무실해 질 수 있는 다소 경계가 모호한 부분이기도 하다. 때문에 OmniFocus(이하 OF)와 같은 컴퓨터 기반의 어플리케이션들에서는 기능 구현은 GTD의 절차적 단계 진행과 다소 차이가 날 수 있다.

 우선 Porcess 단계의 첫 과정은 GTD의 관리 대상 여부의 판단부터 시작하게 된다. 다시 말해 수집함이나 Inbox의 대상에 대하여 ‘일’로서 ‘관리’해야만 할 대상인지를 평가하는 과정이다. 먼저 ‘일’은 행동과 결과를 모두 수반하는 대상이며 또한 단순하게 행동만 하므로 써 완수되는 간단한 대상이 아닌 나름 조건과 계획을 필요로 하는 수준이어야 한다. 예로 단순히 어느 지점으로 이동한다거나 뻔한 결과가 정해 진 정형화된 행동은 비록 일이지만 GTD에서 관리될 필요성까지는 없다고 본다; 물론 사안 마다 그리고 개인의 생각 마다 경우가 다를 것도 분명하다. 더불어 어렵고 복잡한 일처럼 보이지만 결과나 목표 그리고 목적 등이 명확하지 않거나 하는 대상 역시 GTD에서 모두 관리하기는 무리가 있다고 본다. 마찬가지로 수 년 후 미래의 바램 등과 같은 계획이나 기대 등도 동일한 경우로 볼 수 있다. 떄문에 이러한 일들이 GTD에거 관리되기 위해서는 명확한 일로 명시될 수 있어여 한다. 이러한 기준에서 OF의 수집함의 모인 대상에 대하여 다음과 같은 관리 단계를 적용한다.

1. 대상이 일로 판단되지 않고 참고자료의 필요성도 없다고 판단되면 Inbox에서 삭제한다. OF의 Inbox에서 삭제된 대상들은 별도로 저장되지 않기 때문에 이후 View 설정에서 All을 선택해도 보이지 않는다.
   • 물리적인 대상의 수집 과정에서 본의 아니게 일이나 업무와 무관한 개인적 범위의 대상이 수집되었다면 이는 반드시 GTD 적용과 무관하게 별도로 분류하여 보관한다.
2. 일이 아닌(명확한 행동을 요구하지 않는) 참고자료로 활용될 수 있는 대상은 별도의 관리 폴더로 옮긴다. 레퍼런스를 위한 별도의 그룹 폴더를 사용하거나 @Reference 컨텍스트를 지정할 수 있다. 만일 그 판단이 명확하지 않은 대상이라면 @Someday/Maybe 등과 같은 향후 검토용 컨텍스트를 지정할 수 있다. OF에서 이 두 컨텍스트는 별도로 관리되며 또한 두 경우 모두 직접적인 일로서 관리되지 않으므로 프로젝트를 지정하지 않도록 한다.
3. 기준 시간(2 ~ 5 분) 내에 실행이 가능한 일로 판단되면 즉시 처리한다. 하지만 현실적으로 OF와 같은 어플리케이션의 분류 작업 중간에 처리하기는 쉽지 않을 수 있기 때문에 상황에 따라 판단하도록 한다.
4. 일은 개별 업무 혹은 그리고 진행 중인 프로젝트 내의 업무 그리고 새로운 프로젝트 중의 하나가 된다.
   • 개별 업무나 기존 프로젝트 내의 업무지만 스스로 수행할 수 없거나 타인에 의해 수행되어 내 업무에 영향을 미치는 일이라면 위임 항목으로 별도 관리히다. OF에서는 @Delegated 컨텍스트로 지정할 수 있다.
   • 일 임에도 특정 날짜나 시간에 진행되어야 하는 사안은 별도 관리 체계, 캘린더 시스템에서 관리하도록 한다. 예로 ‘A씨와의 미팅’이라고 적힌 메모지가 있다면 이것은 일이 아닌 일정으로서 달력으로 옮겨져야 한다. 명확한 행동과 목표를 지정할 수 없기 때문이다. 실제 달력에 기입하거나 Mac OS X의 캘린더를 이용한다. OF 2에서는 Forecast 화면이 추가되어 OF의 업무 일정과 함께 Apple Calendar의 항목을 함께 볼 수 있다. 유용한 기능이긴 하지만 시각적 표현은 적절하지 않은 듯 하다.
   • 프로젝트가 아닌 개별 업무나 기존 프로젝트의 업무로 판단되면 해당 프로젝트와 컨텍스트를 지정 한다. OF에서는 프로젝트와 컨텍스트 중 하나 혹은 모두가 지정된 경우처럼 분류 작업의 완료 조건을 지정할 수 있다.
   • 신규 프로젝트로 설정되는 경우에는 이미 존재하는 프로젝트 이름과 너무 유사하지 않도록 정하는 것이 좋다. 또한 다른 프로젝트와 구별될 수 있는 범위에서 가능한한 길지 않게 설정하는 것이 좋다. 프로젝트의 경우 별도로 컨텍스트를 지정하지 않거나 @Project라는 컨텍스트를 지정할 수도 있을 것이다.
5. 추가로 OF의 각 항목에 대한 날짜 및 시간 조건을 입력할 수 있다. 일의 시작, 마감, 진행 및 반복 등과 같은 조건들의 입력은 OF에서 GTD의 Tickler 기능 구현을 위한 관리 요소이다. 만일 시간 조건이 명확하지 않다면 성급하게 지정하기 보다는 이후 Review 과정에서 설정할 수 있도록 한다.
   • OF의 일과 업무에 대한 시간 정보에서 시작 일과 마감 일에 대한 기준을 실제 업무 마감일로 할 것인지 마감을 위한 업무 시작일로 할 것인지에 대한 기준을 정해야 한다. 예로 OF는 Tickler 기능의 수행을 위해 시작일에 해당 대상을 다음 업무 목록으로 올리게 된다. 그러므로 OF에서의 업무 시작은 실제 시작일로 마감일은 해당 업무 자체에 지정된 마감일로 설정할 수 있다. 이때 마감일이 실제 해당 업무의 절대적 마감 기준인지 사용자가 임의로 지정할 수 있는 기준인지에 대해서도 명확해야 한다. 기본적으로 특정 마감일이 지나 업무 수행의 의미가 없어지는 마감일이 아닌 경우라면 절대적 기준으로서 마감일의 역할을 의미가 없다고 볼 수 있다.
6. Inbox의 전체 수집 대상에 대하여 위와 같은 조치가 완료되었으면 Clean Up 기능을 실행하여 각 항목은 대상 폴더로 이동될 수 있도록 한다.

 이상과 같은 분류와 조직화 과정의 핵심은 수집된 대상이 ‘일’로서 어떻게 관리할 것인지를 평가하는 단계이다. 하지만 수집 대상을 일로서 판단하는 과정(분류 단계) 이후 그 일을 위임이나 프로젝트 내로 이동하는 과정 혹은 단일 업무 목록으로 지정하는 과정(조직화 및 평가 단계)을 구분하여 진행하기란 매우 어색하고 비효율적일 수 있기 때문에 OF에서는 이러한 두 절차적 단계를 동시에 진행 된다.

• OF에서 굳이 두 단계를 구분하여 적용하고자 한다면 분류 단계에서는 Inbox의 수집 대상에 대하여 먼저 일이 아닌 대상을 삭제하고 이어 참고 자료나 대기 자료로 먼저 판단된 대상을 별도로 이동하고 남은 일로서의 후보들에 대하여 즉시 실행할 수 있는 업무를 실행하고 그리고 남은 업무 목록을 위임 사항과 다음 업무 목록으로 구분한다. 이어서 조직화 및 평가 단계에서는 각 위임 사항과 업무 사항에 대한 세부 분류 및 평가 작업을 따로 진행할 수 있다.

추가로 프로젝트 내로 옮겨진 신규 업무의 순서를 점검하여 새로 정렬하는 작업은 별도 과정으로 진행하거나 이후 Review 단계에서도 수행할 수 있다. 하지만 Review 단계는 기본적으로 진행 중인 프로젝트의 관리라고 볼 수 있으므로 신규 프로젝트의 배치나 프로젝트 업무 간 순서 조정은 별도로 진행하는 것이 효율적일 수도 있다. 하지만 이상의 이러한 원칙(?)적인 방법과 달리 OF에서는 모든 것을 무시하고 Quick Input 단계에서도 프로젝트와 컨텍스트 그리고 시간 조건 심지어는 완료 여부까지 을 즉시 입력하여 분류와 조직화는 마무리까지 할 수도 있다. 앞서의 여러 상황 중 어느 경우를 선택하는 것은 사용자의 몫이라고 할 수 있지만 가능한한 일관성을 유지하는 편이 좋다.

 이러한 과정을 iPhone이나 iPad에서 운용할 경우에도 크게 다르지 않다. 하지만 Mac OS X에서의 OF에 비해 키보드 운용이 불편할 수 있기 때문에 수정이나 이름 변경 등이 많은 경우 나름의 적응이 필요할 것으로 본다.