После одного релиза у нас посыпались поток обращений в поддержку. Мягко сказать, ситуация была не из приятных.
Причина была банальная. Очень торопились попасть в срок. Чтобы сдать релиз до обещанной даты, конечно же сжали тестирование и ревью. Как оказалось, это было зря.
Клиенту в такой ситуации не очень интересно, кто сколько часов работал, кто предупреждал о рисках и почему на проверку осталось меньше времени.
Ну ладно, первая проблема уже случилась, но тут в моменте можно легко перейти ко второй - когда команда спорит, оправдывается, доказывает, что "мы очень старались", или ищет причину на стороне клиента. Даже если часть правды в этом есть, то делать так уж точно не стоит. Клиент уйдет в защитную позицию и тут будет вообще сложно что-либо доказать.
В этой ситуации одних горящих исправлений недостаточно. Нужно не только убрать последствия, но и понять, почему команда вообще попала в эту ситуацию. Разобрать причину, подготовить варианты изменений, обсудить их с клиентом и реально внедрить выбранное решение в процесс. Иначе через месяц можно снова сидеть на встрече с тем же клиентом и слушать вопрос: “А что вы поменяли после прошлого раза?”
Клиент смотрит не только на баги
Ошибки бывают даже у всех. После срыва сроков или неудачного релиза клиент смотрит уже не только на саму ошибку. Он смотрит, что происходит дальше. Есть ли понятный ответ. Есть ли ответственный. Есть ли план. Или все ограничивается фразой "мы разбираемся". А ещё лучше, когда после этой фразы куда то пропали и не вернулись. Разобрались? Не разобрались? Сиди гадай.
Особенно неприятно, когда клиент узнает о проблеме уже по факту. Он уже мог подготовить пользователей, поставить запуск в свой план, пообещать результат внутри своей компании. И вдруг выясняется, что в дату не попали или после релиза критичный сценарий не работает.
Тут уже слова о том, что разбираемся и решаем не вызовут ничего, кроме недовольства и злости.
Самый опасный вариант - спор. Кто-то доказывает, что "с нашей стороны все было сделано", кто-то вспоминает, что "риски обсуждались", кто-то говорит, что пользователи проверяли не так. Каждый о своем и ничего про общий знаменатель. Смысла от спора и поиска виноватых будет мало.
Нужно не объяснить, почему мы торопились. Важно признать, что результат получился, мягко сказать, неудовлетворительным, и показать, что мы не собираемся с этим что-то делать.
Мы договорились, что сначала решаем последствия (если они есть), а потом отдельно разбираем причину и выносим варианты изменений в процесс. Уже внутри команды разобрали, где поздно увидели риск, какие проверки сократили, почему это дошло до пользователей и почему решение "успеть любой ценой" в итоге ударило по качеству.
Сначала разбираем последствия, потом разбираем причины
Когда проблема уже видна клиенту, хочется сразу многое рассказать о причинах, успокоить, сказать, что всё под контролем и назвать сроки исправления. Обещать дело хорошее, главное, чтобы потом была возможность его выполнить.
Перед первым разговором руководителю нужна короткая рабочая картина. Только не надо давать простыню, которую никто читать не будет. Нужны короткие ответы на простые вопросы: что именно не работает, кого это затрагивает, что уже подтверждено, что пока проверяется, есть ли временный обход, кто ведет коммуникацию и когда можно дать следующий статус. В общем всё, что касается проблемы и её решения.
Если этого нет, то легко начать говорить общими словами. А общие слова после срыва срока раздражают. Клиент уже не хочет слышать "ситуация на контроле". Он хочет понять, какой именно контроль появился.
В первый момент важнее снизить ущерб. Решение может быть некрасивым, но главное, чтобы оно было и система работала.
В идеале, нужно приходить к клиенту сразу с несколькими вариантами. В этом случае разговор уже меньше похож на разбор полетов и больше концентрирует фокус на том, что будет.
Случилось и случилось. Как теперь про это рассказать?
Никуда не денешься. Лучше коротко признать факт. Звучать это может по-разному, но смысл должен остаться именно таким.
"Да, проблема есть. Сейчас главное - стабилизировать работу пользователей. Подтверждено, что ошибка затрагивает такие-то сценарии, остальные проверяем. Предлагаю сделать временный вариант, чтобы снять критичность, а причины разобрать отдельно после стабилизации. Следующее обновление по ситуации дам сегодня до 17:00."
Не факт, что клиент от такой фразы станет доволен. Но в ней есть то, чего обычно не хватает в плохих ситуациях: признание факта, граница известного, ближайшее действие и контрольная точка.
Если сорван срок, можно сказать проще: "К согласованной дате весь объем не готов. Предлагаю разделить его на обязательную часть и переносимую. До 15:00 дадим новый план: что показываем первым, какие риски остаются и когда будет следующий результат".
После сорванного срока лучше не говорить, что почти готово. Почти, почти и вот ещё чуть чуть. В этом сразу ощущаются риски. Лучше назвать меньший, но проверенный объем, который ещё можно успеть.
Первый разговор нужен, чтобы очертить текущую ситуацию. Чтобы было чёткое понимание, что происходит и не приходилось додумывать различные сценарии катастрофы. Дальше все равно придется дойти до причины, вариантов изменений и договоренностей по процессу.
Что лучше не говорить
После проблемного релиза особенно вредят фразы, которые звучат как защита или отговорки. "У нас все работало" звучит так, будто проблема клиента не считается проблемой. Лучше сказать: "На проверке этот сценарий не воспроизвелся, сейчас разбираем отличие от рабочей ситуации".
Иногда, если риск действительно обсуждался, очень хочется сказать "Мы же предупреждали". Особенно Но это звучит как "сами виноваты" и выглядит, как перекладывание вины. Лучше оставить эту часть для разбора и сейчас сказать иначе: "Риск обсуждался, но сейчас важнее снизить последствия. После стабилизации вернемся к тому, какие решения по этому риску нужно закрепить".
"Сейчас быстро поправим". А точно ли быстро поправим? Если масштаб еще не понятен, лучше не обещать исправление. Лучше обозначить ближайшую контрольную точку. Например: сначала проверим масштаб, а первый подтвержденный статус дадим к конкретному времени.
Фразу "больше такого не повторится" тоже лучше не говорить. Никто честно не может гарантировать, что похожих проблем больше не будет. Зато можно сказать, что именно меняется: вносим такие то изменения в процесс, чтобы снизить вероятность возникновения подобной ситуации в будущем.
Самое сложное - не отвечать раздражением на раздражение. Если клиент недоволен, он может это транслировать во вне. И в этом случае реакцию "Бей или беги" никто не отменял, но нужно держать контроль.
Обещать меньше, но точнее
После неприятной встречи хочется быстро успокоить клиента. Сказать, что завтра все будет готово, проблема небольшая, причину уже почти нашли, теперь все будет под контролем. Прям вот вот уже сейчас всё решим ещё вчера.
А будет ли клиент слушать эти обещания и верить им? Он может не спорить с каждой фразой, но сам думает: это реально проверено или меня обманывают?
Поэтому первое обещание после проблемы должно быть небольшим и надежным. В стиле: "до 17:00 дадим подтвержденный статус и варианты восстановления". Тут лучше договариваться о небольшом и по частям, но зато быть уверенным в реальности обещаний.
Стабилизация отдельно, причины отдельно
Может поступить один из первых вопросов клиента: "Почему это произошло?" Если пользователи прямо сейчас не могут работать, полный разбор причин может подождать. Сначала нужно снизить ущерб. И это нужно тактично объяснить клиенту с обозначением, что мы вернемся к этому разговору позже.
Я бы разделял три слоя. Первый — стабилизация: как дать людям работать сейчас. Второй — исправление: что нужно изменить в решении, настройках, данных или порядке релиза. Третий — профилактика: почему проблема дошла до клиента и что меняем, чтобы снизить вероятность повтора.
После стабилизации нельзя просто разойтись. Нужно вернуться к причинам. Не в формате с вилами "кто виноват", а в формате "какая часть процесса дала сбой". Проблема лежит где то на одном из этапов разработки, а не только в конкретной строчке кода.
В моем случае, когда возникла неприятная ситуация, причина была не только в конкретных ошибках после релиза. Проблема была в порядке подготовки: слишком сильно держались за дату, поздно вынесли риск, сократили проверку и ревью. Если бы мы просто исправили баги и разошлись, похожая история могла бы повториться.
Клиенту не нужна внутренняя кухня. Но изменения он должен видеть
После проблемного релиза есть соблазн все разобрать внутри, а клиенту потом показать готовый вывод. Это удобно и проще, но если есть желание вернуть доверие, то лучше сделать по другому.
Клиенту не нужно видеть внутренние споры, переписки и разбор каждого технического решения. Но ему важно понимать, что причина не просто "обсуждена", а превращена в конкретное изменение процесса.
Если результат не устроил клиента, мало закрыть последствия. Нужно дойти до изменения порядка работы. Где потеряли риск по сроку - раньше выносить его на обсуждение. Где сократили ревью - закрепить, что без него критичный объем не выходит. Где клиент поздно подключился к приемке - заранее договариваться, кто и когда проверяет результат.
Не все зависит только от команды разработки или сопровождения. Бывает, что срок был слишком сжат. Бывает, что данные для проверки дали в последний момент. Да всякое бывает.
Если всех обвинять, то смысла с таких встреч будет не много. Но если говорить через изменение порядка работы, разговор становится более продуктивным. Не "вы поздно дали пользователей для тестирования", а "для следующих релизов заранее фиксируем участников приемки и сроки обратной связи". Не "вы сами настояли на дате", а "если видим риск по сроку, раньше выносим его на выбор: сокращаем объем, переносим часть или усиливаем проверку".
После нашего проблемного релиза мы как раз пошли по этому пути. Разобрали причины внутри, подготовили несколько вариантов и вынесли их клиенту. Там уже обсуждали, какие изменения будем вносить в процесс.
Клиент в таком разговоре становится участником изменения, потому что часть процесса зависит и от него.
После встречи должны остаться не только слова
Письменная фиксация после встречи нужна, чтобы не потерять договоренности и не создать новые ожидания там, где их не было.
Я бы фиксировал коротко: какой факт признан проблемой, что уже подтверждено, что еще проверяется, какой ближайший шаг выбран, кто отвечает за коммуникацию, когда следующий статус, какое временное решение используем, что разберем после стабилизации и какие изменения процесса обсуждаем с клиентом.
Отдельно полезно написать, чего пока не обещаем. Руководитель сказал "проверим возможность исправить завтра", клиент услышал "завтра исправят". Поэтому лучше прямо отделять проверку от обязательства.
И еще одна практическая деталь: договоренности нужно привязать к следующему релизу, приемке или ревью. Иначе они останутся где то зафиксированными на листочке, который потом будет добросовестно потерян. Если решили, что критичные сценарии не выходят без проверки, это должно появиться в реальном порядке подготовки релиза, а не только в письме после неприятной встречи.
После встречи клиент смотрит уже на действия
Клиент не обязан поверить сразу. Если срок уже сорван, а релиз принес ошибки, словам уже могут не так верить. Начать восстановление можно с простого: вернуться с обновлением ровно тогда, когда сам обещал.
Но главный показатель - не встреча и не письмо, а то, что произошло после. Если договорились добавить проверку критичных сценариев, она должна появиться. Если решили не выпускать спорный объем без ревью, это должно соблюдаться. Если договорились раньше поднимать риск по срокам, нельзя снова молчать до последнего дня.
Иначе второй похожий разговор будет совсем другим. Во второй раз он уже спросит: "Мы это обсуждали. Почему повторилось?".
Что можно вынести из таких ситуаций
После срыва срока или проблемного релиза руководитель не должен становиться адвокатом команды против клиента. И не должен обещать невозможное, лишь бы быстрее закончить неприятный разговор. Его задача - вернуть управляемость.
После неудовлетворительного результата нужно дойти до причины и изменения порядка работы. Не просто организовать тушение пожара, а понять, где сломался процесс и что нужно поменять.
Самое неприятное - когда после правильной встречи ничего не меняется. Тогда при следующем похожем случае уже не получится спокойно говорить о проработке причин. Можно действительно сидеть с бледным видом и понимать, что клиент прав: в прошлый раз договорились, но процесс не изменили.
Доверие после проблемного релиза возвращается, когда клиент видит, что историю не замяли, причину нашли, договоренности не забыли, а при следующем похожем риске команда уже действует иначе. Если после встречи ничего не изменилось, это быстро всплывет. И второй раз объяснение "так получилось" уже не прокатит.