Цитата сообщения rss_rss_hh_new Прочь из моей головы. GTD в разработке

Если на вашем столе стоит чашка остывшего желанного кофе или чая, значит, что-то не так. Во всяком случае, так наверняка подумал бы Дэвид Аллен, автор знаменитого метода GTD (Getting Things Done). Мы хватаемся за тысячу дел, пытаясь попутно не забыть про бытовые мелочи, часто забываем о цели, но помним о неотвратимо приближающихся дедлайнах. Порой страх перед лавиной задач буквально парализует мозг и наступают апатия, прокрастинация, депрессия. Работа в такие моменты движется медленно, кажется, даже курсор мыши еле ползёт по монитору. Такая ситуация тем опаснее, чем больше человек работает в команде, особенно, если речь идёт о команде разработчиков.



Идея пригласить на нашу конференцию GeekWeek-2015 Дэвида Аллена была хоть и неожиданной, но неслучайной. Личностная, на первый взгляд, концепция GTD, даёт неплохие рекомендации для каждого разработчика в отдельности и процесса разработки в целом. Конечно, метод GTD не столь «заточен» под процесс разработки ПО, как agile, но тем не менее, способен его дополнить или стать первым шагом на пути перехода команды к гибкой методологии разработки. Какой же он, GTD для программиста?

Разделим применение принципов GTD в разработке на два блока: персональный, когда речь идёт об отдельном человеке, и командный, когда речь идёт о компании или группе разработчиков. В целом, принципы едины, но в команде их реализовать гораздо сложнее, поскольку гарантированно будут саботаж и сопротивление со стороны работников или тимлида.

Один в поле воин

Одна из основ метода GTD — принцип перемещения задач из памяти человека на внешний источник. Таким образом, мозг человека перестаёт заботиться о том, чтобы удержать в голове все планы, от незначительных до глобальных, а начинает концентрироваться на действительно важных на данный момент задачах и их выполнении. Кто-то говорит, что метод GTD эффективно использовать для высвобождения личного пространства и нахождения баланса между работой и, например, хобби или семьёй. Однако с точки зрения практичного разработчика GTD нужен, прежде всего, для соблюдения баланса между работой и… работой.

Программисты, системные архитекторы и менеджеры проектов непрерывно находятся в рамках нескольких приоритетов, задач или проектов. Часто обстоятельства исключают ведение одной задачи, поэтому нужно уметь быстро перестраиваться. Подобное метание от проекта к проекту нередко порождает стресс, но не тот, который возникает от нелюбимой работы, а стресс как физиологическое и эмоциональное явление. Чем выше уровень тревоги, тем сложнее справляться с поставленными задачами. Тут-то на помощь и приходит GTD.

Устанавливаем фильтры на список дел

Прежде всего, нужно установить ограничения, выбрав основное среди всех задач. Оставляя главное, вы высвобождаете время и силы и создаёте импульс для действий с гораздо меньшими трудозатратами, чем когда вы держите в голове все мелочи. Есть рутина, есть важные проекты, есть планы на будущее. При этом во всех перечисленных категориях есть главное. Чтобы его выделить, нужно выполнить несколько шагов:

• выбрать начатые, но не завершённые задачи;
• выбрать дела, вызывающие наибольшее беспокойство;
• выбрать дела, которые не хочется выполнять и которые всё время откладываются;
• выбрать рутинные дела, в том числе бытовые.

Как правило, основное находится первых трёх группах. Соответственно, первоочередное внимание следует уделить беспокоящим и незавершённым делам — ведь не даром точный перевод Getting Things Done — «довести дела до завершения».

Упорядочиваем коммуникацию

Неважно, фрилансер или программист, работает удалённо или в команде, он постоянно находится в поле коммуникации: звонки заказчиков, вопросы руководства, запросы пользователей и коллег, информационные сообщения от поставщиков SDK и проч… Эти коммуникации нельзя назвать малозначительными, но их нужно уметь грамотно обрабатывать.

