Вы не поверите, но 1С начинался именно с разработчиков, которые садились вместе с бухгалтером и настраивали\дорабатывали.
Перегорают обычно от оверлоада, а не от разнообразия задач, тут тоже проблема в процессах
И не надо того, кто все все умеет, просто и разработчик и инженер по качеству должны понимать, что и как они делают для бизнеса, тогда и бизнесу будет сложно всякую дичь пропихивать. Заметьте, разработчик и инженер по качеству, а не кодер и тестировщик. И да, им аналитик не нужен, они сами умеют головой думать
вот тут вы подсветили проблему сломанных процессов. По факту - аналитик, это просто затыкание дырки в процессе лишним человеком, про это автор и писал. Это простой и в моменте дешевый способ. Стратегически более верно будет вовлекать разработчика в бизнес процессы. Но для этого надо нанимать разработчика, а не кодера)
Поэтому, во первых, я уже не преподаю по направлению СА.
Мой курс, который я создал и 4 года вел на Отусе выгодно отличался от других именно там, что давал не только базу по СА, но и фактически перенаправлял аналитиков в сторону архитектуры и проектирования решений.
Все мои текущие учебные проекты направленны в сторону продуктового и бизнесового развития для аналитиков и технических специалистов.
Так что я считаю, что я абсолютно честен с аудиторией
Вопрос и к Дмитрию и к комментатору: а зачем системные взаимодействия описывать в BPMN? Напомню, что BPMN - это Business Process Model and Notation. То есть сразу в названии, что это бизнес процессы, а не системные. Соответственно системный взаимодействия из С4 абсолютно правильно описывать в сиквенсе
Все пытался понять, почему всю статью мы вроде про продукты, но нет - про проекты. А потом увидел подпись автора - Head of PMO и все встало на свои места, проджекты в подавляющем большинстве не умеют в продукт, они не умеют в ценность, они только про сроки и бабки.
Очень сильно выдает незнание терминологии, например, growth team - это не команда, которая создает продукт. Growth - это команда, которая растит уже существующий продукт, который доказал свою эффективность и потребительскую ценность, но уперся в некоторый потолок развития и ему нужен новый качественный скачок, они занимаются в первую очередь оптимизацией продукта: SEO, пользовательские пути, поиск узких мест в конверсии.
Второй момент, который выдает незнаение предмета с головой - это предложение поделить на две команды: дизайн и разработку. Узнаю проджекта! Но так делать нельзя, вы должны поделить задачи вертикально между командами, а не горизонтально, иначе не будет синергии кросс-функциональной команды, да и информация будет теряться.
И в целом, вопрос нужна ли вам продуктовая команда имеет очень короткий ответ - нужна, если вы пилите продукт. То есть сам вопрос и проблематика поставлены идеологически не верно. Хотя, возможно, цель статьи как раз и была навести потенциальных заказчиком на вывод, что не нужна, а надо брать проекты в Agima? Но как по мне, так все равно не получилось.
Вы не поверите, но 1С начинался именно с разработчиков, которые садились вместе с бухгалтером и настраивали\дорабатывали.
Перегорают обычно от оверлоада, а не от разнообразия задач, тут тоже проблема в процессах
И не надо того, кто все все умеет, просто и разработчик и инженер по качеству должны понимать, что и как они делают для бизнеса, тогда и бизнесу будет сложно всякую дичь пропихивать. Заметьте, разработчик и инженер по качеству, а не кодер и тестировщик. И да, им аналитик не нужен, они сами умеют головой думать
вот тут вы подсветили проблему сломанных процессов. По факту - аналитик, это просто затыкание дырки в процессе лишним человеком, про это автор и писал.
Это простой и в моменте дешевый способ.
Стратегически более верно будет вовлекать разработчика в бизнес процессы. Но для этого надо нанимать разработчика, а не кодера)
согласен, но такой аналитик как правило вообще не имеет отношения к ИТ
Согласен, абсолютно не честно.
Поэтому, во первых, я уже не преподаю по направлению СА.
Мой курс, который я создал и 4 года вел на Отусе выгодно отличался от других именно там, что давал не только базу по СА, но и фактически перенаправлял аналитиков в сторону архитектуры и проектирования решений.
Все мои текущие учебные проекты направленны в сторону продуктового и бизнесового развития для аналитиков и технических специалистов.
Так что я считаю, что я абсолютно честен с аудиторией
На первый взгляд и правда дешевле. Но в какой то момент появляется налог на коммуникации и вот тут становится уже не так дёшево и выгодно
Да, говорил и продолжаю говорить. А ответ получился каким то совсем не убедительным, ну или вы больше себя убеждаете)
Особенно про затычку интересно получилось - мне вот как раз всегда как-то не нравилось быть затычкой)
Насчет дешевой замены разработчику тоже спорно - оклады практически сравнялись, если у вас не так, у меня для вас плохие новости.
Лоу код оставим в стороне - там не аналитик нужен, а специалист по внедрению, профессия смежная, но отдельная.
Вайб-кодинг - тут полезно инженерное мышление, но аналитик как раз становится совсем не нужен, ТЗ писать не надо)
Так что, повторюсь, ответ достаточно спорный)
Выглядит, как будто вы просто переписали классическое ТЗ в формате User Story. Потеряли легкость US и полноту ТЗ
Вы серьезно не понимаете разницы между бизнес процессом и Use Case?
Вопрос и к Дмитрию и к комментатору: а зачем системные взаимодействия описывать в BPMN? Напомню, что BPMN - это Business Process Model and Notation. То есть сразу в названии, что это бизнес процессы, а не системные. Соответственно системный взаимодействия из С4 абсолютно правильно описывать в сиквенсе
За продуктом, очевидно, не в Agima
Все пытался понять, почему всю статью мы вроде про продукты, но нет - про проекты. А потом увидел подпись автора - Head of PMO и все встало на свои места, проджекты в подавляющем большинстве не умеют в продукт, они не умеют в ценность, они только про сроки и бабки.
Очень сильно выдает незнание терминологии, например, growth team - это не команда, которая создает продукт. Growth - это команда, которая растит уже существующий продукт, который доказал свою эффективность и потребительскую ценность, но уперся в некоторый потолок развития и ему нужен новый качественный скачок, они занимаются в первую очередь оптимизацией продукта: SEO, пользовательские пути, поиск узких мест в конверсии.
Второй момент, который выдает незнаение предмета с головой - это предложение поделить на две команды: дизайн и разработку. Узнаю проджекта! Но так делать нельзя, вы должны поделить задачи вертикально между командами, а не горизонтально, иначе не будет синергии кросс-функциональной команды, да и информация будет теряться.
И в целом, вопрос нужна ли вам продуктовая команда имеет очень короткий ответ - нужна, если вы пилите продукт. То есть сам вопрос и проблематика поставлены идеологически не верно. Хотя, возможно, цель статьи как раз и была навести потенциальных заказчиком на вывод, что не нужна, а надо брать проекты в Agima? Но как по мне, так все равно не получилось.