Все события выдуманы, все совпадения случайны.... ли?

Однажды директор судостроительного завода собирает сотрудников в актовом зале и делает объявление: "К нам обратился очень солидный клиент, он хочет заказать у нас постройку шикарного лайнера. Мы должны построить самый лучший лайнер в своем классе: непотопляемый, с непревзойденным уровнем комфорта для пассажиров и экипажа, быстрый и экономичный. У нас  есть год на то, чтобы построить судно и передать его новому владельцу."

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

В ходе прояснения статуса готовности выясняется, что
1. Нос и корма не стыкуются друг с другом.
2. Про центральную часть вообще забыли.
3. Дизель запускали только на холостых, и работает он минут двадцать максимум, так как вытекает всё масло.
4. В грузовой отсек помещается лишь один чемодан, хотя планируется возить двести пассажиров.

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

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

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

Mindmap++: как я собираю мысли в кучу

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

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

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

Сейчас достаточно широко известны методы визуализации конечного результата. Например, UML предлагает множество видов диаграмм, описывающих разные аспекты разрабатываемой системы. Так же известны методы рисования наших мыслей: разного рода mind maps, семантические сети и тому подобное. Следующий шаг визуализации - объединить несколько видов разнотипной информации на одной диаграмме, чтобы наглядно представить связи между разрабатываемой системой, планом её реализации и процессом планирования.

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

Изначальный набросок разрабатываемой системы

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

