GTD: Getting Things Done

From Wiki4Intranet
Jump to: navigation, search

Очередная рекомендация на тему «что послушать» — must-read книга Девида Аллена «Getting Things Done».

Это действительно мастрид для IT-культурного человека, возможно наличие статьи в Википедии, сотен тысяч результатов в гугле, и рецензия Игоря Беспальчука убедят вас в этом.

Но (лайфхак! лайфхак!) mustread-книгу не обязательно читать, особенно когда она стала классикой, т.е. когда куча ее революционных положений стала общеизвестными банальностями, и при чтении постоянно будут возникать вопросы — «разумно ли я трачу свое время/глаза/энергию?». Ее можно слушать, ведь аудиоверсию, скажем так, легко найти Интернете.

«Getting Things Done®™» (да-да, это теперь не только книга, но и зарегистрированный торговый знак, и методология, и бренд) — но я говорю о конкретной аудиокниге, первой книге Аллена по теме, которая не полностью раскрывают его методологию во всей широте, но на самом деле, ИМХО, проговаривает самые важные, радикальные вещи, сломавшие хребет классическому календарному тайм-менеджменту с одной стороны и подходу «все в моей голове» с другой.

Слушается книга легко, добротная озвучка менторским тоном от чтеца-профессионала → можно прослушать не напрягаясь даже несколько раз, что, кстати, я и проделал → и каждый раз все это наводило меня на новые мысли.

Интересный, ориентированный на читателя язык. Как пример, использование странного словосочетания «незамкнутые циклы» («А-а! Циклы! Незамкнутые! Деление на ноль!») для обозначения незавершенных дел. Но оно работает! Как-то скоро я стал ощущать, что да, это действительно циклы, и действительно незамкнутые! Это напомнило мне эффект «командирской заруки» из Пелевина[1]

Не держать дела в голове!

Т.е. первое важнейшее утверждение — ни в коем случае не держать дела в голове, она не приспособлена для этого!

В виду важности сообщений, Гени зафиксировал их в мозгу, с помощью специального приспособления, построенного на способности некоторых лучей бирадия *) раздражающе действовать на мозговые извилины и тем самым закреплять в памяти известные впечатления и мысли. Прием — известный очень немногим. ©

И дело тут не только в ограниченности кратковременной памяти («5±2», «4±1»), в скорее в механизмах функционировании долговременной памяти, когда единственным методом поддержания актуальности информации является принудительная перезагрузка информации о делах через кратковременную память, но в отличие от четко функционирующих механизмов DDR-памяти, мозг человека использует такую «шину» как центральная нервная система, и тупой болевой механизм, чтобы заставить «вспомнить все».

Начиная с некоторого, достаточно небольшого объема «висящих в памяти» задач возникает сплошной болевой фон — «аврал! ничего не успеваю! все пропало, гипс снимают, клиент уезжает», причем приоритезацию «это в 100 раз важней этого» мозг делать не может, и таким образом, либо какие-то мелочи семейной жизни глушат «мильонбаксовые» проблемы, либо получается рассеянный асоциальный тип, полностью в глобальных проблемах и абсолютно забывших об остальном.

Пока кибернизация и улучшения человеческой породы не произошло, можно использовать только концепции Extended Mind, т.е. использование внешнего хранения и приоритезации задач, осталось только понять, как именно это сделать эффективно, ибо к моменту написания книги (2000), уже были и календари-органайзеры, и электронная почта, и программы-календари, и даже программы проектного планирования, типа MS Project, но народ страдал по-прежнему, и было ощущение, что это не совсем то.

Т.е. и возникали связные вопросы «как это хранить и как это обрабатывать», и Аллен показал, что календарный подход, с жесткой привязкой сроков выполнения для задач, в не зависимости от того, сделал ли это человек (стандартная работа с календарями), или программа планирования (тот же MS Project) — это неоправданная жесткость, навязывание несуществующих ограничений. Привязка к времени нужна очень редко, для моментов синхронизации (встречи, совещания, демонстрации), а для всего остального нужно использовать концепции теории массового обслуживания — очереди[2], правило их формирования и обработки.

