Бег и разработка продуктов

Что может быть общего между бегом и разработкой программного обеспечения? На первый взгляд, ничего особенного. Потный и стройный бегун совершенно непохож на рыхлого, согнутого сколиозом программиста. Разработчикам не рукоплещут стадионы и никто не выдает им знамя страны для почетного круга по офису после выпущенного релиза. И, тем не менее, между бегом и разработкой много общего.

Недавно я прочитал одну тяжелую книгу — Surfaces and Essences. Дуглас Хофштадтер оттянулся по полной и сделал так, что после первых 50 страниц читать книгу просто не хочется. Я буквально заставлял себя осваивать пару десятков страниц в неделю, пока не дошел до последней трети книги — и там все стало очень круто.

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

Хорошая книга. Стоит прочитать. Source: http://birdschmidt.blogspot.com/2013/10/more-dandy-looking-books-in-mail.html

У меня родилась простая идея, взять одну область знаний, проанализировать ее и применить к другой области знаний. Я выбрал бег.

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

Медиум не позволяет вставлять таблицы, приходится выкручиваться…

Может, у вас появились вопросы, вроде “что этот странный чувак имеет ввиду под направлением разработки?” и “какие нахрен травмы у программистов?” Это очень хорошо, значит интрига присутствует и вы хотя бы пробежите глазами картинки.

Какая цель бега вообще? Я бы сказал, такая:

Бежать как можно быстрее как можно дальше без травм

Бегун на стометровке рассмеется мне в лицо, потому что бежать дальше ему не надо. Но любой бегун на средние и дальние дистанции одобрительно кивнет. Если вы начинали бегать, то знаете, как это бывает. Сначала вы пробегаете 2 километра с темпом 6:50. Со временем 5 километров с темпом 5:30. Потом 10 с темпом 4:50 и наконец перестаете бегать из-за проблем с коленом/ахилом/пяткой/голеностопом. Каждый раз, выходя на пробежку, вы хотите пробежать чуть дальше и чуть быстрее, чем в прошлый раз.

Давайте переключимся на программные продукты. И тут мы хотим

Разрабатывать как можно быстрее как можно дальше без травм

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

Мы возьмем свойства бега и сгенерируем новые гипотезы, которые можно будет попробовать в разработке.

Направление

Вообще бежать нужно в правильную сторону. В беге это настолько тривиальная вещь, что никто даже не задумывается об этом. Сложно себе представить, как Усейн Болт прикрепляет колодки в другую сторону и стартует на трибуны. Или как в середине 800 метровки Уилсон Кипкетер резко разворачивается и убегает назад, провожаемый недоуменным гулом стадиона и удивленными глазами соперников.

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

Выбор верного направления в разработке продуктов — невероятно сложная штука. Ошибаются все. Интуиция не работает. Коллективный разум выдает удивительно неверные решения. Формальную модель построить сложно. Даже опыт помогает далеко не всегда. Если мы побежали не в ту сторону, становится совершенно неважно, с какой скоростью мы бежим. Ну разве что мы окажется в неправильном месте быстрее. И там нас никто не ждет.

Что можно сделать, чтобы выбирать правильное направление? Делать быстрые прототипы и проверять концепции. Строить простые модели и учитывать паттерны поведения пользователей. Обложить систему статистикой и научиться понимать, какие фичи используют, а какие не очень. Решений много и все они несовершенны. Крайне важно понять, что выбор направления — это самая важная штука в разработке. Если направление верное — мы рано или поздно будем наслаждаться солнышком и морем. Если нет — нас ждут дождливые ночи в жопе мира.

Дистанция

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

Вот забавное видео, которое неплохо все объясняет. http://youtu.be/Uxwh2IIg_Z0

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

Спринтеры

• Делают очень быстро, не думают о поддержке
• Пишут крутой непонятный другим код
• Прыгают с проекта на проект

Стайеры

• Делают медленно, сопровождение важно
• Пишут простой и понятный код
• Долго работают на одном проекте

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

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

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

Реальные бегуны.

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

Наша цель — исключить длинные релизы.

Живая легенда разработки продуктов.

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

Скорость

Люди бегают довольно медленно. Выдающиеся личности могут бежать со скоростью 38 км/ч, но очень недолго. Другие выдающиеся личности могут бежать со скоростью 20 км/ч два часа. А некоторые могут бежать сутки со скоростью 12 км/ч. Вообще люди отличаются необычайной выносливостью, и вполне могут загнать антилопу за несколько часов непрерывного преследования.

Source: http://en.wikipedia.org/wiki/Running

На длинной дистанции мы не можем бежать очень быстро. Что будет, если пытаться это делать?

И вот начинается забег на пять километров. Знаменитый спринтер Григорий Колодкин возглавляет забег и бежит в гордом одиночестве. Вот он преодолевает первые круги дистанции с невероятным отрывом. Он наращивает темп и ему кажется, что финиш вот-вот наступит. Григорий с удивлением выясняет, что до финиша еще 4 километра, а бежать дальше организм отказыватся. У организма есть существенные аргументы, он вообще удивлен, как смог пробежать целый километр в таком темпе. Григорий переходит на бег трусцой, восстанавливая дыхание и мышцы. Пелотон настигает Григория на третьем километре дистанции, последний бегун пелотона дружески хлопает Григория по плечу и легко устремляется вперед.