• Перестаньте проверять e-mail каждые 5 минут — установите всплывающие оповещения, на которые можно глянуть краем глаза. Разместите почту по папкам и прочитывайте по мере актуализации в конкретный момент.
  
  
• Разделите все коммуникации по контексту: Skype, мобильные звонки, городской телефон, общение через почту и т.д… Отведите определённое время на коммуникацию внутри каждого канала.
  
  
• Проверьте рабочие и личные чаты. Возможно, если вам без конца пишет ваш новый сотрудник или задаёт одни и те же рабочие вопросы старый коллега, стоит попросить их подготовить вопросы, выделить время на общение и разъяснить все сложные моменты.
  
  
• Понаблюдайте за своим веб-браузером. Разработчики часто смотрят профильные темы на форумах или специализированных сайтах. Там их подстерегают интересные темы и обсуждения, не имеющие никакого отношения к текущей задаче. Лучше отложить чтение действительно интересной темы, воспользовавшись закладками в браузере или специальными утилитами для хранения ссылок (например, дополнение Pocket, которое можно также установить как приложение на мобильном устройстве и синхронизировать закладки).
  
  
• Заведите записную книжку и/или приложение, где вы будете записывать все задачи с метками срочности и важности. GTD для управления делами вводит понятия времени, контекста (места), действия. Чтобы правильно расставить приоритеты задач, представьте себе простой фильтр, как в Excel, например. Присвойте каждой задаче параметр времени (по часам или времени суток), места (дом, работа, улица, спортзал, магазин и т.д.). А затем разделите задачи примерно таким образом: «запросить комментарии к ТЗ — работа — 14:00» или «позвонить в шиномонтаж — улица — вечер». Для подобных записей существует много приложений: от планировщика заданий в Windows, который можно использовать для своих целей до Evernote, Rainlendar и тщательно прописанных напоминаний на смартфоне.

Уверенность в том, что у вас есть такой список, гарантированно снизит уровень тревожности и поможет сосредоточиться на решении каждой из задач.

Есть и более глобальная проблема, которая также затрагивает разработчиков любого типа занятости. Сегодня почти каждую неделю выходят новые инструменты, гайды, утилиты для разработчиков, то и дело появляются сообщения о новых версиях фреймворков, новых библиотеках и даже новых языках программирования. Вся эта информация вызывает чрезвычайный интерес профессионалов, а иногда даже увлекает и заставляет попробовать что-то новое (создать простое мобильное приложение, написать «Hello, world!» на Brainfuck или собрать новый опенсорсный проект). Выход один: распределять интересы по мере их значимости по отношению к текущим проектам, краткосрочным и долгосрочным целям. Фокусировка на одной задаче даёт возможность повысить личную продуктивность, освободить время и приступить к изучению новой информации.

5 шагов оптимизации

Метод GTD выделяет пять стадий работы над списком дел.

Сбор информации. Нужно собрать все задачи— просто взять и записать ручкой или в текстовый файл все свои рутинные, незавершённые, глобальные дела. При этом важно помнить, что, например, за задачей «Написать отчёт в Fast Report для ООО «Снеговик» скрывается несколько важных и требующих внимания подзадач: собрать требования с клиента, составить и утвердить ТЗ, запросить массив данных для тестирования отчёта и т.д… Необходимо записывать абсолютно все задачи — чуть позже вы их сгруппируете.
Обратите внимание не только на те проекты, которые есть в памяти, но и на те, которые находятся в компьютере — зачастую там не меньше хаоса, чем в мыслях. Стоит разделить файлы по папкам, соответствующим каждому проекту, отделить личные документы от рабочих.

Процесс обработки. Обработайте информацию по схеме, предложенной GTD: если что-то уже исполняется, нужно продолжить дело до конца, если можно сделать менее, чем за две минуты, сделайте сразу.


Классический алгоритм обработки по GTD

С точки зрения работы над ключевым для вас проектом важно учесть несколько нюансов.

• Отложить несрочные задачи, например, изучение непрофильных материалов, никак не связанных с текущей работой.
  
  
• По возможности делегировать задачи, например, коллегам или фрилансерам. Если вы быстро и эффективно пишете код, но не очень хорошо справляетесь с задачами создания сайта, рекламы или дизайна, обратитесь к профессионалам. Даже, если это ваш собственный проект, вложение в чужую качественную работу быстро окупится.
  
  
• Научиться говорить «нет». Это, пожалуй, один из самых сложных навыков: всегда найдутся десятки знакомых, у которых слетела Windows, закралась ошибка в код, требует прошивки Android и молит о джейлбрейке iPhone. Эти небольшие задачи отнимают массу времени. Если не хотите портить отношения, найдите несколько доступных мануалов в Сети и отправляйте страждущим ссылки.

