📌 Лучшие практики - самая дорогая фраза в бизнесе

Архитектор добавляет еще один слой абстракции. Бизнес-аналитик вписывает в требования еще один пункт «на всякий случай». Системный аналитик добавляет в схему интеграции еще один сценарий «чтобы потом было проще». Разработчик пишет свою версию паттерна вместо простого решения, потому что «так правильнее». Спрашиваешь зачем - везде один ответ: «так принято», «лучшие практики так велят».

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

Разница не в том, кто из них честнее. Разница - в цене ошибки.

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

Особенно когда сроки уже согласованы и зафиксированы, а наверху проектируют так, будто их не существует.

Бизнес обозначил дедлайн. Команда под него распланировала работу. И тут приходит архитектура с дополнительным слоем «для гибкости» и требования с обвесом «для полноты картины» - под сценарии, которых пока нет и, возможно, не будет. На вопрос «мы вообще успеваем к сроку с этим?» - тишина, потому что вопрос сроков не входил в рамку, в которой это проектировалось.

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

Каждый лишний адаптер на схеме, каждый «докрученный» пункт в требованиях - это не просто красивая деталь. Это код, который нужно написать, покрыть тестами, задокументировать и поддерживать годами ради сценария, которого может не случиться никогда. Внутри уже прибитого срока это не забота о качестве - это решение потратить чужое время на свою эстетику. И чем выше по цепочке принято это решение, тем дороже оно обходится бизнесу.

Правило простое для всех: необходимо и достаточно. Не «максимально гибко». Не «с запасом на будущее, которое мы себе придумали». Ровно то, что закрывает задачу бизнеса в тех рамках, которые бизнес обозначил.

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

#менеджмент #архитектура #эффективность

@fokin_media