Набросок системы, "нагруженный" mind map`ом

Здесь голубым помечены запланированные задачи, желтым - вопросы для прояснения, красным - известные риски и проблемы. Из голубых заметок формируется бэклог работ по реализации. Из желтых и красных - бэклог работ по составлению бэклога реализации (чувствуете рекурсию? :)). Первый идёт в task tracker, второй - в личные списки дел. После того, как некоторые работы выполнены, диаграмма обновляется: какие-то вопросы и задачи уходят, новая информация добавляется. Например, были сняты некоторые вопросы по разрабатываемому приложению:

Диаграмма после первой итерации работ по уточнению

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

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

Главным недостатком метода является ограниченность масштаба. По достижении некоторого количества визуальных элементов диаграмма перестаёт читаться. Из-за этого я применяю этот метод для планирования "в малом". Целый проект в подробностях так не нарисуешь, а отдельную пользовательскую историю (пусть и крупную) - вполне. Отсюда и короткий жизненный цикл этого артефакта в реальном применении.

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

Процессные астронавты (небольшая зарисовка из жизни)

Дожэль Спольски как-то писал про архитектурных астронавтов. В глубинах IT-шного космоса у них есть братья по разуму - процессные астронавты.

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

К сожалению, это было ровно, чем мы тогда занимались. Например, мы упорно придумывали и воплощали в жизнь Процесс Обработки Заявок Клиентов (всех полутора, ага), который включал в себя портал на Microsoft Sharepoint, проект в TFS и весьма вычурный регламент, объединяющий их в единое целое. Мы сами так и не научились по нему нормально работать, но достаточно настырно пытались заставить полтора наших внутренних клиента работать по этому Процессу. Клиенты, и так не фонтанировавших лояльностью, а тут ещё мы со своим Процессом.

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

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

Насколько я могу судить, это явление достаточно распространено в нашей индустрии. Только в одном и пяти мест моей работы я не столкнулся с его проявлением. Я пока не готов сказать, как с бороться с этим в себе и в других. Когда-нибудь я достигну просветления и напишу об этом.

"Решение без проблемы", или история одного требования

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

Пытаясь восполнить пробел в информации я стал задавать Product Owner`у вопросы, призванные прояснить конечную цель требуемой функции программы. Вот тут-то и начались проблемы, которых я не ожидал: диалог с Product Owner`ом у меня совсем не клеился. Я пытался узнать, зачем ему эта функция, какую проблему он хочет решить. Он же отвечал мне совсем на другой вопрос: что именно должна делать функция, какой отчёт он хочет увидеть и так далее. Это было весьма трудное общение, осложнённое тем, что поймать его было не так-то просто и он не горел желанием тратить много времени на обсуждение этого требования. Более того, его явно раздражала моя настырность и мои вопросы.

Признаться честно, в определённый момент я просто сдался. Решил, что я, наверное, зря пристаю к человеку и выдумываю на ровном месте какие-то сложности. "Надо просто взять и сделать" (с).  Закончилось это так: демонстрация нашей разработки была проведена практически "на бегу", после чего прошло уже полгода, а ей так НИ РАЗУ и не воспользовались.

Сухой осадок: выброшенные на ветер деньги и испорченное от осознания бесполезности проделанной работы настроение.

Почему так получилось? Я вижу две причины:

1. Product Owner, видимо, сам не понимал, зачем ему нужна эта функция в программе. Такое часто бывает, что люди делают что-то просто так, без чёткого осознания связи своих действий со своими целями и проблемами. Видимо, PO попался в эту же ловушку и сделал свою работу некачественно. Грубо говоря, принёс вместо требования bullshit.
2. Я согласился взять в работу требование без внятного понимания его цели и решаемой проблемы. Грубо говоря, я пропустил bullshit "сверху" в свою команду, не добился того, чтобы входящее требование соответствовало определённому стандарту качества. 

Мораль этой истории состоит в том, что ошибки совершенные "сверху по потоку" запросто приводят к тому, что вся дальнейшая работа становится бесполезной. Garbage in, garbage out. Чтобы защититься от некачественных данных на входе и, тем самым, обеспечить качественный результат на выходе, недостаточно быть просто умным и понимающим - надо обладать определённой твёрдостью и упрямством. Слишком мягкий человек, даже понимая, что он прав, рискует согласиться с плохим решением, просто чтобы не вступать в конфликт с коллегами.

Карьерный рост и бонусы в свете теории ограничений

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

Чему нас учит теория ограничений Голдратта? Если в двух словах, то тому, что пропускная способность производственной системы определяется её самым слабым звеном (сиречь, ограничением). Практическое следствие из этого состоит в том, что оптимизация того, что не является ограничением системы, не приведёт к повышению пропускной способности и не имеет смысла.

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

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

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

Не слишком серьёзные размышления о нашей тяге к разработке платформ

Данное сообщение изначально было размещено мною на сайте RSDN в разделе "философия программирования". 

"Что делают программисты, когда собираются вместе? Правильно — пишут фреймворк"
(с) Волков, Танки Онлайн, неточная цитата.

Я неоднократно видел одну и ту же ситуацию — вместо разработки решения для конкретной бизнес-задачи команда начинает пилить обобщенное техническое решение, платформу или каркас. Обычно это подается под соусом снижения затрат на будущие разработки, дескать, сейчас "наработаем технологию" (или даже "наработаем архитектуру"), а потом на ее основе за три дня слепим конечный продукт. А потом и еще десяток, если надо будет.

Я лично участвовал в пяти проектах, которые развивались по этой схеме. Вот результаты:
1. Три полностью провалились (т.е. были отменены после того, как сожрали изрядно денег и не дали никакого полезного результата). 
2. Один еле вытащили до состояния shippable-продукта (т.е. все обещанные плюшки от разработки платформы пошли лесом, оставив переусложненную и нестабильную кодовую базу, в которую были зарыты крупные деньги).
3. Один, участником которого я являюсь сейчас, так же борется за жизнь, но есть сильный риск того, что он повторит первый или второй сценарий.
Про случаи, о которых я знаю по наслышке, я рассказывать не буду, но их ещё больше.

"Тенденция, однако" (с)

Моя скромная гипотеза, объясняющая этот феномен, состоит в том, что типичным технарям просто психологически комфортнее делать технологию, а не конечный продукт, обладающий business-value. Разработчики — эгоцентристы, им некомфортно влезать в шкуру пользователя, учиться смотреть на мир его глазами, понимать его проблемы, получать от него негативный фидбек. Им гораздо проще и интересное заниматься технологией ради нее самой, потому что там не надо выходить из своей зоны комфорта. Технология делается не для пользователей, а для самих себя (или же других разработчиков), так что можно обойтись привычной картиной мира критериями оценки результата, да и общаться с потребителем проще. 

Поэтому, они стараются максимально оттянуть тот момент, когда им потребуется решать реальные проблемы клиента. Но, делать что-то надо, вот и появляется такая уловка — мол, клиентскими проблемами мы займемся завтра, а сейчас мы подготовим для этого солидную техническую базу. Истинная цель этой стратегии — оправдать в своих глазах и в глазах руководства замыкание в своей зоне комфорта, изолированной от реальных целей проекта, продиктованных бизнесом. Получить возможность избежать неприятных коммуникаций о бизнес-проблеме и принятия решений, основанных не на привычных критериях (техническое совершенство), а на чуждых среднему разработчику критериях бизнеса. То же самое, в миниатюре, можно видеть, когда при обсуждении трудного и неоднозначного вопроса проектирования, команда дружно и с улыбкой решает "заложить гибкость", вместо того, чтобы разобраться в проблеме и выбрать оптимальный вариант.

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

Зло, о котором я говорю — это именно такой подход, а не результат.

Наш метод проведения ретроспективы

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

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

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

1. Собрания растягивались, утомляя участников до состояния полной непродуктивности.
2. Не все заявленные вопросы успевали обсудить.
3. Обсуждения отдельных вопросов вызывали долгие споры, оканчивавшиеся ничем.
4. Слишком туманные решения, не являющиеся actionable item.

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

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

Затем, команда устраивает второй штурм, решая, как она может повлиять на корневые проблемы, которые привели к проявлению непосредственно наблюдаемых. Принятые решения так же наносятся на схему.  

Если первая итерация процесса не исчерпала всех проблем для обсуждения, то она повторяется. Обычно за ретроспективу у нас случается от одной до трех итераций.

В результате получается примерно такая картинка:

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

Такой формат позволил изменить к лучшему наши встречи, повысить их эффективность.

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

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

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

Зарисовка из жизни: опыт борьбы за производительность сборочного сервера (окончание)

Продолжение истории о борьбе с деградацией производительности сборочного сервера.

В прошлой заметке я остановился на том напряежённом моменте, когда специалист из IT-отдела признал их ответственность за деградацию производительности сервера и даже подтвердил то письмом.

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

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

Чтобы это решение "взлетело", пришлось решить две небольшие проблемы:
1. Поскольку объем виртуального диска был ограничен, пришлось подправить build process workflow таким образом, чтобы он удалял все файлы после сборки.
2. Сборка вызывала много активности во временном каталоге (например, инструментарий WiX этим отличился), так что пришлось и его перенаправить на RAM disk.

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

Эти идеи нашлись в форме использования тех ресурсов, которые оказались в нашем распоряжении практически случайно. У нас остались рабочии станции двух уволившихся ранее сотрудников, о которых наши  IT-шники попросту забыли. Нет худа без добра: безалаберность их отдела, приведшая к бедам на виртуальной инфраструктуре, открыла нам нетрадиционную возможность для решения наших проблем :)

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

Зарисовка из жизни: опыт борьбы за производительность сборочного сервера (начало)

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

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

Началось всё с того, что одна из команд разработчиков "дозрела" до применения такой полезной функции TFS как gated build для защиты репозитория от ломающих изменений. Это было сделано, но быстро выяснилось, что сборка занимала слишком много времени: один check-in занимал 15-20 минут, тогда как разработчикам хотелось бы, чтобы это происходило моментально. По результатам проведенного const/benefit analysis удалось договориться о том, что целевая длительность gated build - 5 минут.  Этого удалось достичь путем исключения интеграционных тестов из сборки, а также отказом от сборки инсталляционных пакетов, что в итоге дало время сборки ~4.5 минуты.

Но это было лишь началом. Спустя примерно два месяца от этой команды поступили жалобы на медленную сборку, которая вместо целевых пяти минут стала занимать около 20-25 минут. Поскольку наша сборочная инфраструктура виртуализирована, то было три уровня, на которых могли быть расположены причины деградации:
1. Исходный код и скрипты сборки, которые могли замедлиться в ходе развития;
2. Виртуальная машина сборочного сревера.
3. Виртуальная инфраструктура, поддерживавшая сборочный сервер, производительность которой могла деградировать по независящим от нас причинам.

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

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

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

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

Продолжение следует.

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

Немецкий военный мыслитель 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. Многие начинающие разработчики  упускают из виду этот аспект своей работы, считая, что главное - это знание технологий и инструментов разработки, а все остальное либо не нужно, либо не важно. Я и сам с завидным упорством набивал себе все виды шишек из-за пренебрежения этими навыками, пока осознание того, что я действительно делаю что-то не так, не изменило мою жизнь.

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

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

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

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

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

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

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

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

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

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

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

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

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

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