Клаузевиц об эджайле :)

Немецкий военный мыслитель XIX века Карл Клаузевиц в своем классическом труде "О войне" затрагивает вопрос, как бы сейчас сказали, развития военной компетенции. Приведу две цитаты:

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

"Все на войне очень просто, но эта простота представляет трудности. Последние, накопляясь, вызывают такое трение, о котором человек, не видавший войны, не может иметь правильного понятия... под влиянием бесчисленных мелких обстоятельств, которых письменно излагать не стоит, на войне все снижается, и человек далеко отстает от намеченной цели... Военная машина - армия и все что к ней относится, - в основе своей чрезвычайно проста, и потому кажется, что ею легко управлять. Но вспомним, что ни одна из ее частей не сделана из целого куска; все решительно составлено из отдельных индивидов, из которых каждый испытывает трение по всем направлениям… Это ужасное трение, которое не может, как в механике, быть сосредоточено в немногих пунктах, всюду приходит в соприкосновение со случайностью и вызывает явления, которых заранее учесть невозможно, так как они по большей части случайны." 

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

Добиться этого навыка сложнее, чем изучить принципы agile или какие-либо другие принципы. Поэтому людей, которые понимают эджайл больше чем тех, которые его умеют. Иногда кажется, что последних даже меньше чем тех, кто учит эджайлу ;)

О вредных привычках

В заключение своего небольшого цикла заметок (1, 2, 3) хочу рассказать о том, как я боролся с вредными привычками. Вредные привычки бывают самые разные: курение, алкоголь, ковыряние в носу пальцем (ринотиллексомания), и так далее. Есть и вредные информационные привычки: доведенные до автоматизма шаблоны поведения, направленные на получение информации. Конечно же я говорю, в первую очередь, о трате рабочего в времени на веб-серфинг, социальные сети, чатики.

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

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

Когда я осознал свою проблему, я попытался сначала решить её в лоб: мощным волевым усилием фокусировал своё внимание на работе и всячески избегал нерабочего интернета. Однако эта прямая стратегия совсем не принесла результата (моё почтение, сэр Лиддел Гарт), да я и не могу похвастаться особой силой воли :)

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

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

Это сработало. Трата времени на нерабочий интернет сократилась почти до нуля. Примерно через два месяца я не нуждался уже в этих костылях и подпорках, хотя сохранил их.

Об обработке прерываний:

В предшествующих заметках (первая, вторая) я рассказал о том, как я осознал некоторые свои проблемы, мешавшие мне эффективно работать, и начал их решать. Недостаток навыков в планировании своей работы и управлении вниманием был, можно сказать, моей внутренней проблемой. Теперь я хочу рассказать о том, как научился справляться  с внешней проблемой, которая мешает работать: прерываниями от окружения.

Это проблема, я думаю, известна всем: "только начнёшь работать, тут же будят" :) Если серьёзно, то я говорю о том, что входящие запросы сильно мешают сфокусироваться на задаче, которая того требует, поддерживать режим потока. Причина этого, опять же, кроется в трудностях переключения контекста. Когда приходит какой-то запрос, которые требует чего-то более нетривиального, чем устный ответ на короткий вопрос, ответ на которые уже есть в голове, необходимо перезагружать мозг, а это дорогая операция. Естественное нежелание это делать приводит иногда к забавным эффектам: синдрому смещенной активности или же к желанию разобраться с входящим запросом по принципу "лишь бы отстали и не мешали делать своё дело".

Рис.1 О синдроме смещённой активности

Основная причина моих бед состояла в том, что я всегда начинал беспокоиться о входящей проблеме сразу: просящие люди обычно не говорят, что их проблема может подождать :) Да и я иногда боялся отложить проблему, опасаясь забыть о ней. 

Решение нашлось в умении правильно откладывать делать на потом:

во-первых, необходимо всегда очень придирчиво прояснять срочность оказалось, что "здесь и сейчас" нужно делать совсем немного (хотя сначала многие любят свои проблемы преподносить как срочные);

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

В итоге большинство прерываний удалось свести к простой и, что главное, не требующей перезагрузки мозга, операции - создании записи "на будущее", после чего я полностью выбрасывал новость из головы и продолжал заниматься своим делом. 

Накопленные записи регулярно (как правило - на следующее утро) просматриваются, анализируются по всем правилам problem-solving`а и трансформируются в "actionable item`ы", идущие в работу в общем порядке. 

