Спасибо за хорошо сформулированные вопросы - всегда рад по существу обсудить!
На рынке найма в РФ в целом до недавнего времени (условно до начала 2025), спрос на разработчиков в целом превышал предложение, так что многие компании были готовы брать более менее знающих техничку ребят, типа а там разберемся. Сейчас немного притормозили, но в целом картина не меняется.
В целом, думаю большинство компаний (особенно крупных вроде банков, страховых, больших интеграторов) строят процессы разработки так, чтобы нанимать больше "простых" технарей. Плюс в найме разработчиков (не лидов) чаще следуют практике "нанимай по хардам - увольняй по софтам", т.е. даже если по факту нужен продуктовый, на входе будут проверять все равно инженерные навыки. Так что уйти от знания технических навыков никак.
С другой стороны есть компании, которые топят за продуктовый подход в головах разработчиков, плюс есть отдельные подразделения в крупных компаниях, которые развивают инновационные продукты в очень конкурентных нишах - и они часто действительно готовы платить больше, в том числе крупных компаний с сильным HR брендов. В РФ есть такие, но еще больше на Западе - хорошие стартапы, скейлапы. Туда не возьмут если не будете вникать в продукт и его цели, ну либо не сработаесь с командой.
С ростом ИИ помощников в разработке, думаю, увеличит именно востребованность разработчиков с одновременно сильным техническим И продуктовыми навыками.
Хорошее замечание. Покопав тему про Вотсап: действительно команда меньше, чем я думал, по крайней мере было - по каким-то источникам в 2016 когда у них было 1 млрд пользователей и 50 инженеров. Я считаю это довольно эффективной командой. Что случилось дальше с командой Вотсапа под новым руководством - я не нашел. Ясно, что продуктовое развитие практически остановилось. Для сравнения Телеграм до сих справляется меньшей командой - держит тот 1 млрд юзеров и делает куда лучший продукт.
Вообще я стартап с mvp привел для примера. Есть много вполне развитого бизнеса такой подход востребован - см telegram, cursor, прочие "scaleup", из российских например dodo, mindbox, плюс куча среднего бизнеса где it продукт уже есть, а горы денег для огромного штата аналитиков и менеджеров нет.
Думаю что "промышленный подход" более распространен. Многие в него пытаются, но получается хорошо у немногих.
Но вопрос в том насколько эффективно он приносит результаты - сравните тот же Телеграм, который создает небольшая команда в пару десятков человек, и Вотсап, который создают сотни инженеров и аналитиков - в котором редактирование сообщений появилось только два года назад, а расшифровывать голосвухи на русском до сих боль.
Почему не будет? Набираю себе таких единорожков в команду и успешно работаю с ними (без галлюциногенов 😄). Общаюсь с коллегами, клиентами - по факту на таких ребятах держится ого-го сколько бизнеса.
В целом не буду спорить - цепочка в стартапах частая: создаем какой продукт, решаем, что его можно переиспользовать для другого рынка, более широкой аудитории, гипотеза оказывется успешная, и вот наш велосипедик должен гнать по трассе под 150км/ч.
Не согласен с вами насчет Facebook, Google, YouTube: все эти продукты хоть и были созданы программистами, но их архитектура и то, как они создавались - было основано на довольно понятных целях чего хотели авторы. Авторы YouTube делали сервис знакомств с видео - от этого им надо было решить как это видео хранить и показывать.
Думаю есть продукты инновационные продукты, которые рождались от того кто-то что-то внезапно изобрел - слышал что есть ученые, которые изучают и проектируют алгоритмы распредленных БД или делают какие-то эксперименты в области машинного обучения - но кажется чаще все куда прагматичнее.
И я не стал бы делить продукты на 100% инновационные и 100% типовые. Да, большинство не пишет БД и языки программирования, не создает сверхнагруженные софт для Гугл, и не обучает новые нейронки, но задач достаточно сложных хватает.
Типа как нарисовать сову? :) Да, возможно попробовать сделать некоторый навигатор по паттернам на основе ответов на ключевые вопросы, но все таки архитектура ПО не такой hard science, как например написание кода, поэтому там всегда будет место для свободного полета мысли.
Ну это, как бы "by design": когда пытаешься вывести принципы - они будут абстрактными. Но я всё таки постарался кратко привести некоторые примеры ошибок и кейсов.
Но думаю может в будущем сделать ещё статью о применении этих принципов на конкретном примере.
2. Разобраться как сценарии будут дружить друг с другом. Это, кстати, решает основную, на мой взгляд, проблему разработки через юзер стори без глубокой проработки — часто сценарии противоречат друг другу и мы в будущем можем очень много проблем из-за этого получить.
Согласен - в тексте документа легче рассказать понятную стройную историю от лица конкретного пользователя.
В классической версии процесса: мы сначала набрасываем юзер стори, можно не детализировать, а оставить просто заголовок, а уже потом, когда нужно описываем критерии приемки до достаточного состояния. Почему вам кажется, что нужно собрать полный документ сразу?
Спасибо за хорошо сформулированные вопросы - всегда рад по существу обсудить!
На рынке найма в РФ в целом до недавнего времени (условно до начала 2025), спрос на разработчиков в целом превышал предложение, так что многие компании были готовы брать более менее знающих техничку ребят, типа а там разберемся. Сейчас немного притормозили, но в целом картина не меняется.
В целом, думаю большинство компаний (особенно крупных вроде банков, страховых, больших интеграторов) строят процессы разработки так, чтобы нанимать больше "простых" технарей. Плюс в найме разработчиков (не лидов) чаще следуют практике "нанимай по хардам - увольняй по софтам", т.е. даже если по факту нужен продуктовый, на входе будут проверять все равно инженерные навыки. Так что уйти от знания технических навыков никак.
С другой стороны есть компании, которые топят за продуктовый подход в головах разработчиков, плюс есть отдельные подразделения в крупных компаниях, которые развивают инновационные продукты в очень конкурентных нишах - и они часто действительно готовы платить больше, в том числе крупных компаний с сильным HR брендов. В РФ есть такие, но еще больше на Западе - хорошие стартапы, скейлапы. Туда не возьмут если не будете вникать в продукт и его цели, ну либо не сработаесь с командой.
С ростом ИИ помощников в разработке, думаю, увеличит именно востребованность разработчиков с одновременно сильным техническим И продуктовыми навыками.
Хорошее замечание. Покопав тему про Вотсап: действительно команда меньше, чем я думал, по крайней мере было - по каким-то источникам в 2016 когда у них было 1 млрд пользователей и 50 инженеров. Я считаю это довольно эффективной командой.
Что случилось дальше с командой Вотсапа под новым руководством - я не нашел. Ясно, что продуктовое развитие практически остановилось.
Для сравнения Телеграм до сих справляется меньшей командой - держит тот 1 млрд юзеров и делает куда лучший продукт.
Ок, по смыслу статьи у вас есть комментарии или вы только картинки смотрите и банальные морали читаете?
Вообще я стартап с mvp привел для примера. Есть много вполне развитого бизнеса такой подход востребован - см telegram, cursor, прочие "scaleup", из российских например dodo, mindbox, плюс куча среднего бизнеса где it продукт уже есть, а горы денег для огромного штата аналитиков и менеджеров нет.
Думаю что "промышленный подход" более распространен. Многие в него пытаются, но получается хорошо у немногих.
Но вопрос в том насколько эффективно он приносит результаты - сравните тот же Телеграм, который создает небольшая команда в пару десятков человек, и Вотсап, который создают сотни инженеров и аналитиков - в котором редактирование сообщений появилось только два года назад, а расшифровывать голосвухи на русском до сих боль.
Ну бывет такое - не спорю, притом работает в определенных контекстах, условный стартап на mvp стадии где только фаундеры и несколько разработчиков.
Но когда аналитик есть, разработчик это очень важный участник работы с требованиями и беклогом.
Почему не будет? Набираю себе таких единорожков в команду и успешно работаю с ними (без галлюциногенов 😄). Общаюсь с коллегами, клиентами - по факту на таких ребятах держится ого-го сколько бизнеса.
Круто! Такая формулировка принципа мне кажется более применимой на практике, чем у Дяди Боба.
PS Мне всегда больше нравился перевод "cohesion", как "согласованность".
В целом не буду спорить - цепочка в стартапах частая: создаем какой продукт, решаем, что его можно переиспользовать для другого рынка, более широкой аудитории, гипотеза оказывется успешная, и вот наш велосипедик должен гнать по трассе под 150км/ч.
Да, согласен пирамидка видимо не удачная метафора тут совсем
Не согласен с вами насчет Facebook, Google, YouTube: все эти продукты хоть и были созданы программистами, но их архитектура и то, как они создавались - было основано на довольно понятных целях чего хотели авторы. Авторы YouTube делали сервис знакомств с видео - от этого им надо было решить как это видео хранить и показывать.
Думаю есть продукты инновационные продукты, которые рождались от того кто-то что-то внезапно изобрел - слышал что есть ученые, которые изучают и проектируют алгоритмы распредленных БД или делают какие-то эксперименты в области машинного обучения - но кажется чаще все куда прагматичнее.
И я не стал бы делить продукты на 100% инновационные и 100% типовые. Да, большинство не пишет БД и языки программирования, не создает сверхнагруженные софт для Гугл, и не обучает новые нейронки, но задач достаточно сложных хватает.
Типа как нарисовать сову? :)
Да, возможно попробовать сделать некоторый навигатор по паттернам на основе ответов на ключевые вопросы, но все таки архитектура ПО не такой hard science, как например написание кода, поэтому там всегда будет место для свободного полета мысли.
Хаха, я только сейчас заметил... Пирамидку хотелось на основание поставить.
Отличная мысль, задача архитектора найти ограничения которые ещё пока не понятны и которые могут ограничить развитие продукта.
Ну это, как бы "by design": когда пытаешься вывести принципы - они будут абстрактными. Но я всё таки постарался кратко привести некоторые примеры ошибок и кейсов.
Но думаю может в будущем сделать ещё статью о применении этих принципов на конкретном примере.
Почему вы менеджера переименовали в продюсера? Все ведь любят менеджеров :)
а чем тимлид в вашем понимании занимается, если не руководит разработчиками и процессами разработки?
вы что-то имеете против пропаганды?
Спасибо за подробный ответ!
Согласен - в тексте документа легче рассказать понятную стройную историю от лица конкретного пользователя.
В классической версии процесса: мы сначала набрасываем юзер стори, можно не детализировать, а оставить просто заголовок, а уже потом, когда нужно описываем критерии приемки до достаточного состояния. Почему вам кажется, что нужно собрать полный документ сразу?
TIL что такое "дисфемизм", спасибо!