Т.е. все должно регистрироваться! В одной или нескольких входящих очередях («корзинах», «inbox-ах» и т.п.).

Например, в качестве таких очередей у меня:

  • Блокноты, когда я оффлайн (еду в транспорте, на совещании, и т.п.) — там я составляю списки или рисую майндмапы.
  • Когда я «читаю интернет» — использую наш супермеханизм викизакладок. Одной основной, но и иногда для отдельных книг (отбор цитат) или задач — завожу отдельные.
  • Иерархию личных вики-заметок Участник:StasFomin/Tasks — иерархический личный беклог, в который легко добавить новое, и очень просто регулярно актуализировать. Когда дело доходит до серьезной длительной работы — кодирование, взаимодействие с другими сотрудниками — тогда уже я завожу и баги.
  • Очередь багов с «флагами-запросами» ко мне.
  • Очередь новых задач на меня.
  • Электронная почта (N-аккаунтов).

Да, тут есть проблема «что из этого главное» и «как синхронизировать». ИМХО тут идеального решения в обозримое время не будет, с этим надо смирится и жить.

Так вот, тут я считаю, что абсолютная целостность не нужна, важно, чтобы было одностороннее движение проблем по очередям до момента их решения. А основная технология односторонней синхрозации — copy-paste (плоский текст рулит), или вбивание руками.

Note.svg C слепой десятипальцевой печатью я печатаю быстрее, чем пишу рукой, и практически со скоростью мысли. Если вы задумались о повышении личной продуктивности, то это первое, чему нужно научится. Если уж какие умения и инвентаризировать («грейды», «списки необходимых компетенций», «планы развития»), чтобы потом спрашивать с сотрудников — так вот, начинать нужно с этого — это просто, это легко верифицируемо, это общеполезно.

[svg] Т.е. доехав до работы — я обрабабываю «очередь из блокнота», зачеркивая обработанное и даже вырывая листы. Также я помечаю «обработанную почту» или стираю «викизакладки» заводя соотвествующие баги.

Как обрабатывать «входящее» — следующая тема.

Обработка «Входящих»

Ну во-первых, обработка должна быть. Есть ибо есть «псевдоGTD»-подход — дело куда-нибудь записать («блокнот», «бумажка»), расслабится и потерять записанное. Этого конечно надо избегать, и если записывать в «пассивных хранилища», то они должны быть там, где ты регулярно бродишь, либо пользоваться «активными», которые сами могут напомнить о себе.

Ключевые слова, которых Девид Аллен не говорил, но которые должны быть понятны ITшникам, и которых за него скажу я → «сериализация» и «обход в ширину».

Обработка входящих дел должна быть последовательной.

Вне зависимости от внешней «важности», или внутреннего «интереса» к задаче. Это помогает бороться с синдромом перфекциониста, когда человек, взяв одну задачу и начав «раскапывать тему» зарывается в деталях, ответвлениях, связанных проблемах, при этом остальная его очередь простаивает нетронутой. Сам автор называл этот процесс «стрижкой яка».

[svg]

Также неправильно выбирать задачи для обработки случайно или эвристично — тогда с высокой вероятностью, что-то важное тоже может неограниченно долго валятся без внимания.

Только последовательное рассмотрение новых задач из входящих, решение легких вопросов на месте и сходу, и диспетчеризация остальных вопросов в очереди по приоритетам, направлениям, и исполнителям.

Технически, на примере Bugzilla, для нас это означает, что по крайней мере ежедневно вам нужно сначала пройтись по запросам-вопросам «RequestsToMe», и ответить на все из них (если что-то сложное — надо клонировать блокирующий баг и начинать исследование), затем, рассмотреть все баги из категории «NEW», и либо взять их на себя, определив их «очередь» заданием продукта-приоритета-важности и т.п., либо перенаправив по адресу. Ибо иначе, вы оказываетесь вольным или невольным виновником блокировки других задач и сотрудников. И собственно, чтобы такого не случилось, мы запускаем снова встроенный механизм «нытья» в Bugzilla, когда она будет напоминать о нерассмотренных багах в состоянии «NEW», о неотвеченных флагах-вопросах, о полузабытых багах в состоянии «RESOLVED LATER». (, )

