Разговоры в курилке: как продать клиенту рефакторинг?
Знакомая картина: сроки горят, фича нужна «еще вчера», и команда лепит костыли на скорую руку. Главное — успеть сдать, а там разберемся.
Но давайте честно: рано или поздно в курилке любого проекта всплывает этот неловкий вопрос: «Как признаться, что в нашем коде всё... не очень хорошо?»
Сценарий ведь стандартный. Команда в спешке выкатывает фичу. Костыли скрипят, гидратация умоляет о пощаде, но фича работает, и заказчик её успешно принимает. Все выдохнули и честно поставили «TODO: поправить позже». А через месяц приходит следующая задача, и выясняется: чтобы прикрутить к этому Франкенштейну новую кнопку, нужно снести половину старого кода и переписать всё заново.
И тут команда упирается в глухую стену:
1. Делать за свой счет? Писать код по ночам в свободное время ради «чистого искусства» дураков нет. 2. Продать заказчику рефакторинг? А как объяснить человеку, далёкому от IT, почему фича, за которую он уже заплатил месяц назад, вдруг требует ещё 40 часов оплачиваемой разработки?
Я сам напрямую с клиентами не общаюсь (я всё-таки разработчик), но отголоски этих жарких споров регулярно долетают до команды. И вариантов решения обычно всего три:
- Вариант «Партизанский» (Самый частый): Раздуть оценку новой фичи в два раза и втихаря засунуть туда переделку старых косяков. Минус — если менеджер со стороны заказчика умеет считать, возникнут вопросы, почему «простая формочка» стоит как крыло от самолёта.
- Вариант «Героический»: Тот самый, из курилки — «Хочешь сделать нормально? Делай в своё личное время, а мы тебе спасибо скажем». (Спойлер: не работает, приводит к выгоранию).
- Вариант «Честный» (Утопический): Прийти и сказать: «Мы поторопились, сделали костыль, теперь надо исправлять». Но признаваться в собственных косяках стыдно, да и репутацию студии/команды подставлять никто не хочет.
В итоге проблемы часто просто консервируются, пока проект не начнёт разваливаться под собственным весом.
А как в ваших командах решается этот вопрос? Менеджеры честно продают рефакторинг или разработчики молча «размазывают» исправление старых багов по оценкам новых тасок? 👇
· 39 мин
Классика жанра: заказчику нужен MVP, чтобы просто проверить концепцию или гипотезу. В итоге менеджеры и заказчик в полном восторге: «Все круто, все работает!». Пытаешься объяснить, что этот код собран из палок и его нельзя пускать в прод — но тебя никто не слышит, ведь «зачем трогать, если летает?». В итоге этот временный прототип плавно становится финальной архитектурой всего проекта 🫠 Знакомо?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён