К содержимому
Проект и разработка

User story — задача глазами пользователя

Формулировка задачи через человека, его цель и результат. Заставляет описывать, зачем нужна функция, а не как её реализовать.

Также встречается как: пользовательская история, юзер стори

Коротко. User story — способ описать задачу через пользователя: кто, что хочет сделать и зачем. Классический шаблон: «Как менеджер цеха я хочу видеть статус заказа, чтобы не переспрашивать у мастера».

Почему формулировка важна

Сравните две записи одной задачи:

  • «Добавить колонку статуса в таблицу заказов»;
  • «Менеджеру нужно понимать, где заказ, не звоня в цех».

Первая формулировка допускает ровно одно решение. Вторая позволяет предложить лучшее: возможно, колонка не нужна, а нужно уведомление. Разница в стоимости решения — в разы.

Зачем фаундеру

История с «зачем» — это проверка на нужность. Если для функции невозможно сформулировать пользователя и его цель, скорее всего, она возникла из внутреннего обсуждения, а не из реальной потребности.

Это же лучшая защита от расползания объёма: к каждой новой просьбе задаётся вопрос, чья это цель.

Где ошибаются

Пишут «как пользователь я хочу…» для всего. Если роли нет, шаблон превращается в ритуал. Внутренние технические задачи спокойно описываются обычным текстом.

Прячут решение в историю. «Как клиент я хочу кнопку в правом верхнем углу» — это не история, а указание, замаскированное под неё.

Забывают про критерии приёмки. История говорит зачем; рядом нужен короткий список того, что должно работать, чтобы задачу можно было закрыть.

Разобрать это на своём проекте

Мы доводим идеи фаундеров до работающего MVP за долю в компании. Расскажите про свою — посмотрим на цифры вместе.

Оставить заявку

Рядом в словаре

Бэклог

Список всего, что команда может сделать, отсортированный по приоритету. Работает, только пока в нём есть порядок и он регулярно чистится.

Definition of Done

Согласованный список условий, при которых задача считается сделанной. Убирает спор «я уже закончил» — «а у меня не работает».

Scope creep

Постепенный рост объёма работы без пересмотра сроков и бюджета. Главная причина, по которой MVP на два месяца превращается в разработку на год.

Веха

Заранее назначенное событие, по которому проверяют состояние проекта и принимают решение продолжать, менять курс или останавливаться.

Канбан

Подход, где задачи текут по доске от «взять» до «готово», а главное ограничение — сколько дел можно вести одновременно. Подходит малым командам.

Критический путь

Последовательность задач, от которой напрямую зависит дата окончания проекта. Ускорять что-либо вне её — не ускорять проект вообще.