Бизнес - контекст

Часто ли вы слышите тезис, что команда разработки обязана разбираться в бизнес - контексте продукта, который она разрабатывает? В какой - то момент это стало прям мантрой. Хотя, на мой взгляд, это больше отдает карго - культом. Ниже объясню почему.

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

Спасибо, капитан.

Но что на самом деле значит понимать бизнес - контекст? Насколько это важно? Это важнее того, что фронтендер сможет настраивать CI пайплайны? Или все таки пайплайны для разработчика важнее? Где грань, которая покажет, что вот сейчас фронтендер уже нормально погружен в бизнес - контекст и дальше уже можно позволить разработчику разбираться в пайплайнах?

К сожалению, на эти вопросы вам не дадут четкого ответа.

Лично я думаю, что бизнес - контекст своего продукта (и только его) нужно знать ровно настолько, насколько это нужно для успешного закрытия спринта или реализации конкретной фичи. Ни больше и ни меньше. Ты понимаешь как конкретно эта кнопка, которую ты сейчас разрабатываешь, будет использоваться пользователями? - Достаточно. Больше разработчику не нужно.

Вы можете со мной поспорить, но разработчику, зачастую, абсолютно фиолетово как данная кнопка, по нажатию которой должен вызваться ендпойнт, промапиться данные, сработать обработчик и далее произойти рендер, позволит бизнесу поднять бабла. Ему нет до этого дела. Он выполнил задачу, сделал это красиво с точки зрения кода, прокачал свои навыки и, следовательно, стал ценнее как специалист.

Все. Для него это главное.

Поэтому, если вы требуете чтобы команда была глубоко погружена в бизнес - контекст, объясните причину, по которой это необходимо. Конкретизируйте, в каком именно месте разработчику нужно понять бизнес - контекст и для чего. Потому что иначе эта фраза ничем не отличается от пустых, карго культных, клешеных шаблонов в духе “нам нужно сфокусироваться на задачах” или “нам нужно улучшить ттм” или “нам нужно прозрачнее подходить к планированию”. Без конкретики это пустые тезисы, которые нужны ровно для одного - показаться умным и растянуть эфирное время встречи.

Ну и да, глубина погружения в бизнес - контекст прямо пропорциональна роли, которую вы занимаете. Чем выше эта роль, чем больше на вас ответственности и чем шире ваша зона импакта на продукты, тем больше вам необходимо погружаться в бизнес - контекст.

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

Если говорить про бизнес логику, то фича поставленная корректно, снимает с разработчика ответственность за правильность бизнес логики с точки зрения бизнеса, а на разработчике остаётся ответственность за как раз ее реализацию. Ответственность за корректность бизнес логики лежит на продакте и его аналитиках.