Разработчик сделал ровно то, что вы просили. Разбор
Как-то я совсем запамятовал, что публиковал этот кейс, а значит, пора его разобрать. Давайте последовательно отвечу на все три вопроса.
1️⃣. Что делать прямо сейчас? Что говорить на совете директоров?
В такой ситуации первое, что нужно убрать, — это эмоции и поиск виноватого.
Нужны:
— сухие факты,
— оценка ущерба и аналитика,
— гипотезы причин,
— план стабилизации,
— и план недопущения повтора.
То есть не просто: «сделали А, получили Б» (или «так бывает») а: «сделали А, получили Б, ущерб такой-то, причины видим вот такие, прямо сейчас делаем вот это».
Где-то это называют постмортемом, где-то разбором полётов, но суть одна: не защищаться, а управлять ситуацией. Даже когда корабль тонет — капитан не бегает в панике, а спокойно руководит эвакуацией и последним покидает корабль.
2️⃣. Есть ли вина специалиста, если он сделал всё «по ТЗ»?
Это самый важный вопрос.
Самый простой ответ звучит так: раз менеджер поставил задачу, значит, менеджер и виноват.
И в этом есть большая доля правды. Потому что именно тот, кто ставит задачу и принимает решение о выкатке, в конечном счёте отвечает за результат.
Но есть нюанс.
Исполнитель — не принтер, который просто печатает ТЗ в коде, макетах или документации. Если специалист видел риск, понимал, что решение сомнительное, но ничего не сказал, то часть ответственности на нём тоже есть.
Например, в командах с системной аналитикой в процессах разработчик может получить формально подробную постановку, в которой всё расписано, но по сути решение слабое. Аналитик торопился, задача «должна была уйти в работу» и сроки горели, а в итоге команда просто реализовала то, что было написано.
Формально — все молодцы.
По факту — продукту стало хуже.
С моей точки зрения, чем выше сениорность специалиста, тем выше ожидание, что он:
— задаёт вопросы к постановке,
— подсвечивает риски,
— замечает слабые места в решении,
— и не работает как бездумный транслятор требований в артефакт.
Но тут важно не впасть в другую крайность. Не всякий специалист обязан видеть весь бизнес-контекст. И не всякая ошибка исполнителя равна ошибке постановщика.
Поэтому я бы сказал так:
Основная ответственность за провал — у того, кто формулировал задачу и принимал решение о внедрении. Но зрелый специалист тоже обязан сигнализировать, если видит, что команда идёт не туда.
3️⃣. Где проходит граница ответственности между постановкой, валидацией и внедрением?
Для меня здесь главный принцип такой:
за успех фичи команда отвечает совместно, но виды ответственности внутри этой команды разные.
Мне не близка модель, в которой:
— менеджер «придумывает»,
— аналитик «описывает»,
— дизайнер «рисует»,
— разработчик «кодит»,
— QA «проверяет»,
а за итог как будто бы никто не отвечает целиком. («К пуговицам претензий есть?»)
Если у вас команда, то фича — это общий результат. Каждый, кто к ней прикасался, в каком-то смысле за неё отвечает.
Это не значит, что ответственность у всех одинаковая.
Кто-то отвечает за корректность постановки.
Кто-то — за то, что решение реализуемо и не ломает систему.
Кто-то — за UX и сценарии использования.
Кто-то — за качество проверки и безопасный rollout.
Поэтому правильнее говорить не «виноваты все», а:
ответственность коллективная, но границы личной ответственности разные.
И это, кстати, одна из главных причин, почему хорошие команды жарко спорят до релиза, а не после провала.
Что для меня здесь главное
Самая опасная фраза во всей этой истории — не
«разработчик ошибся», а «он просто сделал, что ему сказали».
Потому что как только команда начинает жить в логике «я сделал свой кусок, дальше не моё дело», и команда, и продукт почти неизбежно начинают деградировать.
