Менеджеры, которые соглашаются и продавливают подход «х**к х**к и в продакшн»
— это редкостные сволочи, которых нужно вечером встречать у парковки и
проводить беседу на тему best practices in project management.

А инженеры, которые дают себя продавить — ..., впрочем, они сами себя уже наказали.

Почему такой подход работает:
Этот подход не работает на серьезных проектах. И вот почему.
К менеджеру приходит продакт и говорит — у нас есть о**ительная идея фичи,
которая нужна очень важному клиенту.

Есть 2 варианта:
1) Ad-hoc решение, что займет 1 час
2) Собрать полностью требования, сделать нормальный дизайн, нормальную
реализацию (50 часов)

Если менеджер в этот момент выбирает первый вариант, он запускает процес,
который очень медленно, но неотвратимо приведет к неотвратимому плохому концу.
Как только мы делаем фичу в ковбойском стиле (захардкорить чей-то ID-шник в
коде, 2 раза в день выполнять ad-hoc запрос на продакшн базе, отключить
входную валидацию чтоб пропустить какой-то высокоприоритетный запрос, тысячи
их), мы берем на себя технический долг, по которому должны платить проценты
каждый день рабочим временем инженеров.

Сегодня захардкордили ID-шник одного клиента.
Завтра скажут что нужно запустить еще одного клиента.
Когда через неделю скажут запустить 11-го клиента, кто-то спросит, какого
фига, ему ответят — вы смогли запустить 10 клиентов, значи 11-го тоже
запустите без редизайна системы.

И инженер будет добавлять 11-й ID-шник в код и деплоить на продакшн.
Поскольку фича со стороны выглядит «complete», отказаться онбоардить 50-го
клиента будет намного сложнее, чем отказаться онбоардить первого, так как на
эту фичу уже рассчитывает бизнес, клиенты, уже есть план по ее использованию.
Дальше ситуация становится еще хуже.

Поверх этого костыля строится инфраструктура и процес. Отдельная папка в
джире, в которую заводятся тикеты по онбоардингу, появляется запланированный
ежедневный деплоймент только для обновления списка кастомеров, на скорую руку
пишется скрипт, который генерирует и обновляет этот список, заводится
еженедельный митинг, посвященный этому вопросу, появляется выделенный
специалист в каждой команде, который занимается этой «фичей» Т.е. строятся
костыли вокруг костыля, которые его поддерживюат и как-то упрощают,
стабилизируют и формализируют порцес, тем самым цементируя это решение.

Наши инженеры теперь постоянно совершают какие-то операционные действия для
поддержания этой фичи и мы теряем velocity.
Поскольку все это не было нормально задизайнено, а вместо этого
разрабатывалось мелкими итерациями, слабо согласованными друг с другом, все
решение получается очень хрупким и потихоньку начинает рушиться. Появляются
баги и проблемы на продакшене, нарушаются SLA. Кто решает эти проблемы?
Правильно, инженеры, которые теперь не только должны заниматься операционными
вопросами вместо разработки, но еще и должны поддерживать разваливающийся в
продакшене сервис.
Теперь мы имеем инженеров, которые регулярно пишут код для поддержки этой
фичи, и мы теряем еще больше velocity.
Когда наш velocity упадет до нуля — это вопрос времени, и чем позже это
случится, тем хуже будет для всех.

После этого один из инженеров говорит fuck this shit и уходит из команды,
унося с собой часть уникальных знаний о том, как все это было сделано.
Берется новый инженер, которого начинают вводить в курс. Когда он задает
вопрос «какого хрена это сделано через жопу», тогда и произносится та самая
фраза — мы так делаем последние полгода, просто смирись.
Теперь уже не составит труда выбить бюджет на нормальный дизайн этой фичи. Не
потому, что инженеры заипались, не потому, что менеджер становится более
принципиальным, а потому что все заинтересованные лица видят, что эта фича
работает через жопу, сайт постоянно падает и лежит по несколько часов пока его
не поднимут, и они сами скажут — возьмите и сделайте нормально.

Проблема в том, что теперь сделать нормально не так просто. Этот костыль, как
раковая опухоль, начал распространяться по коду, на появляется зависимость на
него от других компонентов сервиса, и даже хуже — от других сервисов.
Появляются несогласованные невалидные данные, причем они расползаются по
разным источникам, о которых не все помнят, часть данных к тому времени уже
будет утеряна.
================================================
Итог — фича, на которую при нормально подходе потратили бы 50 часов уже
потрачено 2000 часов только инженеров, и нужно будет потратить еще минимум 500
часов для полного редизайна. Убытки, которые понесли из-за нестабильной работы
еще можно посчитать, а убытки, котоыре понесли из-за того, что инженеры
занимались ерундой вместо запуска новых фич — вряд ли.