О правильном ToDo-list

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

Когда я начал составлять себе такие списки, я быстро столкнулся c такой проблемой: некоторые задачи постоянно откладывались на будущее. Причем, это были не только какие-то неважные задачи, многие важные задачи тоже я тоже постоянно отодвигал на будущее ("синдром студента").

Дэвид Аллен, автор книги "Getting things done", описывает понятие "actionable item" - это такая постановка задачи, которая обладает следующими свойствами:
1. Достаточно конкретна, чтобы быть исполненной без дополнительного планирования.
2. Для неё выполнены все предварительные условия.
3. Находится в пределах возможностей исполнителя.

Моей типичной ошибкой было занести себе в список дел запись типа "Тесты!" или "Рефакторинг". Или даже "Реализовать функционал". Беда с такими абстрактными постановками задач заключается в том, что для их исполнения необходимо сначала переключиться в режим планирования и конкретизировать задачу, а такое переключение - очень дорогая операция. Мой не слишком трудолюбивый мозг очень сильно сопротивляется таким переключениям, особенно во второй половине дня. Чтобы снизить количество таких переключений, я научился прорабатывать задачи до нужного уровня конкретики на этапе составления и/или пересмотра списка задач. Лучше всего у меня это получается делать утром, когда голова свежая и не замусоренная. Например, если я планировал за день сделать две задачи из рабочего task-tracker`а, я утром анализировал их и составлял для них достаточно подробные списки, которые потом исполнял в течение дня.

Другой ошибкой, которую я часто совершал, являлось неполное разбиение. Например, я брал в работу некоторое требование или брался решать проблему, но составлял ToDo-list, который охватывал лишь часть необходимых работ. Как правило я заносил в список те работы, которые были мне очевидны в тот момент. Проблемой это становилось потому, я забывал пересмотреть объем работ и считал законченной работу, которая ещё не была завершена. В итоге я научился делать полное разбиение задачи на подзадачи. Даже если вначале не было возможности заранее всё продумать и получить подробный work breakdown structure по задаче, я просто оставлял в конце списка специальную запись-терминатор, которая означала: "проверить достаточность проделанной работы и, если надо, запланируй ещё".

Наконец, третьей проблемой стало накопление в списках дел всякого рода мусора. Как правило это были разного рода дела, которые я занес в списки дел из лучших побуждений, но которые не имели достаточного "веса" или важности. Проблемой это стало тогда, когда действительно важные дела стали теряться на среди подобного рода "дел". Это привело меня к простому правилу: если дело "висело" не сделанным достаточно долго и это не привело ни к каким плохим последствиям, то его можно спокойно выбросить из списка. По-началу я пытался складывать их в некий список "на будущее", но вскоре убедился, что этот список не приносит никакой пользы.

Итого, в качестве базы своего метода управления списками дел я применяю следующие правила:
1. Каждое утро я планирую свои задачи, добиваясь при это того, чтобы все записи были "actionble item".
2. При взятии в работу любой крупной задачи я произвожу полное разбиение её на подзадачи.
3. Регулярно освобождаю списки дел от мусора - тех записей, которые когда-то показались мне актуальными, но потеряли актуальность со временем.

Эти правила помогли мне существенно повысить эффективность и качество моей работы.

Опыт развития навыков самоуправления

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

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

Во-первых, моя усталость удивительным образом была обратно пропорциональна тому, насколько продуктивным и успешным выдался день. Чем лучше я работал в течение дня, тем бодрее и свежее я был вечером. Напротив, те дни, когда я "разряжался в ноль", у меня ничего толком не получалось сделать: я все время тратил на какую-то ужасно непродуктивную суету или на интернет.

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

В-третьих, поскольку я планировал не сознательно, а интуитивно, хорошо спланированные задачи у меня получались или не получались случайно.

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

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

Во-вторых, исполнению плана постоянно мешало окружение: мои коллеги и руководство с завидным постоянством приходили ко мне и отвлекали от работы по составленному утром плану.

В-третьих, рука всё равно постоянно тянулась к браузеру.

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

Первое сообщение

Это моё первое сообщение в этом блоге. 

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

В определенном смысле это эксперимент, так как в блогах я ещё новичок. Надеюсь на вашу помощь и критику.

Удачного вам дня :)