Материал подготовлен для будущих руководителей команд в ИТ.

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

Но с окончанием всё иначе. Последние 10% проекта, когда работа превращается в возню с мелочами, энергия заканчивается, а финишная черта постоянно отодвигается, – именно на этом этапе многие проекты незаметно разваливаются.

Если запуск проекта похож на взлёт, то завершение – на посадку. Здесь нужны совсем другие навыки и уровень внимания, и именно на этом этапе сосредоточено больше всего рисков. В конце концов, самое сложное в управлении самолётом – посадить его.

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

  • Почему финальный этап проекта психологически и организационно сложнее его начала.

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

  • Почему расползание скоупа ускоряется в самый неподходящий момент и как этому противостоять.

  • Практический план действий, который поможет хорошо завершать проекты.

Почему окончание – самая сложная часть

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

В программировании есть известное правило 90–90, которое приписывают Тому Каргиллу из Bell Labs: первые 90% работы занимают 90% времени, а оставшиеся 10% – ещё 90%. Джефф Этвуд отлично описал жизнь в таком состоянии в своей статье, уже ставшей классикой — о том, как проект вечно готов на 90%. Наверняка вам знакома эта ситуация.

Потому что именно в последних 10% всплывают граничные случаи, проблемы интеграции и тысяча мелких решений, о которых никто не думал, когда архитектуру набрасывали на доске или писали первые строки кода.

Мне это до боли знакомо, и, думаю, вам тоже.

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

Сет Годин в одноимённой книге называет этот этап провалом (the Dip): это долгий и неблагодарный отрезок между первоначальным воодушевлением и удовлетворением от завершённой работы. Большинство людей сдаются на этом этапе не потому, что работа слишком сложна, а потому, что заканчивается эмоциональное топливо. К слову, хорошо, что вы не видите мои приватные проекты на GitHub.

Есть ещё ошибка планирования (planning fallacy), термин Канемана и Тверски, который стал широко известен благодаря книге «Думай медленно… решай быстро». Мы систематически недооцениваем, сколько времени займёт задача, особенно если раньше ничего подобного не делали. И сильнее всего это бьёт как раз под конец проекта, потому что оставшаяся работа обычно хуже всего поддаётся оценке: например, «сколько итераций понадобится с пользователями, чтобы действительно довести продукт до ума?».

Больше о когнитивных искажениях читайте в статье.

Кроме того, интеграции, тестирование, деплой и документация имеют неприятное свойство занимать всё время, которое вы на них отвели. И ещё немного сверху…

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

Можно было бы ожидать, что здесь поможет эффект градиента цели (goal-gradient effect). Исследование Кивеца, Урминского и Чжэна показывает, что по мере приближения к цели люди естественным образом начинают прикладывать больше усилий. Но этот эффект работает только тогда, когда финишная черта видна и остаётся на месте. А в разработке она всё время отодвигается – и именно в этом проблема.

Тихая смерть проекта

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

Наверняка у каждого был проект, который ещё три месяца назад был «почти готов»: команда мысленно уже переключилась на другое, но формально точку так никто и не поставил. Характерные признаки: на доске в Linear всё ещё висят тикеты, никто не заглядывал туда неделями, ретроспективы не было, завершение не отметили, выводы не зафиксировали. Проект не провалился с треском – он просто незаметно канул в лету.

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

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

Тихая смерть особенно коварна потому, что состояние «готово на 95%» – самое дорогое для проекта: вы уже вложили почти максимум ресурсов, но ещё не поставили никакой ценности.

Или, что ещё хуже, успели выпустить только часть – достаточно, чтобы получить нагрузку на сопровождение, но недостаточно, чтобы добиться обещанного результата.

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

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

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

Ловушка «и ещё последнее»

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

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

«А можем добавить тёмную тему до запуска?» «А что с доступностью в новом сценарии?» «Я только что посмотрел, что на прошлой неделе выпустил конкурент. Мы можем сделать так же?» Каждая такая просьба сама по себе звучит разумно, каждая кажется небольшой, но каждая понемногу отодвигает финишную черту.

Джон Акофф в книге Finish называет это «благовидными препятствиями» (noble obstacles): вещами, которые выглядят как разумная подготовка, кажутся ответственным подходом, но на деле лишь маскируются под стремление всё сделать правильно.