Организация списка. После того, как пройдены два первых и самых сложных этапа, необходимо организовать работу с задачами. Тут можно воспользоваться простым правилом: разделить время на недели, в конце недели пересматривать список и создавать новый. Все задачи стоит разделять по срокам выполнения и приоритету. Для ведения задач можно использовать любое из понравившихся приложений: это и мобильные OneNote и Evernote, и Asana, и Redmine, и Google Календарь, и проч…

На этом этапе главное — уделить много внимания работе с текущим или несколькими проектами. Для этого можно воспользоваться ассоциативными картами (mindmap), которые отразят все этапы работы в виде наглядной структуры-карты, в соответствии с которой вы будете продвигаться по проекту. Для создания mindmap существует множество платных и бесплатных приложений с интересными фичами. Нам нравится удобный, бесплатный и русифицированный Freemind, в котором мы и создали примерный вид незавершённой карты, не претендующей на истину:



Часть 1



Часть 2

Не стоит делить задачи на простые и сложные, нужно выполнять всё по порядку, тогда и время будет распределено рационально.

Ревизия сделанного. На этом этапе необходимо отметить сделанное, проанализировать причины провалов, создать план на следующий этап (например, неделю).

Собственно действие. Выполнять задачи следует исходя из наличных ресурсов: сил, времени, места выполнения, а также установленного приоритета. Если для быстрого решения задачи вам не хватает какого-то ресурса, который появится позже, постарайтесь перенести задачу на момент появления средства её лучшего исполнения. Например, если вы занимаетесь доработкой десктопного приложения и для внесения части изменений требуется обновлённая и ещё не купленная вашей компанией, но запланированная к покупке в ближайшее время SDK, вносите те изменения, которые можно сделать в текущей версии, а задачу по остальным изменениям внесите в папку или файл с задачами на будущее. Безусловно, поиск путей решения задачи имеющимися средствами раскрывает вас как профессионала, но требует больших и не всегда оправданных затрат вашего времени и сил.

Вот несколько советов, как использовать принципы GTD, если вы разработчик в команде или работаете самостоятельно.

• Планируйте свой проект изначально, а не по ходу работы, дробите его на решаемые подзадачи.
  
  
• Выделяйте отдельные этапы работы над проектом и проставляйте метки важности и срочности выполнения работы.
  
  
• Доводите каждую задачу до конца, не оставляя её на потом. Даже, если вы знаете только длинный путь решения задачи, решите её. В ходе дальнейшего рефакторинга можно будет избавиться от неоптимального решения.
  
  
• Периодически пересматривайте списки задач с целью ревизии выполненного и изменения планов.
  
  
• В один момент времени сосредоточьтесь на одной задаче — так вы сэкономите время и силы.
  
  
• Выделяйте время на каждый этап и уделяйте ему максимальное внимание: на сбор требований, на разработку, на unit-тестирование и проч..

GTD нельзя внедрить одним днём — сперва появляются какие-то отдельные элементы, затем формируются правила, наконец, появляется привычка и ощутимый результат. Главное — не останавливаться. Кстати, неплохо, если вы сможете перенести часть своих навыков в GTD на команду, с которой работаете — это может значительно оптимизировать работу внутри компании.

Один в поле не воин

Несмотря на то, что GTD, как правило, нацелен на отдельного человека, он применим и к команде, в которой важно уметь определить видение проекта, цели, обозначить проекты и распределить зоны ответственности. Тем более, что во многих организациях уже существует и успешно используется, пожалуй, самая близкая к логике GTD сущность — диаграмма Ганта. Диаграмма Ганта очень точно отражает потребность проекта в ресурсах, задачи и подзадачи, примерное время выполнения каждой задачи, даты старта и окончания работ по задаче, этапы выполнения проекта, которые могут стартовать только после окончания предыдущего этапа и высвобождения требуемых ресурсов.