«Решение сходу» — тоже важный момент, ибо если накладные расходы на рассмотрение (открыли баг, прочитали, осознали) сравнимы с временем на ее решение — глупо откладывать решение и повторять расходы на загрузку в голову контекста задачи. Автор говорит о «двух минутах» — но это время связанное с выборкой из папок и чтением обычного листа бумаги, так что «две минуты» — это не догма, это зависит от класса задач и используемых инструментов.

Что же такое рассмотрение задачи и какова должна быть его глубина (время на анализ)? Тут как раз применяется техника «поиска в глубину», можно даже сказать «с отсечением ветвей и границ», чтобы быстро определить первый, «листовой» шаг по задаче, для того, чтобы возможно, обнаружить, что он зависит от других людей или организаций и вовсе заблокирован чем-то еще — и обраружив это, сходу запустить процесс разблокирования (позвонить кому-то, узнать что-то, поставить подзадачу, заказать что-то из штатов и т.п.), и переключится на другие, незаблокированные задачи.

[svg]


И обратите внимание, все это опять таки бьет PUSH-парадигму (на вас упала задача, вы прервались и бросились ее делать), заменяя ее PULL — вы «вошли в поток», и спокойно и последовательно «тащите» из очереди задачи.

Ну и если что-то осталось таки непонятным → разные варианты схем «GTD-workflow» можно найти в инете, например даже в в википедии.

Хранение дел

Тут автор делает крутой ход — вместо того, чтобы описать «идеальный трекер задач» или наоборот, как использовать распространенные программы и сервисы, чтобы было ОК, делает ход конем, и описывает «бумажную багзиллу» — систему очередей задач «43 папки» (12 месячных и 31 дневная папка ). Ну что же, это можно послушать, посмеятся, хотя может быть для организации домашнего делопроизводства с использованием жены и детей, будет ОК.

Впрочем, там был важный совет — системы бумажного хранения — не реляционная база, с произвольным доступам по разным индексам, тут надо сразу определиться, классифицируем мы информацию по темам, алфавиту или датам. С этим я безусловно согласен — все помнят, какой ужас являют собой технологии стандартных библиотек с их громоздкими картотеками, и никому это не нужно для хранения счетов или чеков.

Лично я, для хранения всяких чеков склонился к простому, хронологическому подходу (папки по годам), остальное — full table scan.

Инфографическая схема

Для любителей плакатов — распечатай и повесь на стену.



  1. «Чапаев и Пустота»
     
    Он кивнул на притихшую площадь, над которой разносились слова Чапаева:
    - Только бы дело свое не посрамить - то-то оно, дело-то!... Как есть
    одному без другого никак не устоять... А ежели у вас кисель пойдет - какая
    она будет война?.. Надо, значит, идти - вот и весь сказ, такая моя
    командирская зарука... А сейчас комиссар говорить будет.
    
    …
    
    - О, до вас в этой области мне далеко. Кстати, не объясните ли вы,
    что такое зарука?
    - Как? - наморщился Чапаев.
    - Зарука, - повторил я.
    - Где это вы услыхали?
    - Если я не ошибаюсь, вы сами только что говорили с трибуны о своей
    командирской заруке.
    - А, - улыбнулся Чапаев, - вот вы о чем. Знаете, Петр, когда
    приходится говорить с массой, совершенно не важно, понимаешь ли сам
    произносимые слова. Важно, чтобы их понимали другие. Нужно просто отразить
    ожидания толпы. Некоторые достигают этого, изучая язык, на котором говорит
    масса, а я предпочитаю действовать напрямую. Так что если вы хотите
    узнать, что такое "зарука", вам надо спрашивать не у меня, а у тех, кто
    стоит сейчас на площади.
    
  2. Напрямую он так не говорил, это мое творческое осмысление

Статья реплицируется в Wiki4IntraNet.

[ List view ]Comments

(no items)

Please login to comment.