Вы уверенный в своих знаниях специалист, который точно знает, сколько времени понадобится на новую фичу? Или может вы нашли неприятный баг за день до релиза? Или вовсе считаете новое дополнение нецелесообразным? Это все, конечно, хорошо, но заказчик все еще уверенно выходит в прод и требует полноценных результатов уже завтра.
А все дело в пресловутых софт-скиллах и айти-конфликтологии, о которой я и собираюсь рассказать вам в этой статье.
Ало, бизнес? Да-да, деньги.
Во главе заказчика стоит бизнес и требования, под которые вынужден подстраиваться сам заказчик. Он, возможно, и сам не хочет каждый день спрашивать вас о готовности релиза, но пока у бизнеса нет четкой картины "почему работа занимает ровно x дней, а не меньше", может складываться ощущение, что работа просто стоит, что приводит ко всяким неприятным последствиям и лишним нервам.
Более того, заказчик зачастую человек далекий от технических деталей, а потому не может оценить сколько времени займет добавление новой кнопки или изменение структуры баз данных. В своей практике я и сама часто сталкивалась с тем, что на простые задачи заказчик сразу был готов заложить несколько недель, ибо звучали они страшно и непонятно, а на действительно сложные вещи выделял сутки, потому что звучало понятно и просто.
И так как условия проектов, как и люди, все разные, иногда заказчик может открыто не соглашаться с вашими словами, что в конечном итоге приводит к:
а) заказчик остается прав, а к вам потом приходят с претензиями
б) происходит конфликт
в) рассуждения и споры затягиваются на несколько безрезультатных часов
Как можно заметить, я не написала про вариант, где в конфликте побеждает специалист, потому как, раз уж появилось несогласие, заказчик крайне редко будет готов идти на уступки, особенно при горящих сроках. И это вовсе не потому, что он плохой человек, а потому, что вы говорите на разных языках.
Вывод: крайне важно понимать структуру процессов бизнеса, говорить на его языке и уметь правильно преподносить информацию.
Ниже я приведу несколько советов и техник, которые помогут вам проводить созвоны безболезненно и без вреда для сторон. Среди них есть такие вещи как:
Языковой барьер
Рукописи не горят
Дежавю
Помощь зала
Верь в лучшее, готовься к худшему
Заказчик всегда прав
Языковой барьер
"Нужно добавить новый endpoint, базу расширить и мигрировать, еще кафку обновить и покрыть все unit тестами с регрессом, а потом в нагрузку передать. На это две недели нужно"
и
"Нам потребуется две недели, в которые будет входить разработка нового функционала, проверка качества и подготовка к внедрению. После этого пользователям придется выполнять меньше ручных действий, а текущие процессы останутся стабильными".
В первом случае заказчик, далекий от технической стороны, будет слышать просто набор умных, но непонятных для него слов, которые никак не объясняют такой срок. Во втором же случае заказчик получает понятный для него самого ответ, который включает в себя самое главное - что за эти две недели получит бизнес. Да, он все еще может не знать, сколько должна длиться разработка и проверка качества, но звучит это куда более внятно и уверено. А еще он будет знать что говорить, если с него спросят чем там так долго занимаются разработчики.
Давайте рассмотрим пример с дефектом:
"При нагрузке в 100 рпс consumer уходит в timeout, транзакция продолжает висеть, что приводит к ретраю и ошибке по дублированию ключа в базе"
и
"При увеличении количества операций система не успевает обработать платежи вовремя, в результате чего часть клиентов может увидеть задержку платежа или получить ошибку, хотя фактически операция будет выполнена позже."
Итак, что бизнес видит в первом? Да, какая-то проблема есть, но как она повлияет на работу системы и пользователей вообще непонятно, а значит выходим в прод и потом уже разберемся. А что бизнес видит во втором? Жалобы пользователей, потерю денег и репутационные проблемы. С таким раскладом выходить в прод не хочется совсем.
Итак, как же говорить на языке бизнеса?
Использовать общие формулировки без подробных технических деталей (Если, конечно, сам заказчик не запрашивает их)
Описывать процессы со стороны пользователя
Помнить, что ваш заказчик возможно будет вынужден объясняться перед другими, и чем сложнее формулировки, тем сложнее ему будет объяснить причины задержки выхода в прод
Говорить результатами, а не процессами - заказчик должен понимать, какой результат будет получен из работы на которую он тратит деньги
Рукописи не горят
Я не раз бывала в ситуациях, когда каждый созвон вновь и вновь повторялся вопрос о времени, предстоящих работах или вовсе о резких изменениях в них. В такие моменты невольно чувствуешь себя попугаем, с бесконечным "да, неделя, да, четыре воркер ноды, да, неделя, да четыре".
Решение проблемы - документировать всю информацию и обязательно присылать на почту рабочей группе.
Когда будет готово? Вот протокол рабочей встречи, где мы договорились о времени. Сколько у нас памяти? Вот протокол тестирования с конфигурацией окружения. У заказчика изменились требования? И вот снова протокол рабочей встречи, где требования описаны и зафиксированы.
Протоколы рабочих встреч вещь вообще хорошая. И хоть в моменте заполнять документ может быть лень, рано или поздно они придут вам на помощь. Для наглядности приведу ниже шаблон рабочей встречи:
Итак, мы имеем документ, на который можем ссылаться, и который был направлен заказчику на почту для фиксации.
И теперь жить стало чуточку легче, потому как наше "я уже говорил/мы обсуждали" заменяется на "зафиксировано в протоколе рабочей встречи от дд.мм".
Чувствуете, да? Очень важно звучит, очень по-бизнесовому. Так еще и вам не дает забыть важную информацию
Дежавю
Иногда простого объяснения причин бывает мало и несмотря на то, что вы говорите, что новый функционал плохо отразится на пользовательском опыте, заказчик продолжает настаивать на его внедрении. Все мы люди, случается и такое.
Что же делать в таком случае?
Говорить про свой опыт.
Если у вас когда-либо были похожие кейсы, которые привели к проблемам - вы можете использовать их как крайне сильный довод в свою пользу. Расскажите, что именно похожего было и обязательно сделайте акцент на результатах для пользователя (не работало, не открывалось, висло) и бизнеса (недоступность, необходимость в откате и времени на исправление).
Потому как заказчик может не прислушаться ко мнению одного человека и счесть его субъективным, но вот похожая история, повлекшая последствия, может послужить веской причиной смены плана действий.
А если у вас нет своего - говорите про чужой опыт.
Это могут быть кейсы ваших коллег или и вовсе конкурентов, которые уже пробовали делать так, но в итоге отказались от принятого решения. В общем, любая информация, идущая из реальных примеров и опыта, ведет к повышению рисков в глазах заказчика. А чем больше риск - тем меньше хочется и дальше говорить "а давайте все же попробуем".
Помощь зала
Если вы чувствуете, что не справляетесь или у вас нет достаточных инструментов для отстаивания своей позиции - не бойтесь обращаться к коллегам и наставникам. Возможно, они уже сталкивались с такой ситуацией и смогут помочь вам реализовать метод "дежавю".
А даже если и нет - совпадение мнений уже хорошее начало, которое можно преподнести в формате:
"Я обсуждал вопрос с коллегами и мы сошлись в том, что новая функция может привести к ....."
Это не сделает вас менее профессионалом в глазах остальных, а наоборот покажет вашу вовлеченность в процесс.
Или они смогут помочь вам найти хорошее решение вашей нехорошей проблемы :)
Верь в лучшее, готовься к худшему
Как только ты понимаешь, что шанс провальных переговоров высок, начинай готовиться к последствиям.
Выходим в прод с багом? Начинай работать над его решением хотя бы в формате плана
Торопят со сроками без возможности нормально доработать фичу? Допиши ее код даже после дедлайна.
Хотят ввести нецелесообразную функцию? Знай, на что она будет влиять и готовься к откату.
Следует всегда быть готовым к худшему сценарию развития событий и сделать все для экономии собственных нервов, времени и сил.
Да, вы конечно соберетесь на ретроспективу и проведете экстренный созвон, где все будут спрашивать: "а почему так", но самым главным вопросом обязательно будет - "как быстро мы можем все исправить". И если у вас уже будут наработки и понимание, что делать - вы выйдете из этой неприятной ситуации, не то чтобы сухим, но явно не мокрым с ног до головы.
Заказчик всегда прав
Несмотря на всё то, что я перечисляла выше, неизменным остается одно - заказчик всегда прав, даже если у него нет вкуса. Просто потому, что он платит вам деньги, и так устроены реалии рынка.
Во избежание проблем и неприятной атмосферы на рабочем месте лучше отказаться от резких формулировок и прямых указаний на неправоту заказчика. Да, он может быть не прав по фактам и логике, но доносить такую информацию стоит правильным образом. Согласитесь, вам тоже было бы неприятно, если бы сантехник (которому вы уже заплатили!) начал говорить о неправильности выбора цвета для ванны и отказываться от ее установки, пока цвет не будет изменен на бежевый. А рано или поздно вы бы и вовсе задумались о замене специалиста на того, кто не будет говорить вам, что ваши желания и идеи неправильны, а будет делать то, для чего ему заплатили.
Этот пример, конечно, примитивен и между ванной и информационной системой есть как минимум два отличия, но ощущения у заказчика часто схожи.
Потому лучше представить, что вы на очередном собеседовании и включить все свои софт-скиллы, используя предложения и вопросы, а не утверждения.
Ваша идея не сработает -> у этой фичи слишком много рисков, таких как ...
Нужно делать x, а не y -> в сравнении выгоднее и безопаснее использовать x, т.к. ...
Я знаю, как лучше -> на нашей практике уже был такой кейс, и в результате тестов мы опытным путем пришли к решению x
Вы не правы -> напомните, какой результат вы ожидаете от вашей фичи? (И приводить к решению х)
Это не даст профита и займет много времени -> на разработку нужно будет заложить дополнительные дни, и я не могу гарантировать, что результат будет сопоставим с рисками
Важное дополнение
Если у вас дружеские отношения с заказчиком или вам двоим просто подходит более прямолинейный и честный формат, то могу только позавидовать.
Итого, не следует всерьез спорить с заказчиком или доказывать его неправоту. Лучше обойтись мягкими формулировками, предложениями и вариантами, усилив свое мнение предложенными выше вариантами. Сохраните нервы, и себе, и коллегам, и самому заказчику.
Заключение
IT-конфликтология - это в первую очередь не про доказательство правоты, а про то, как правильно и четко доносить свои мысли и идеи до тех, кто говорит на другом языке. Чем больше компания, в которой вы работаете - тем важнее вам овладеть техниками ведения переговоров, дабы упростить жизнь не только вам, но и другим.
То, о чем я говорила в статье - лишь рекомендации, которые полезно иметь в виду, но конечный формат и рабочие способы будут зависеть только от вас и вашего заказчика.
Если у вас есть собственные методы или истории подобного взаимодействия с заказчиками, буду рада почитать о них в комментариях :)
