|
|
| Line 1: |
Line 1: |
| − | Очередная рекомендация на тему «что послушать» — ''must-read'' книга Девида Аллена «Getting Things Done».
| + | #REDIRECT [[Blog:Стас Фомин/GTD: Getting Things Done]] |
| − | | + | |
| − | Это действительно мастрид для IT-культурного человека, возможно наличие [[RuPedia:Getting Things Done|статьи в Википедии]], [http://www.google.com/search?hl=en&client=firefox&rlz=1R1GGGL_ru___RU322&q=+Allen+%22getting+things+done%22&aq=f&aqi=g-c1&aql=&oq=&gs_rfai= сотен тысяч результатов] в гугле, и [[Блог:Игорь Беспальчук/2010-02-21 Getting Things Done|рецензия Игоря Беспальчука]] убедят вас в этом.
| + | |
| − | | + | |
| − | Но (лайфхак! лайфхак!) ''mustread''-книгу не обязательно читать, особенно когда она стала классикой, т.е. когда куча ее революционных положений стала общеизвестными банальностями, и при чтении постоянно будут возникать вопросы — «разумно ли я трачу свое время/глаза/энергию?». Ее можно слушать, ведь аудиоверсию, скажем так, [http://www.google.com/#hl=en&q=%D0%90%D1%83%D0%B4%D0%B8%D0%BE%D0%BA%D0%BD%D0%B8%D0%B3%D0%B0+%D0%90%D0%BB%D0%BB%D0%B5%D0%BD+Getting+Thins+Done&aq=f&aqi=&aql=&oq=&gs_rfai=&fp=c401d881a5ff002f легко найти Интернете].
| + | |
| − | | + | |
| − | «Getting Things Done®™» (да-да, это теперь не только книга, но и зарегистрированный торговый знак, и методология, и бренд) — но я говорю о [http://mann-ivanov-ferber.ru/books/audio/011a/ конкретной аудиокниге], первой книге Аллена по теме, которая не полностью раскрывают его методологию во всей широте, но на самом деле, ИМХО, проговаривает самые важные, радикальные вещи, сломавшие хребет классическому календарному тайм-менеджменту с одной стороны и подходу «все в моей голове» с другой.
| + | |
| − | | + | |
| − | Слушается книга легко, добротная озвучка менторским тоном от [[RuPedia:Кузнецов, Всеволод Борисович|чтеца-профессионала]] → можно прослушать не напрягаясь даже несколько раз, что, кстати, я и проделал → и каждый раз все это наводило меня на новые мысли.
| + | |
| − | | + | |
| − | Интересный, ориентированный на читателя язык. Как пример, использование странного словосочетания «незамкнутые циклы» («А-а! Циклы! Незамкнутые! Деление на ноль!») для обозначения незавершенных дел. Но оно работает! Как-то скоро я стал ощущать, что да, это действительно циклы, и действительно незамкнутые! Это напомнило мне эффект «командирской заруки» из Пелевина<ref>«[http://books.rusf.ru/unzip/xussr_mr/pelevv03.htm?10/41 Чапаев и Пустота]»
| + | |
| − | <pre>
| + | |
| − | Он кивнул на притихшую площадь, над которой разносились слова Чапаева:
| + | |
| − | - Только бы дело свое не посрамить - то-то оно, дело-то!... Как есть
| + | |
| − | одному без другого никак не устоять... А ежели у вас кисель пойдет - какая
| + | |
| − | она будет война?.. Надо, значит, идти - вот и весь сказ, такая моя
| + | |
| − | командирская зарука... А сейчас комиссар говорить будет.
| + | |
| − | | + | |
| − | …
| + | |
| − | | + | |
| − | - О, до вас в этой области мне далеко. Кстати, не объясните ли вы,
| + | |
| − | что такое зарука?
| + | |
| − | - Как? - наморщился Чапаев.
| + | |
| − | - Зарука, - повторил я.
| + | |
| − | - Где это вы услыхали?
| + | |
| − | - Если я не ошибаюсь, вы сами только что говорили с трибуны о своей
| + | |
| − | командирской заруке.
| + | |
| − | - А, - улыбнулся Чапаев, - вот вы о чем. Знаете, Петр, когда
| + | |
| − | приходится говорить с массой, совершенно не важно, понимаешь ли сам
| + | |
| − | произносимые слова. Важно, чтобы их понимали другие. Нужно просто отразить
| + | |
| − | ожидания толпы. Некоторые достигают этого, изучая язык, на котором говорит
| + | |
| − | масса, а я предпочитаю действовать напрямую. Так что если вы хотите
| + | |
| − | узнать, что такое "зарука", вам надо спрашивать не у меня, а у тех, кто
| + | |
| − | стоит сейчас на площади.
| + | |
| − | </pre>
| + | |
| − | </ref>
| + | |
| − | | + | |
| − | == Не держать дела в голове! ==
| + | |
| − | Т.е. первое важнейшее утверждение — ни в коем случае не держать дела в голове, она не приспособлена для этого!
| + | |
| − | | + | |
| − | {{SideBar40|
| + | |
| − | ''В виду важности сообщений, Гени зафиксировал их в мозгу, с помощью специального приспособления, построенного на способности некоторых лучей бирадия *) раздражающе действовать на мозговые извилины и тем самым закреплять в памяти известные впечатления и мысли. Прием — известный очень немногим.'' [http://epizodsspace.airbase.ru/bibl/fant/muhanov/pylaush-bezdny/01.html ©]
| + | |
| − | }}
| + | |
| − | | + | |
| − | И дело тут не только в ограниченности кратковременной памяти («5±2», «4±1»), в скорее в механизмах функционировании долговременной памяти, когда единственным методом поддержания актуальности информации является принудительная перезагрузка информации о делах через кратковременную память, но в отличие от четко функционирующих механизмов DDR-памяти, мозг человека использует такую «шину» как центральная нервная система, и тупой болевой механизм, чтобы заставить «вспомнить все».
| + | |
| − | | + | |
| − | Начиная с некоторого, достаточно небольшого объема «висящих в памяти» задач возникает сплошной болевой фон — «аврал! ничего не успеваю! все пропало, гипс снимают, клиент уезжает», причем приоритезацию «это в 100 раз важней этого» мозг делать не может, и таким образом, либо какие-то мелочи семейной жизни глушат «мильонбаксовые» проблемы, либо получается рассеянный асоциальный тип, полностью в глобальных проблемах и абсолютно забывших об остальном.
| + | |
| − | | + | |
| − | Пока кибернизация и улучшения человеческой породы не произошло, можно использовать только концепции [[EnPedia:Extended Mind|Extended Mind]], т.е. использование внешнего хранения и приоритезации задач, осталось только понять, как именно это сделать эффективно, ибо к моменту написания книги (2000), уже были и календари-органайзеры, и электронная почта, и программы-календари, и даже программы проектного планирования, типа MS Project, но народ страдал по-прежнему, и было ощущение, что это не совсем то.
| + | |
| − | | + | |
| − | Т.е. и возникали связные вопросы «как это хранить и как это обрабатывать», и Аллен показал, что календарный подход, с жесткой привязкой сроков выполнения для задач, в не зависимости от того, сделал ли это человек (стандартная работа с календарями), или программа планирования (тот же MS Project) — это неоправданная жесткость, навязывание несуществующих ограничений.
| + | |
| − | Привязка к времени нужна очень редко, для моментов синхронизации (встречи, совещания, демонстрации), а для всего остального нужно использовать концепции теории массового обслуживания — очереди<ref>Напрямую он так не говорил, это мое творческое осмысление</ref>,
| + | |
| − | правило их формирования и обработки.
| + | |
| − | | + | |
| − | Т.е. все должно регистрироваться!
| + | |
| − | В одной или нескольких входящих очередях («корзинах», «inbox-ах» и т.п.).
| + | |
| − | | + | |
| − | Например, в качестве таких очередей у меня:
| + | |
| − | * Блокноты, когда я оффлайн (еду в транспорте, на совещании, и т.п.) — там я составляю списки или рисую майндмапы.
| + | |
| − | * Когда я «читаю интернет» — использую наш супермеханизм [[ВикиЗакладки/Справка|викизакладок]]. Одной [[Участник:StasFomin/Закладки|основной]], но и иногда для отдельных книг (отбор цитат) или задач — завожу отдельные.
| + | |
| − | * Иерархию личных вики-заметок [[Участник:StasFomin/Tasks]] — иерархический личный беклог, в который легко добавить новое, и очень просто регулярно актуализировать. Когда дело доходит до серьезной длительной работы — кодирование, взаимодействие с другими сотрудниками — тогда уже я завожу и баги.
| + | |
| − | * Очередь багов с «флагами-запросами» ко мне.
| + | |
| − | * Очередь новых задач на меня.
| + | |
| − | * Электронная почта (N-аккаунтов).
| + | |
| − | | + | |
| − | Да, тут есть проблема «что из этого главное» и «как синхронизировать».
| + | |
| − | ИМХО тут идеального решения в обозримое время не будет, с этим надо смирится и жить.
| + | |
| − | | + | |
| − | Так вот, тут я считаю, что абсолютная целостность не нужна, важно, чтобы было одностороннее движение проблем по очередям до момента их решения.
| + | |
| − | А основная технология односторонней синхрозации — copy-paste (плоский текст рулит), или вбивание руками.
| + | |
| − | | + | |
| − | {{note}} C слепой десятипальцевой печатью я печатаю быстрее, чем пишу рукой, и практически со скоростью мысли. Если вы задумались о повышении личной продуктивности, то это '''первое''', чему нужно научится. Если уж какие умения и инвентаризировать («грейды», «списки необходимых компетенций», «планы развития»), чтобы потом спрашивать с сотрудников — так вот, начинать нужно с этого — это просто, это легко верифицируемо, это общеполезно.
| + | |
| − | | + | |
| − | <graph>
| + | |
| − | digraph G{node [style=filled fillcolor=aliceblue shape=egg] edge[color=blue]
| + | |
| − | Выполнено [fillcolor="#666666" shape=box3d]
| + | |
| − | Блокноты -> Выполнено
| + | |
| − | Блокноты -> Викизаметки
| + | |
| − | Блокноты -> Bugzilla
| + | |
| − | | + | |
| − | Почты -> Выполнено
| + | |
| − | Почты -> "Почта (надо ответить)" -> Выполнено
| + | |
| − | Почты -> Викизаметки
| + | |
| − | Почты -> Bugzilla
| + | |
| − | | + | |
| − | Викизаметки -> Выполнено
| + | |
| − | Викизаметки -> Bugzilla
| + | |
| − | | + | |
| − | Bugzilla -> Выполнено
| + | |
| − | }
| + | |
| − | </graph>
| + | |
| − | Т.е. доехав до работы — я обрабабываю «очередь из блокнота», зачеркивая обработанное и даже вырывая листы. Также я помечаю «обработанную почту» или стираю «викизакладки» заводя соотвествующие баги.
| + | |
| − | | + | |
| − | Как обрабатывать «входящее» — следующая тема.
| + | |
| − | | + | |
| − | == Обработка «Входящих» ==
| + | |
| − | Ну во-первых, обработка должна быть.
| + | |
| − | Есть ибо есть «псевдоGTD»-подход — дело куда-нибудь записать («блокнот», «бумажка»), расслабится и потерять записанное.
| + | |
| − | Этого конечно надо избегать, и если записывать в «пассивных хранилища», то они должны быть там, где ты регулярно бродишь,
| + | |
| − | либо пользоваться «активными», которые сами могут напомнить о себе.
| + | |
| − | | + | |
| − | Ключевые слова, которых Девид Аллен не говорил, но которые должны быть понятны ITшникам, и которых за него скажу я → «сериализация» и «обход в ширину».
| + | |
| − | | + | |
| − | Обработка входящих дел должна быть '''последовательной'''.
| + | |
| − | | + | |
| − | Вне зависимости от внешней «важности», или внутреннего «интереса» к задаче.
| + | |
| − | Это помогает бороться с синдромом перфекциониста, когда человек, взяв одну задачу и
| + | |
| − | начав «раскапывать тему» зарывается в деталях, ответвлениях, связанных проблемах, при этом остальная его очередь простаивает нетронутой.
| + | |
| − | Сам автор называл этот процесс «стрижкой яка».
| + | |
| − | | + | |
| − | <graph>
| + | |
| − | digraph G{node [style=filled fillcolor="#ccffcc" shape=egg] edge[color=blue]
| + | |
| − | Задача1 [fillcolor=yellow]
| + | |
| − | Задача2 Задача3 Задача4
| + | |
| − | node [fillcolor=yellow]
| + | |
| − | Задача1->Подзадача11 [color=red]
| + | |
| − | Задача1->Подзадача12 [color=red]
| + | |
| − | Задача1->Подзадача13
| + | |
| − | Подзадача12->Подзадача121
| + | |
| − | Подзадача12->Риск122
| + | |
| − | Подзадача12->СвязаннаяТема123 [color=red]
| + | |
| − | СвязаннаяТема123 -> СвязаннаяТема1231 [color=red]
| + | |
| − | СвязаннаяТема123 -> СвязаннаяТема1232 [color=red]
| + | |
| − | }
| + | |
| − | </graph>
| + | |
| − | | + | |
| − | Также неправильно выбирать задачи для обработки случайно или эвристично — тогда с высокой вероятностью, что-то важное тоже может неограниченно долго валятся без внимания.
| + | |
| − | | + | |
| − | Только последовательное рассмотрение новых задач из входящих, решение легких вопросов на месте и сходу, и диспетчеризация остальных вопросов в очереди по приоритетам, направлениям, и исполнителям.
| + | |
| − | | + | |
| − | Технически, на примере [[Bugzilla]], для нас это означает, что по крайней мере ежедневно вам нужно сначала пройтись по запросам-вопросам «RequestsToMe», и ответить на все из них (если что-то сложное — надо клонировать блокирующий баг и начинать исследование), затем, рассмотреть все баги из категории «NEW», и либо взять их на себя, определив их «очередь» заданием продукта-приоритета-важности и т.п., либо перенаправив по адресу.
| + | |
| − | Ибо иначе, вы оказываетесь вольным или невольным виновником блокировки других задач и сотрудников. И собственно, чтобы такого не случилось, мы запускаем снова встроенный механизм «нытья» в Bugzilla, когда она будет напоминать о нерассмотренных багах в состоянии «NEW», о неотвеченных флагах-вопросах, о полузабытых багах в состоянии «RESOLVED LATER».
| + | |
| − | ({{BugInfo|54794}}, {{BugInfo|65403}})
| + | |
| − | | + | |
| − | «Решение сходу» — тоже важный момент, ибо если накладные расходы на рассмотрение (открыли баг, прочитали, осознали) сравнимы с временем на ее решение — глупо откладывать решение и повторять расходы на загрузку в голову контекста задачи.
| + | |
| − | Автор говорит о «двух минутах» — но это время связанное с выборкой из папок и чтением обычного листа бумаги, так что «две минуты» — это не догма, это зависит от класса задач и используемых инструментов.
| + | |
| − | | + | |
| − | Что же такое рассмотрение задачи и какова должна быть его глубина (время на анализ)?
| + | |
| − | Тут как раз применяется техника «поиска в глубину», можно даже сказать «с отсечением ветвей и границ», чтобы быстро определить первый, «листовой» шаг по задаче, для того, чтобы возможно, обнаружить, что он зависит от других людей или организаций и вовсе заблокирован чем-то еще — и обраружив это, сходу запустить процесс разблокирования (позвонить кому-то, узнать что-то, поставить подзадачу, заказать что-то из штатов и т.п.), и переключится на другие, незаблокированные задачи.
| + | |
| − | | + | |
| − | <graph>
| + | |
| − | digraph G{node [style=filled fillcolor="#ccffcc" shape=egg] edge[color=blue]
| + | |
| − | Задача1 [fillcolor=yellow]
| + | |
| − | Задача2 Задача3 Задача4
| + | |
| − | | + | |
| − | Задача1->Подзадача11 [color=red]
| + | |
| − | Подзадача11->Подзадача111 [label="работаем"]
| + | |
| − | | + | |
| − | Задача2->Подзадача21->Подзадача211 [label="можно начинать"]
| + | |
| − | | + | |
| − | Подзадача311 [fillcolor="red"]
| + | |
| − | Задача3->Подзадача31->Подзадача311 [label="надо разблокировать"]
| + | |
| − | }
| + | |
| − | </graph>
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | И обратите внимание, все это опять таки бьет PUSH-парадигму (на вас упала задача, вы прервались и бросились ее делать), заменяя ее PULL — вы «вошли в поток», и спокойно и последовательно «тащите» из очереди задачи.
| + | |
| − | | + | |
| − | Ну и если что-то осталось таки непонятным → разные варианты схем «GTD-workflow» можно найти в инете, например даже в [[RuPedia:Getting Things Done#Обработка|в википедии]].
| + | |
| − | | + | |
| − | == Хранение дел ==
| + | |
| − | Тут автор делает крутой ход — вместо того, чтобы описать «идеальный трекер задач» или наоборот, как использовать распространенные программы и сервисы, чтобы было ОК, делает ход конем, и описывает «бумажную багзиллу» — систему очередей задач «43 папки» (12 месячных и 31 дневная папка ).
| + | |
| − | Ну что же, это можно послушать, посмеятся, хотя может быть для организации домашнего делопроизводства с использованием жены и детей, будет ОК.
| + | |
| − | | + | |
| − | Впрочем, там был важный совет — системы бумажного хранения — не реляционная база, с произвольным доступам по разным индексам, тут надо сразу определиться, классифицируем мы информацию по темам, алфавиту или датам. С этим я безусловно согласен — все помнят, какой ужас являют собой
| + | |
| − | технологии стандартных библиотек с их громоздкими картотеками, и никому это не нужно для хранения счетов или чеков.
| + | |
| − | | + | |
| − | Лично я, для хранения всяких чеков склонился к простому, хронологическому подходу (папки по годам), остальное — full table scan.
| + | |
| − | | + | |
| − | == Инфографическая схема ==
| + | |
| − | Для любителей плакатов — [http://wiki.office.custis.ru/wiki/images/5/53/GTD-Scheme.png распечатай и повесь на стену].
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | ----
| + | |
| − | <references/>
| + | |
| − | | + | |
| − | {{replicate-from-custiswiki-to-4intranet}}
| + | |
| − | {{wl-publish: 2010-07-21 17:45:25 +0400 | StasFomin }}
| + | |
