Pull to refresh

Comments 12

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

UFO landed and left these words here

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

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

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

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

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

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

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

Sign up to leave a comment.

Articles