Ориентация на бизнес
Короче, у меня давно крутилось на языке, но только щас я смог сформулировать. Обычно же как, все говорят, что надо быть ориентированным на бизнес, что задача программиста решать проблемы, а не код писать. Но когда дело доходит до реальной работы, понимание что такое ориентация на бизнес, начинает резко отличаться у разных людей (и сильно зависит от компании).
Самая распространенная точка зрения, что делать для бизнеса это понять что от нас хотят, доуточнить все требования, может предложить какие-то улучшения и качественно, в срок реализовать и задеплоить. От синьора ждут, что он не просто будет делать что-то о чем попросили, но и критически на это посмотрит.
В этой схеме есть одна проблема, она работает только в идеальном мире, там где люди спускающие задачи сверху делают ровно то, что надо для бизнеса. А вот это вообще не так. Я вам более того скажу, когда ты сам принимаешь свои решения в бизнесе, тебе некуда пойти и уточнить у кого-то требования, никто тебе не скажет ты в правильную сторону идешь или нет.
Поэтому каждая штука, которая придумывается на этом уровне, почти всегда является гипотезой с непонятным выхлопом. А дальше происходит следующее, на самом верху придумали концепцию, дальше по цепочке ниже ее начинают развивать и в какой-то момент она превращается в задачу, которую надо сделать (на уровне менеджеров). При этом люди, которые это придумывали, вообще не хотели делать сложно, долго и дорого, но они почти наверняка не понимают во что может вылиться с точки зрения разработки и главное поддержки та или иная просьба. Яркий пример это поддержка какого-нибудь вида оплаты. Типа а чо бы не добавить? Ну и начинают там все это добавлять, а то что потом, изменение биллинга в целом усложняется в разы, потому что добавление каждого нового способа, скорее всего растит сложностей всей системы и изменение в одном месте, потребует по цепочке менять все. Но так как задача ушла далеко от самого верха, то на уровне исполнителей она воспринимается как нужно сделать обязательно и сделать качественно, поэтому сбор требований, совещания, аналитики, тестировщики и понеслась. Но такое происходит даже там, где цепочка между фаундерами и программистами гораздо меньше. Достаточно одного человека по середине и все, восприятие задач уже такое, что раз надо значит надо.
Реальное же участие в бизнесе, это все таки понять, а почему мы вообще решили это сделать? Речь конечно не про всякую мелочь в стиле добавить фильтрацию в админке, а про какие-то более серьезные, влияющие на бизнес. Например кто-то решил, что давайте добавим реферальную программу. Вот кто тут должен придумать как ее добавить и что она будет из себя представлять? А вариантов тут просто тьма, от берем готовые решения чтобы быстро затестить, до фигачим неделями все это у себя, делая админку для рефералов с автоматической выплатой (по сути создаем полноценный сервис).
Например в таких ситуациях, я часто вижу, что те же разработчики, могут начать делать такую систему, даже не попытавшись посмотреть, а как оно вообще реализовано в аналогичных проектах. Можно так делать? Да сплошь и рядом, но только это не очень сильная ориентация на бизнес. Если не видеть как это делают другие, то вероятность принять правильное решение, не усложнять, не придумывать всякую фигну стремится к нулю.
Тут можно сказать, что чот перебор, для этого есть аналитики и продакты и им платят очень немало за такое, а еще у них часто KPI прямо на деньги (это очень хорошо, когда продакт зарабатывает зарабатывая для компании). Но конкретно с разработкой тут есть проблема, для всех людей со стороны это черная магия. Оценить со стороны стоимость решения, а, что еще важнее, его дальнейшее сопровождение ну просто нереально. Поэтому они легко могут нафантазировать фигню, которая всех займет и у всех будет работа и митинги и ревью и ретроспектива. Только все это по факту ни к чему не приведет, кроме доп геммороя и давайте еще наймем 10 человек, а то не справляемся. =>
Короче, у меня давно крутилось на языке, но только щас я смог сформулировать. Обычно же как, все говорят, что надо быть ориентированным на бизнес, что задача программиста решать проблемы, а не код писать. Но когда дело доходит до реальной работы, понимание что такое ориентация на бизнес, начинает резко отличаться у разных людей (и сильно зависит от компании).
Самая распространенная точка зрения, что делать для бизнеса это понять что от нас хотят, доуточнить все требования, может предложить какие-то улучшения и качественно, в срок реализовать и задеплоить. От синьора ждут, что он не просто будет делать что-то о чем попросили, но и критически на это посмотрит.
В этой схеме есть одна проблема, она работает только в идеальном мире, там где люди спускающие задачи сверху делают ровно то, что надо для бизнеса. А вот это вообще не так. Я вам более того скажу, когда ты сам принимаешь свои решения в бизнесе, тебе некуда пойти и уточнить у кого-то требования, никто тебе не скажет ты в правильную сторону идешь или нет.
Поэтому каждая штука, которая придумывается на этом уровне, почти всегда является гипотезой с непонятным выхлопом. А дальше происходит следующее, на самом верху придумали концепцию, дальше по цепочке ниже ее начинают развивать и в какой-то момент она превращается в задачу, которую надо сделать (на уровне менеджеров). При этом люди, которые это придумывали, вообще не хотели делать сложно, долго и дорого, но они почти наверняка не понимают во что может вылиться с точки зрения разработки и главное поддержки та или иная просьба. Яркий пример это поддержка какого-нибудь вида оплаты. Типа а чо бы не добавить? Ну и начинают там все это добавлять, а то что потом, изменение биллинга в целом усложняется в разы, потому что добавление каждого нового способа, скорее всего растит сложностей всей системы и изменение в одном месте, потребует по цепочке менять все. Но так как задача ушла далеко от самого верха, то на уровне исполнителей она воспринимается как нужно сделать обязательно и сделать качественно, поэтому сбор требований, совещания, аналитики, тестировщики и понеслась. Но такое происходит даже там, где цепочка между фаундерами и программистами гораздо меньше. Достаточно одного человека по середине и все, восприятие задач уже такое, что раз надо значит надо.
Реальное же участие в бизнесе, это все таки понять, а почему мы вообще решили это сделать? Речь конечно не про всякую мелочь в стиле добавить фильтрацию в админке, а про какие-то более серьезные, влияющие на бизнес. Например кто-то решил, что давайте добавим реферальную программу. Вот кто тут должен придумать как ее добавить и что она будет из себя представлять? А вариантов тут просто тьма, от берем готовые решения чтобы быстро затестить, до фигачим неделями все это у себя, делая админку для рефералов с автоматической выплатой (по сути создаем полноценный сервис).
Например в таких ситуациях, я часто вижу, что те же разработчики, могут начать делать такую систему, даже не попытавшись посмотреть, а как оно вообще реализовано в аналогичных проектах. Можно так делать? Да сплошь и рядом, но только это не очень сильная ориентация на бизнес. Если не видеть как это делают другие, то вероятность принять правильное решение, не усложнять, не придумывать всякую фигну стремится к нулю.
Тут можно сказать, что чот перебор, для этого есть аналитики и продакты и им платят очень немало за такое, а еще у них часто KPI прямо на деньги (это очень хорошо, когда продакт зарабатывает зарабатывая для компании). Но конкретно с разработкой тут есть проблема, для всех людей со стороны это черная магия. Оценить со стороны стоимость решения, а, что еще важнее, его дальнейшее сопровождение ну просто нереально. Поэтому они легко могут нафантазировать фигню, которая всех займет и у всех будет работа и митинги и ревью и ретроспектива. Только все это по факту ни к чему не приведет, кроме доп геммороя и давайте еще наймем 10 человек, а то не справляемся. =>
101👍61❤27🔥9🤔2💩2😴2
Начинаем серию прожарки фреймворков для тех кому интересно, что происходит в других стеках. Сегодня говорим про spring boot https://youtu.be/ElzbKGKjDrU?si=4rjFUinqkQFUQUJ4 (прошу прощения за звук, у меня был включен не тот микрофон)
YouTube
Прожарка: Стоит ли писать на Spring Boot в 2026? | Валерий Жила | №65
Spring Boot — один из самых популярных фреймворков в экосистеме Java. Вместе с Валерием Жилой поговорили о том, как он устроен, почему вокруг него столько споров и насколько оправдано его использование сегодня. Разобрали фреймворк с разных сторон — от удобства…
🔥31👍11❤4🤔3