Всем привет. Меня зовут Александр Наумов, и последние 5 лет я занимаюсь тестированием сайта Утконос ОНЛАЙН — руковожу группой QA.

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

Роберт Кийосаки как-то сказал: «Победители не боятся проиграть. Неудача — это часть дороги к успеху. Люди, избегающее неудач, избегают и успехов».

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

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

Что такое неудача?

Я всегда думал, что неудача — это неблагоприятный исход моих действий: «Я сделал, что-то неправильно», «не успел в срок», «надо было уточнить, а я пустил на самотек». Одним словом, налажал. Но это не всегда так. 

Википедия говорит, что неудачи делятся на 2 категории:

• Нежелательный исход чего-либо, отсутствие успеха. Негативные последствия от собственных действий.

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

Рассмотрим подробнее каждый случай и разберемся, в чем же причины FuckUp’а.

Нежелательный исход

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

Причина 1: Плохая осведомленность

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

Случай из практики:

Мы дорабатывали корзину. У нас несколько фулфилмент центров поэтому в корзине решили добавить возможность выбора адреса.

Логично, если у вас более одного адреса, в корзине вы выбираете нужный и видите актуальный состав корзины с привязкой к складу, который это доставит. А если в профиле адрес не указан, то при добавлении товара вылезает поп-ап «добавь адрес». Все отлично, тесты прошли. Выкатились, ошибок нет. Через месяц звонит поддержка: «У нас массовый инцидент, не работает корзина».

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

Решение: Документация

Это долго, скучно, но необходимо. Структурируйте ведение документации и держите ее в актуальном виде.

 Причина 2: Спешка

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

Случай из практики:

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

Решение: Планируйте неудачи

Накидайте небольшой план, что вы будете делать, если все пойдет не так.

Причина 3: Выгорание профессиональное и эмоциональное 

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

Случай из практики:

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

Решение: Отпуск, Оценка сложности работы

Проанализируйте, как доработка/фича/релиз влияют на продукт. И не забывайте про отпуск, если чувствуете, что устали от проекта.

Неблагоприятное стечение обстоятельств

Здесь иначе: выложились на 200%, очень устали, но все летит в пропасть.

Причина 1: Воздействие извне

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

Случай из практики:

В 2015 мы попали под WoW-эффект компании Amazon с ее Dash Button и решили сделать нечто похожее. Замысел был прост: клиент получает физическую кнопку, которая позволяет добавить продукт в корзину или оформить заказ на ближайший интервал. Все проверки с прототипом кнопки прошли успешно, но мы не запустились. Поставка партии кнопок задержалась, а проект решили не продолжать.

Решение: Коммуникации

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

Причина 2: Форс-мажор

Самая непредсказуемая причина.

Случай из практики:

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

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

Решение: Закон Мерфи

Закон гласит: «Если что-то может пойти не так, оно пойдёт не так». Анализируйте работу команды: чем грозит та или иная доработка? Каков самый плохой итог принятого решения? Возможно, вы что-то упускаете или недооцениваете влияние.

Извлекаем пользу из FuckUp’а

У неудачи есть две стороны. По итогам заваленного релиза, недоработанного проекта и любого рабочего fuсkup’a мы можем стать жертвами разных негативных состояний:

• Страх
  «Как же так, мы налажали. Что же теперь будет? Меня уволят или кинут на глухой проект,» — пугающая неизвестность.

• Стыд
  Стыдно перед коллегами, что ты не увидел эту проблему раньше.

• Отсутствие желание двигаться к цели
  «Ну и зачем дальше продолжать? И так понятно, что я не могу это сделать. Получится так же или хуже».

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

•  Апатия
  Все плохо, ничего не хочется, с трудом беретесь за другие задачи и еле функционируете сами. 

• Синдром самозванца
  «Другие-то коллеги никогда такой ошибки не сделают. На такое способен только я, и все об этом знают».

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

• Новые ощущения
  Познакомьтесь, это FuckUp, и да, это больно. Запомните его, он существует и очень бодрит.

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

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

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

Учимся принимать поражение

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

Что НЕ нужно делать:

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

• Отвергать вину и причастность
  «На стенде все было хорошо, а что там на проде у клиента, я не знаю, не мои проблемы». Мы все сотрудничаем и работаем над одной задачей — когда есть проблема, ее надо решать, а не тыкать пальцами друг в друга. 

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

Что НУЖНО делать, когда разработка уже исправляет, а мы ждем фикс:

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

• Оценить размер ущерба
  Аналитика в помощь. Она даст полное представление о проблеме и поможет понять, насколько страшен пожар: может, не стоит сильно переживать, или наоборот, надо бежать и собирать всю команду.

• Выяснить причину решения
  Почему были приняты именно эти решения? Нужно вернуться к моменту, когда все началось.

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

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

Решение: Post Mortem

Одной из хороших практик является написание Post Mortem по крупным ошибкам. Так вы получите весомый аргумент, если придется менять один из процессов работы команды, или поднять приоритет технического долга проекта перед бизнесом.

Где взять силы?

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

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

• Хобби
  У вас есть любимое занятие, кроме написания кода? Если после работы вы программируете, то это больше похоже на то, как если бы вы ели в Бургер Кинге после Макдональдса. Хобби должно кардинально отличаться от профессиональной деятельности.

• Прогулки
  Помогают успокоиться и привести мысли в порядок.

• Бытовые вопросы
  Починить кран, заменить душ, разобрать шкаф. Как говорит моя жена: «Порядок в шкафу — порядок в голове».

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

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

На этой ноте хочется пожелать всем самого лучшего в нового году. И поменьше факапов :)