И новые требования приходят не только от стейкхолдеров – мы сами делаем то же самое. «Перед релизом надо бы отрефакторить этот модуль» – благовидное препятствие. «Давайте ещё немного ускорим этот эндпоинт, чтобы P95 наконец стал зелёным» – ещё одно.

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

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

Джоэл Спольски очень точно сформулировал: «Решение, готовое на 50%, но которым люди реально пользуются, решает больше проблем и живёт дольше, чем решение, готовое на 99%, которого никто не видел, потому что оно всё ещё лежит у вас в лаборатории, где его бесконечно полируют».

Умение провести границу между «готово» и «достаточно готово» – одно из важнейших инженерных решений. И на финальном этапе принимать его придётся снова и снова. «Достаточно готово» означает выпустить, а не махнуть рукой на качество.

Как запоминаются релизы

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

Исследования Даниэля Канемана о правиле пика и конца показывают, что люди оценивают пережитый опыт в основном по двум моментам: пику – самому интенсивному эпизоду – и концу. А из-за так называемого эффекта пренебрежения длительностью (duration neglect) то, сколько времени всё это продолжалось, влияет на воспоминания гораздо меньше, чем можно было бы ожидать.

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

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

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

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

Как хорошо завершить проект

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

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

На финальном этапе вовлечённость, наоборот, должна стать плотнее. На заходе на посадку требуется активнее направлять работу, чаще проводить синки и жёстче расставлять приоритеты. И всё это вовсе не означает микроменеджмент.

Вот как хорошее завершение проекта выглядит на практике:

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

  • Жёстко защищайте скоуп. На каждый новый запрос отвечайте одинаково: «Отличная идея для v2». Ведите единый приоритизированный список того, что осталось сделать, и не поддавайтесь соблазну что-то туда добавить. Команда должна видеть, что финишная черта становится ближе, а не отодвигается.

  • Давайте стейкхолдерам больше информации, чем кажется необходимым. На финальном этапе им нужны более частые апдейты. Молчание порождает тревогу, а встревоженные стейкхолдеры приходят с новыми запросами в последний момент. Поэтому короткий ежедневный апдейт – «где мы сейчас, что осталось и когда планируем выпуск» – это дешёвая страховка от расползания скоупа.

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

  • Ограждайте команду от новых запросов. Вы – буфер между командой и остальной организацией. Каждый «быстрый вопрос» и каждая «маленькая просьба», которые доходят до команды в последние дни, могут сбить проект с курса, поэтому берите вопросы на себя. А если поздно появившееся требование действительно нельзя проигнорировать, не пытайтесь просто впихнуть его в текущий план: уберите что-то другое. «Мы можем это добавить, но тогда что-то другое придётся исключить. Что именно?» – гораздо честнее, чем делать вид, что добавлять новое можно бесконечно.

После релиза работа ещё не закончена: то, как вы закроете проект, не менее важно, чем то, как вы его завершили.

  • Проведите нормальную ретроспективу. Не формальную встречу, на которой все в очередной раз скажут «надо было лучше коммуницировать», а честно разберите, что сработало, что нет и что в следующий раз вы сделали бы иначе. Именно в конце проекта можно зафиксировать одни из самых ценных выводов – пока все детали ещё свежи в памяти.

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

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

Теперь ваша очередь

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

  • Проведите ревизию текущих проектов. Посмотрите на всё, над чем работает команда, и спросите себя: не застряло ли что-нибудь в состоянии «почти готово»? Если проект уже несколько недель остаётся на уровне 90%, нужно вмешаться: либо дожать его до завершения, либо осознанно решить остановиться. Тихая смерть проекта всегда обходится дороже, чем сознательное решение его заморозить.

  • Проведите премортем перед следующим релизом. До того как текущий проект войдёт в финальный этап, соберите команду и спросите: «Как этот финал может пойти не так?» Так вы обнаружите риски, о которых раньше не думали, и сможете построить чек-лист завершения вокруг способов их снизить. Это инверсия применительно к завершению проектов.

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

Подведём итог

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

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

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

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

  • 9 сентября в 20:00. «Как тимлиду распределять ответственность и не становиться узким местом команды». Записаться

  • 16 сентября в 20:00. «Сложные разговоры в команде: как давать обратную связь без эскалации». Записаться

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