🦁 Укротить строптивого (,) нельзя (,) помиловать 🦁

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

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

🏓 В первом подходе мы честно пишем письма, где подробно излагаем обнаруженное и просим принять решение. Ничего не делаем с релизом, пока явного «ОК» или пересогласования макета не получим. В таком случае наши руки чисты, но сам релиз в результате может очень надолго отложиться, просто в силу процессов согласования на стороне заказчика, процедуры выставления ТЗ на тендер, конкурса КП и прочей мути. А фича так и не увидит прода, простой приведёт к упущенной выгоде, и где-то в конце клубка заказчик потеряет деньги. И может вдруг решить перестать с нами сотрудничать.

🏹 Во втором подходе мы робингудим в пользу бедных пользователей, да и бизнеса тоже. Берём на себя ответственность за то, что другой дизайн не повлияет на функциональность, зато релизим вовремя. Здесь мы рискуем быть отрицательно умными и загубить какую-нибудь метрику заказчику, которую он хитромудро предусмотрел улучшить конкретным макетом. Однако если же нашей экспертности хватило, то и волки целы и загорелы, и овцы сыты денежным траншем за случившийся релиз. А если заказчик доволен, то мы будем сыты и в будущем. АУФ.

🏹 Да, нюансов в каждом методе больше, чем цитат <сос мыслом>, но всё же интересно провести эксперимент: а как бы поступили вы? Голосуйте в опросе ниже и оставляйте комментарии к посту.

#мысли | Analyst Boost