Да, действительно прийдется приложить больше усилий, особенно на начальных этапах. Как и в любом изучении чего либо нового.
Смысл в том, что любые границы между всеми привычными нам ролями на проекте оказываются на практике размытыми. А если роли разрезаны по жестким границам, то между ними возникают пробелы, которые могут приводить к проблемам. Такие проблемы можно восполнить интересуясь и вовлекаясь в контексты других, смежных ролей. Как я писал не нужно пытаться стать экспертом во всех них (особенно на начальных этапах). В этом случае большее внимание и фокуса все таки остается на инжениринге.
Что касается времени: если смотреть в долгую, то такой подход очень часто может помочь принять более правильные решения на более ранних этапах, сэкономить время, а не итерировать кодом, переделывать и рефакторить по несколько раз. Знание доменной области, бизнес контекста и планов поможет лучше «написать код», который и будет покрывать проблему той самой доменной области.
В тоже время я соглашусь, что очень глубокая техническая экспертиза требует 100% вовлеченности. И тут каждый сам принимает решение в какую сторону расти: глубину или широту.
Теперь попробую поразмышлять на тему основного вопроса о востребованности. Да фиг его знает что будет завтра :)
К сожалению аутсорсинговая IT индустрия, и украинская в частности, очень сильно напоминает сырьевую экономику, где код является ресурсом который добывается и продается. Как и с любым ресурсом, тот кто его произвел и продал, дальше не имеет отношения к тому что из этого ресурса в итоге производят. Это и формирует требования на рынке где все идут самым простым, часто краткосрочным путем. В свою очередь развития продуктового мышления это альтернатива, которая имеет шанс поменять траекторию.
Совершенно верно. Основной смысл развития «продуктового мышления» это расширение горизонта своих знаний, которые в том числе могут помочь, при желании, сменить свою роль.
Спасибо!
Да, действительно прийдется приложить больше усилий, особенно на начальных этапах. Как и в любом изучении чего либо нового.
Смысл в том, что любые границы между всеми привычными нам ролями на проекте оказываются на практике размытыми. А если роли разрезаны по жестким границам, то между ними возникают пробелы, которые могут приводить к проблемам. Такие проблемы можно восполнить интересуясь и вовлекаясь в контексты других, смежных ролей. Как я писал не нужно пытаться стать экспертом во всех них (особенно на начальных этапах). В этом случае большее внимание и фокуса все таки остается на инжениринге.
Что касается времени: если смотреть в долгую, то такой подход очень часто может помочь принять более правильные решения на более ранних этапах, сэкономить время, а не итерировать кодом, переделывать и рефакторить по несколько раз. Знание доменной области, бизнес контекста и планов поможет лучше «написать код», который и будет покрывать проблему той самой доменной области.
В тоже время я соглашусь, что очень глубокая техническая экспертиза требует 100% вовлеченности. И тут каждый сам принимает решение в какую сторону расти: глубину или широту.
Теперь попробую поразмышлять на тему основного вопроса о востребованности. Да фиг его знает что будет завтра :)
К сожалению аутсорсинговая IT индустрия, и украинская в частности, очень сильно напоминает сырьевую экономику, где код является ресурсом который добывается и продается. Как и с любым ресурсом, тот кто его произвел и продал, дальше не имеет отношения к тому что из этого ресурса в итоге производят. Это и формирует требования на рынке где все идут самым простым, часто краткосрочным путем. В свою очередь развития продуктового мышления это альтернатива, которая имеет шанс поменять траекторию.