Обновить

От Job Story к User Story. Часть 1. Введение в связь артефактов и циклов

Уровень сложностиСредний
Время на прочтение4 мин
Охват и читатели1K
Всего голосов 4: ↑4 и ↓0+5
Комментарии7

Комментарии 7

Если бы мне аналитик предоставил бы подобное описание чего-либо, а тем более подобную схему, я бы его уволил.

Добрый день!

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

Только вот этот "аналитик" описаний внятных делать вообще не может. Какой там из него продакт будет - хз.

Спасибо большое! Тоже работаю продактом, но впервые встретила такую чёткую и последовательную логику между фреймворками — читать было правда интересно)

Добрый день!

Благодарю за положительную обратную связь. Продолжаю по мере загруженности работать над следующими статьями.

1) Идея (связи артефактов) интересная и здравая, но вот реализация (в текущей статье) вызывает сомнения

2) Зачем такое количество создаваемых артефактов при продуктовой разработке с жатыми сроками

3) Концептуально не понятно какой команде необходим такой подход

Добрый день!

Благодарю за комментарий. Отвечу также по пунктам:

1) Данная статья является вводной, сама реализация будет описываться в следующих статьях.

2) Согласен, конечно можно и без них, тем более когда сроки сжаты. Однако, количество артефактов выступает необходимой цепочкой, скрепляющей всю разработку. Важно помнить, что на разных этапах жизненного цикла продукта детализация артефактов может быть разной. Если сроки сжаты, следует понизить детализацию, подготовив почву для его возможной декомпозиции и расширения, но не упускать артефакт в целом, т.к. упущенный артефакт понижает способность бизнеса быть гибким и грамотно определять точки роста.

3) Это очень хороший вопрос, и ответ на который вполне может потянуть на отдельную статью. Если кратко, то подойдёт любой команде, которая хочет гибко работать в продуктовой разработке, и в том числе, в проектной разработке при условии, что проект через артефакты сохраняет связь с бизнесом. Однако большинство компаний или пилят проекты, или не готовы тратить дополнительный ресурсы на проработку бизнес-системной архитектуры. И как следствие получается, команды не ассоциируют себя с продуктом, не заинтересованы в установлении связи артефактов и просто сидят на ЗП.
Если же команды следуют логике связи артефактов, обозначенной в данной статье, тогда они вовлечены в бизнес, более качественно получают обратную связь и анализируют результаты своего труда. Проработав данную схему, минимум усилий будет приносить больший результат, и команды будут настроены существовать в долгую.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации