Пользовательские истории устарели?
На собеседованиях часто спрашивают шаблон пользовательских историй.
Типичный пример: "Как пользователь, я хочу кнопку "Экспорт в PDF", чтобы распечатать отчёт". (а зачем этот отчёт нужен и почему именно в PDF?)
Но часто ли аналитики используют такой шаблон на практике? Насколько это удобно?
Я считаю формат пользовательских историй нежизнеспособным в большинстве доменов из-за нескольких проблем:
1. Истории фокусируются на решении, а не на потребности, которую можно закрыть разными способами. Формат истории подталкивает к описанию интерфейса;
2. История атомарна, она не содержит информации, какие части системы затрагивает, на какие другие истории влияет. Например, разбивая функциональность настройки уведомлений на 15 разных историй (почта, пуш, смс, настройки...) слишком легко потерять видение сквозного сценария;
3. В большинстве доменов, где работают системные аналитики, пользователь не "хочет что-то сделать", а участвует в сложном процессе с регуляторными ограничениями, исключениями и последствиями ошибок, большим числом развилок бизнес-процесса. Использование истории в таком домене - излишнее упрощение.
Что подходит лучше?
1. Jobs-to-be-Done - практика, когда нужно понять цели бизнеса и расставить приоритеты, если требуется;
2. Поиск решений для каждой отдельной цели: мозговой штурм, дерево решений, и т. п.;
3. Краткое описание фичи или сценария с возможными исключениями и нефункциональными требованиями.
А вам нравится формат историй?
На собеседованиях часто спрашивают шаблон пользовательских историй.
Типичный пример: "Как пользователь, я хочу кнопку "Экспорт в PDF", чтобы распечатать отчёт". (а зачем этот отчёт нужен и почему именно в PDF?)
Но часто ли аналитики используют такой шаблон на практике? Насколько это удобно?
Я считаю формат пользовательских историй нежизнеспособным в большинстве доменов из-за нескольких проблем:
1. Истории фокусируются на решении, а не на потребности, которую можно закрыть разными способами. Формат истории подталкивает к описанию интерфейса;
2. История атомарна, она не содержит информации, какие части системы затрагивает, на какие другие истории влияет. Например, разбивая функциональность настройки уведомлений на 15 разных историй (почта, пуш, смс, настройки...) слишком легко потерять видение сквозного сценария;
3. В большинстве доменов, где работают системные аналитики, пользователь не "хочет что-то сделать", а участвует в сложном процессе с регуляторными ограничениями, исключениями и последствиями ошибок, большим числом развилок бизнес-процесса. Использование истории в таком домене - излишнее упрощение.
Что подходит лучше?
1. Jobs-to-be-Done - практика, когда нужно понять цели бизнеса и расставить приоритеты, если требуется;
2. Поиск решений для каждой отдельной цели: мозговой штурм, дерево решений, и т. п.;
3. Краткое описание фичи или сценария с возможными исключениями и нефункциональными требованиями.
А вам нравится формат историй?