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

Недавно я выбрался из своего первого марша смерти.

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

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

Мой марш смерти был видом длительного переутомления. Не смешно.

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

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

Я также потратил некоторое время на выяснение, стоило ли оно того? Были ли оправданы конечным результатом 16-часовые дни без выходных в течение месяца?

Зависит от того, кого вы спросите.

Если вы спросите высшее руководство, это того стоило. Проект был выполнен в срок, и мы доставили его довольному заказчику.

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

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

Добро

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

Хорошая видимость

Нашему продукту никогда не было столько внимания. Да, мы были под прицелом, и внимание могло быть не на 100% положительным, но люди использовали наше приложение. Мы постоянно получали отзывы о существующих функциях, новых функциях, вопросах UX, возможности поддержки, будущих функциях и обо всем, что между ними.

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

Супер скорость

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

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

Умные новые решения

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

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

Красные флаги

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

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

Выгореть

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

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

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

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

Односторонние двери

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

Не стоит просто говорить «да, мы можем так сделать» и загонять себя в угол. Вы уже ближе к приложению, чем обычно, и можете придумывать быстрые и умные решения.

Но то, что вы могли, не всегда означает, что вы должны. Amazon называет это дверью с односторонним движением. Это решение, от которого нельзя отказаться, если вы его приняли.

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

Баланс между работой и личной жизнью

Этим сложно управлять как лидером. Есть люди, которым просто нравится работать. Они встают, идут на работу, а когда закончили, ложатся спать. Промыть и повторить. Вы должны убедиться, что люди уделяют время себе и своим семьям.

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

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

Аналитический паралич

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

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

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

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

Заключение

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

Однако у него есть серьезные недостатки. Переутомление может нанести реальный вред вашим сотрудникам. Это чувствуют и все, не только разработчики. Менеджеры, QA, BA, профессиональные службы, технические писатели, все, кто связан с программным обеспечением, внезапно обрушиваются на огромную волну работы.

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

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