Однако зачастую все труды по составлению диаграммы ресурсов и занятости оказываются напрасными. Увязывая GTD с разработкой ПО, о диаграмме Ганта отлично написал Роберт Пик, евангелист GTD и CTO консалтинговой компании Дэвида Аллена, который руководил техническими проектами и понимает тему едва ли хуже самого CEO:

«Я видел столько времени, энергии и денег, канувших в сложные диаграммы Ганта, которые были уничтожены по первому щелчку пальцев руководителя. Любую компанию, делающую ставку на АВС-коды приоритетов и жёсткие узды для программистов для того, чтобы остаться в арьергарде разработки ПО, ждёт горькое разочарование».

Он же раскрывает суть концепции. Дело в том, что она направлена не столько на планирование, сколько на умение вернуться к точке срыва. Поясним подробнее. В жизни любого человека и любой команды случаются моменты, когда они отходят от намеченных целей и вся деятельность погружается в хаос. Это может происходить как по внешним причинам, так и по причинам, связанным с отдельными внутренними воздействиями: временной сменой курса развития проекта, появлением нового инвестора с новым видением, перерывом на сверхсрочную работу (например, подготовку к выставке). Задача GTD в команде — легко вернуться к точке, в которой пришлось отойти от плана работы и продолжить действовать в прежнем режиме.

«Mind sweep (очистка памяти, очистка ума — прим. пер.) составляющая GTD, достаточно проста, Дэвид (Аллен — прим.пер.) зачастую упоминает её как своего рода дамп памяти для «психической оперативки». Это как будто вы периодически сверяетесь со своим собственным мозгом, чтобы увидеть то, что удерживает ваше внимание, вытащить и посмотреть на это. Это как будто вы собираете эти списки возможностей (проекты и следующие действия), которые служат вам подстраховкой для уверенности в том, что всё, что вы делаете, вы делаете правильно и в сочетании с правилом двух минут (если ты можешь что-то сделать менее, чем за 2 минуты, сделай это — прим. пер.) и мышлением, нацеленным на следующее действие, даёт вам статический слепок вашего рабочего состояния, с помощью которого вы сможете легко вернуться к тому моменту, когда вы прервались».

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

1. Регрессионное тестирование — тестируются уже исправленные участки исходного кода, а также работоспособность функциональности, связанной с изменённым кодом. Как часть экстремального программирования, оно иллюстрирует GTD с точки зрения повторяемости, ревизии и однозначности действий.
   
   
2. Работа с документацией — создание и тестирование документации позволяет как раз перенести важные знания и задачи на бумагу. Их не нужно держать в голове ни пользователям, ни тестировщикам, ни разработчикам — в случае необходимости можно обратиться к документации и уточнить неясный момент или найти ответ на вопрос о работе программы.
   
   
3. Рефакторинг кода — процесс улучшения кода без изменения функциональности. Приверженцы экстремального программирования проводят периодический рефакторинг с целью улучшения производительности программы, её понимания и читабельности кода. Есть компании и команды, которые избегают рефакторинга. В большинстве случаев это связано с опасениями, что изменения в коде приведут к краху в в системе. Как правило, такой подход приводит к косности и устареванию программы.
   
   
4. Мозговой штурм. Процесс, который в той или иной форме происходит в любой команде. Это как раз сбор информации и идей. В ходе мозгового штурма и по его итогам могут также создаваться ассоциативные карты mindmap.

В большинстве случаев программист на работе выполняет гораздо больше задач, чем обычное написание кода. Более того, чем больше у него опыта и квалификации, тем больше разнородных задач на него возлагается. В какой-то момент наступает кризис, когда обязанности и обязательства начинают тяготить работника и значительно снижают его продуктивность. Очевидно, что с этим можно и нужно бороться, причём не директивными методами и репрессивными мерами, а с помощью GTD, который нацелен на эволюционное изменение подхода к работе. Многочисленные отзывы тех, кто пробовал этот метод, рассказывают о значительных сложностях в начале и не менее значительных успехах в итоге процесса. В конце концов, говорят, что привычка формируется за 21 день. Почему бы не попробовать?

P.S.: Бесплатно послушать онлайн-выступление автора метода GTD Дэвида Аллена и задать ему вопросы можно будет в рамках конференции GeekWeek-2015

http://habrahabr.ru/post/270865/