Pull to refresh

Comments 12

Разработчик интересуется чем занимается бизнес конкурент своего работодателя 🥵

А ещё должен петь, танцевать, прыгать, бегать и делать двойное сальто.

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

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

Разделение ответственности существует не потому что "так надо", а потому что никто не хочет работать одновременно на трёх работах и нести всю эту ответственность за 100 тысяч в какой.

Вот тебе пример: маркетплейсы.

Разработчику в WB будет полезно знать как устроина аналогичная фича или контракт в Озон и ЯМ.

Более того скажу тебе, что по факту внутри компаний выделяется ресурс на ресерч функционала и api конкурентов.

Подытожим статью:

Вместо развития экспертизы в написании кода вы предлагаете развивать экспертизу в бизнесе. Не беда, что код станет из говна и палок.

Контакт с бизнесом и пользователями - очень удобно, когда разработка, поддержка и колл центр в одном флаконе.

Коммуникация с пользователями - это маркетинг.

Какая несусветная чушь. Если вы готовы платить за такого спеца 1.5+ млн, то ок. А за +50к к ЗП это ж насколько нужно быть отбитым, чтобы такое предлагать.

Вместо развития экспертизы в написании кода вы предлагаете развивать экспертизу в бизнесе

У core developers такая экспертиза развивается и это хорошо. Я из таких.

Энтерпрайзу не очень нужна скорость разработки, ему нужна стоимость длительного развития и сопровождения. Лет на 10-15. И тут совсем не то что в стартапах fast ship, fix later

Опять серебряную пулю нашли? Чем больше у человека областей ответственности, тем хуже он в них разбирается. В итоге код из говна и палок, бизнес метрики непонятно что и для чего меряют и ещё и пользователям на интервью нагрубил.

С одной стороны - поддержу. За много лет общения с бизнесами - я пришел к выводу что концепция "извлечения требований" как база для построения ИТ-решений - глубоко ошибочная. Она исходит из того, что где-то в пространстве идей УЖЕ существует совершенная система с совершенными требованиями к ней. И наша задача - найти правильных людей, и лестью, угрозами, правильными вопросами, и я не знаю чем еще - но заставить их выдать нам это тайное знание.

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

С другой стороны - один разработчик это прямо ой как опасно! Bus-фактор=1 для бизнеса - это неприемлимо... Давайте хотя бы троих для redundancy ?!

Не надо собирать существующие требования. Нужно менять бизнес процессы. ИТ драйвит бизнес, создаёт ему новые конкурентные преимущества.

30-минутного звонка с заказчиком […]

Взоржал так, что соседи прибежали.

▸ У хорошего разработчика нет времени общаться с заказчиком, для этого есть зайчики со значительно более дешевым рабочим временем.
▸ Плохого разработчика нельзя допускать к заказчику: он и там облажается, и передаст из него так себе.

Если вы пишете про «Рога и копыта» на три калеки — так и обозначайте в самом начале. А если про более-менее адекватный стартап с какими-никакими надеждами выжить — то вам (вашей ллмке, точнее) явно не хватает экспертизы.

Тут под заказчиком может имеется ввиду "бизнес". То есть общение разработчика напрямую с product manager даст больше пользы, чем через прослойку в виде "аналитика" и т.п.

Всё-таки тег "юмор" к статье где-то потерялся, да ещё и уровень сложности средний...

Боюсь, что с появлением AI-агентов 80% разработчиков придется переквалифицироваться в бизнес-аналитиков или создателей всяких мультимедиа, или вообще стать бизнесменами вокруг, например, своего приложения. Так что посыл правильный: ребята становитесь бизнесами, пока не поздно.

  • Для этого ему не нужен аналитик. Он отлично понимает предметную область сам.

Все так. По факту у нас в компании аналитики лишь описывают то что уже реализовано в коде.

Иначе придется ждать месяцами пока они будут рожать требования и алгоритмы. И потом тебе как ужаленному все реализовывать в оставшиеся сутки до дедлайна.

Со статьей полностью согласен. Тоже самое наблюдают у себя.

Sign up to leave a comment.

Articles