А теперь давайте возьмем команду программистов. Она спокойно, в своем темпе работает над релизом. Тут приходит менеджер проекта и говорит “ребята, надо быстрее! У нас важный дедлайн!” Команда говорит “надо, значит надо” и прибавляет темп. Через пару месяцев оказывается, что к дедлайну не успеть. Менеджер проекта произносит яркую мотивационную речь, после чего команда работает по воскресеньям, ночует в офисе, кушает пиццу, запивая ее Burn’ом, и колбасит код с невероятной скоростью. Но в один прекрасный момент наступает fuck it point. Менеджеру очень повезет, если fuck it point наступит после дедлайна. Достигнув этой знаменательной точки, команда работает в предельно низком темпе, с отвращением глядит на код, с омерзением исправляет новые баги и старается сделать все, чтобы не работать.

Чтобы бежать быстрее долго — нужна выносливость

Возникает вопрос, как в беге тренируется выносливость? Один из хороших подходов — это интервальная тренировка.

Интервальная тренировка

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

Можно ли применить что-то похожее в разработке продуктов? Конечно же да. И это мы назовем интервальной разработкой.

Интервальная разработка.

Представим себе маленькую команду разработки, которая делает довольно большую фичу в продукте.

Фаза 1. Обычный темп (2 месяца)

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

Фаза 2. Ускоренный темп (1 месяц)

Цель этого режима — фокус.

• Команда убирает все собрания, которые не посвящены непосредственно фиче. Ежедневные стендап собрания, статус репорты и прочие собрания. Вы сможете прожить без них месяц. Точно сможете.
• На время работы выключатся все мессенджеры: Skype, ICQ (да ладно?), IRC и так далее. Если есть удаленные работники, канал оставляется только с ними. Можно выделять время на проверку почты и сообщений, но все равно нужно все минимизировать.
• Если людей из команды привыкли отвлекать представители других команд — вежливо попросите их подождать месяц. Пусть найдут себе других. Повесьте на дверь табличку “не беспокоить” и не отзывайтесь на мольбы о помощи.
• Попробуйте парное программирование. Когда сидишь в паре с другим человеком, не особенно овлечешься. Фокус будет держаться сам по себе.
• Никаких овертаймов!

Можете пробовать все, что угодно, но главная цель — сконцентрированно работать над фичей. Долой многозадачность! Долой все устоявшиеся рутинные дела! Через пару недель вас будет распирать от достигнутого. Чертовски приятно уходить домой, ощущая хороший прогресс и объем сделанных задач.

Четвертая неделя — это наш power lap. Последний рывок перед выпуском фичи в продакшн. Тут можно еще немножно ускориться, может зацепить какую субботу. Все доделать. И выпустить. Настоящие художники выпускают;

Фаза 3. Неделя релаксации (1 неделя)

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

Отдохнули? А теперь самое время взять новую фичу.

Такой режим работы имеет несколько теоретических преимуществ:

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

Фартлек

Кроме ритмичной интервальной тренировки есть еще и неструктурированная. Фартлек придумали в Швеции для тренировки бегунов по пересеченной местности. Все очень просто:

В простейшей форме можно выделить 3 фазы: разогрев (бег в очень медленном темпе), быстрый бег и скоростной бег.

А что будет, если это применить к разработке?

Фартлек разработка.

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

Фаза 1. Медленная (1 месяц)

Неспеша создаем UX фичи, лениво пишем прототипы, исследуем архитектурные решения, думаем, читаем и обсуждаем все это за чашкой чая. Цель этой фазы — хорошенько понять, что же мы тут делаем и как это сделать лучше.

Фаза 2. Умеренная (2 недели)

Начинаем разработку в обычном темпе, разве что попытавшись немного притушить второстепенные активности.

Фаза 3. Ускоренная (2 недели)

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

Дальше мы пару раз чередуем фазы 2 и 3. И на выходе получаем готовую фичу.

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

Травмы

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

У разработчиков тоже есть свои травмы. Логическая цепочка будет такая:

Баги и малоподвижный образ жизни > Эмоциональное выгорание > Печеньки и кофе > #безысходность.

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

Что же делать? “Ага, раньше же все бегали босиком. Почему бы нам не вернуться к истокам?” — подумали люди. И появилась техника бега босиком.

Source: http://www.healthynomics.com/2010/02/running-barefoot-and-barefoot-alternatives/

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

Избавившись от одних проблемы, мы приобрели другие проблемы.

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

Забавные кроссовки.

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

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

Ничего не напоминает? Давайте проведем аналогию с разработкой.

В самом деле, почти все разработчики не особенно любят тестировать. “На это есть тестировщики, чего нам тут возиться?” — резонно заявляют они. Это все прекрасно, но часто ведет к наплевательскому отношению. “Ну вот вроде все готово, сейчас отдадим тестерам, пусть поищут баги. Позитивные сценарии самим проходить некомильфо. Я лучше пойду почитаю про скалу”. В результате фича прыгает от тестировщика к разработчику несколько раз, пока все баги не поправят. Это увеличивает время разработки и снижает скорость (кстати, бег на носок на 5% быстрее, чем бег на пятку).

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

Можно немного подстраховаться и начать писать автоматические тесты. Уверенности станет побольше, но все равно не расслабишься.

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

Резюме

Давайте подведем итог. Мы провели четыре аналогии между бегом и разработкой.

1. Направление — выбор правильных фич
2. Сокращение дистанции — мелкие релизы и фичи
3. Увеличение скорости и выносливости — интервальная разработка
4. Снижение травматичности — выбор правильных практик

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

P.S. Меня можно добавить в друзья в фейсбуке, следить за мной в твиттере. И я буду рад любому фидбеку по нашему продукту управления проектами.

P.P.S. За этот абзац ^ выше пост забанили на хабре.