Мы лажаем: сложный разговор о том, как правильно справляться с факапами в IT
Ошибки и проблемы в работе компании - это сложная тема, о которой обычно не очень хочется говорить. Гораздо приятнее говорить о своих достижениях и успешных кейсах. Но как ни крути, публичное обсуждение факапов - это очень сильная терапия, которая помогает стать лучше. В сфере IT ошибки - это обычное дело, так что давайте поговорим не о том, как их избегать, а о том, как проживать их правильно.
Откуда берутся факапы
Разработка диджитал-продуктов - это процесс с миллионом переменных. Как будто вы собираете продвинутый конструктор LEGO на время, подчас выдумывая недостающие детали на ходу. Редко можно добиться того, чтобы абсолютно все шло по плану. Перечислять частные причины ошибок можно долго - человеческий фактор, технические проблемы, сложности коммуникации, форс-мажор, etc. Я вообще считаю, что во вселенной не существует ничего идеального: людей, предметов, процессов.
На ситуацию можно смотреть и с точки зрения статистики - если вы сделаете девять проектов без проблем, на десятом что-то точно пойдет не так. Факт в том, что никто не застрахован от неприятностей, иногда они происходят, несмотря на весь опыт разработчиков и любые возможные меры предосторожности.
Как это бывает на практике
Неприятности на проекте условно можно поделить на две категории: неудачные обстоятельства и неудачные решения.
Неудачные обстоятельства хоть и провоцируют стресс, но все же не так страшны. Скажем, вскоре после запуска сайта клиент без предупреждения запускает seo-ботов, которые кладут ресурс на лопатки. Ну или кто-то неверно рассчитал нагрузку на сервера. Проблемы на проектах могут возникнуть при заливе крупных обновлений,при переводе продукта на другие технологии, или при реализации большого количества фич, особенно если времени на движение по итерациям у команды не было.
Важно своевременно устранять такие проблемы и держать под контролем коммуникацию, иначе они начинают сеять на стороне клиента панику. Чтобы избежать подобного, мы готовимся к заливу обновлений заранее и заранее обсуждаем все наши действия. И если ресурс все-таки “ложится”, то команда разработки уже готова без промедлений все починить.
Неудачные решения гораздо хуже. Плохо продуманная бизнес-логика, проблемы с архитектурой, ошибочный выбор технологий, etc. Примеры из жизни: клиент заказывает разработку простейшего приложения или MVP, но по ходу дела придумывает к нему два десятка новых фич. А разработчики не замечают или игнорируют очевидные проблемы - с учетом всех новых требований масштаб проекта изменился, его архитектуру пора менять. Как результат, итоговый продукт формально вписывается в ТЗ, но на практике совершенно непригоден к использованию.
Подобное случается в том случае, если роли в проекте разработки ПО изначально были распределены неверно, или команде не удалось построить с клиентом эффективную коммуникацию. Отследить истоки проблемы в таких ситуациях сложно, да и поиск крайних мало чем поможет. Проект нужно переделывать, теряя время и деньги. Клиентоориентированная организация, как правило, закрывает такие дыры ценой собственной прибыли.
Больше про факапы, которые с нами случались в работе и как мы с ними справлялись смотрите в нашем подкасте.
Кто виноват?
Когда в WEZOM кто-то терпит неудачу, то я не рассматриваю это как ответственность отдельного человека, или даже отдельной команды разработчиков. Лажаем мы все вместе, это наша общая ответственность. В конце концов, клиентам не важно, по какой причине произошел факап. Если это случилось, значит у нас что-то не так с процессами, их нужно улучшать.
Это вовсе не значит, что на ошибки не нужно реагировать точечно. Ни один факап нельзя оставлять без внимания, мы разбираем их до мельчайших подробностей. Каждый причастный сотрудник должен твердо понимать, почему возникла проблема, и какую роль в ней сыграли его действия, или его бездействие. Важно, чтобы каждый сделал для себя выводы и больше не допускал таких промахов.
Обсуждение ошибок на наших созвонах может быть резким и эмоциональным, но по факту мы никогда не ищем “крайнего”. Бывают ситуации, когда за провалом стоит конкретный сотрудник, и его нужно “поругать”. Толерантности к факапам быть не может. Как бы это не звучало, но тут работает аналогия с воспитанием детей - это бесконечный процесс: планомерное повторение одних и тех же правил, пока они не становятся базовой нормой.
Как вести себя с клиентом в случае факапа
Это ключевой вопрос, ведь в конечном итоге клиента не интересуют причины проблем и поиск виновных. Они хотят получить то, за что платят деньги.
Во-первых, важна оперативность. В идеале нужно сразу же иметь на столе несколько вариантов решения проблемы и двигаться по ним. Опытный менеджер уже на старте проекта отметит для себя его уязвимые точки и набросает несколько сценариев “что если”. И конечно же, примет превентивные меры.
Во-вторых, важна честность. Нужно иметь мужество сказать клиенту всю правду: “мы совершили ошибку по таким-то причинам, у нас есть вот такие варианты ее решения”. Честность почти всегда находит понимание, ведь наш клиент - тоже же человек бизнеса. Он понимает, что ни один процесс не застрахован от проблем. При нормально выстроенной коммуникации, первый стрессовый толчок на проекте будет встречен клиентом с пониманием.
Худшее, что может сделать компания в случае факапа, так это начать “валять дурака” - уходить от прямых ответов, замыливать клиенту глаза, или даже перекладывать ответственность за ситуацию на него самого. Такая практика на рынке присутствует, и я считаю это слабой позицией. Ошибку можно исправить, а вот репутационные потери из-за неадекватной коммуникации отыграть уже не получится.
Могут ли ошибки возникать по вине клиента?
Перекладывание ответственности за проблему на клиента - распространенная тема для разговоров в курилках IT-компаний. Ведь, чтобы создать действительно крутой продукт, нужно постоянно удерживать фокус внимания клиента на разработке, а это бывает непросто. С другой стороны, есть клиенты, которые приходят к аутсорсеру с собственными представлениями о продукте, и настаивают на них до последнего. Даже если разработчики понимают, что их представления ошибочны.
Я убежден, что клиент никак не может нести ответственности за результаты нашей работы. Если мы называем себя экспертами и берем на себя обязательства сделать все качественно, с соблюдением дедлайнов и бюджета, то вся ответственность за результат лежит на нас.
Да, в IT-производстве есть такой момент - желания и взгляды клиента временами могут вести проект не туда, куда он, с нашей точки зрения, должен двигаться. Но клиент не может и не обязан быть экспертом в разработке, иначе он не обращался бы к нам. Наша миссия здесь - предоставить действительно качественный клиентский сервис: провести коммуникацию должным образом, указать на все возможные риски и проблемы предлагаемых решений.
В таких случаях мы четко следуем нашей инструкции и отработанному бизнес-процессу: предупреждаем о последствиях того или иного решения, отдельно фиксируем это предупреждение. И если разработчики оказываются правы, и проект движется в тупик, то мы возвращаемся к той самой поворотной точке и отрабатываем все заново. Что ж, поиск рабочих решений “методом тыка” - это тоже часть процесса разработки, хороший проект постоянно развивается и переживает множество итераций.
В данном случае, наша ответственность, как профессионалов и знатоков ниши - дать клиенту полную и честную картину проекта. Принять все необходимые меры для того, чтобы уберечь его от дорогостоящих ошибок.
Факапы и “настоящая” клиентоориентированность
С оглядкой на весь свой опыт могу лишь дать совет для клиентов, которые ищут аутсорсеров в IT: не верьте в красивые обещания. Даже больше того, опасайтесь разработчиков, которые во всем с вами соглашаются. Если команда аутсорсеров не оценивает ваши идеи через призму своей экспертизы и не предлагает собственных решений, то у нее либо нет опыта в вашей нише, либо (что гораздо хуже), ей безразличен успех вашего проекта. Если вовлеченности в проект у разработчиков нет, то проблемы и факапы будут прежде всего “замыливаться” и замалчиваться. Лишь бы формально выполнить ТЗ, сдать побыстрее проект в релиз и забыть о нем.
Мы давно признали такую стратегию провальной, даже если в моменте она позволяет зарабатывать больше. Нам интересен именно успех конечного продукта, его фактическое влияние на бизнес клиента. Ведь довольный клиент - это лояльный клиент, он становится нашим партнером на многие годы вперед, рекомендует нас друзьям. В том числе, с оглядкой на то, как мы реагируем на форс-мажоры, исправляем ошибки и “тушим пожары”.
Давно заметил, что в бизнес-менталитете нашей страны укоренились не совсем правильные представления о том, что такое клиентоориентированная компания. Под этими словами часто прячут стремление угодить клиенту здесь и сейчас, даже ценой эффективности проекта. Я же убежден, что настоящие признаки клиентоориентированности - это честность, точность и открытость, а не избегание “острых углов”. И в этом смысле WEZOM - всегда на 100% за клиента - за тесный диалог с ним, за реальное преодоление трудностей, за работу на результат.
