От хаоса к системе: как мы выстроили процесс Discovery (часть 2)

В сфере искусственного интеллекта произошло заметное событие. Anton_OR 11 минут назад От хаоса к системе: как мы выстроили процесс Discovery (часть 2) 6 мин 300 Управление проектами * Управление разработкой * Управление продуктом * Подготовка технической документации * IT-компании Кейс В предыдущей статье мы рассмотрели общий процесс работы аналитиков. Здесь подробнее остановимся на ключевых этапах подготовки постановки. Разберём, как именно выстроена аналитическая работа внутри upstream: от преданализа до груминга, и какие практики помогают повышать качество требований и снижать риски на этапе разработки.

ПреданализЭтот этап помогает уточнить контекст задачи и подготовить её к аналитической проработке. На этапе преданализа аналитик:Уточняет требования. Задача может прийти не только из декомпозиции эпика, но и после устных обсуждений, «быстрых» заявок или пожеланий интегратора — в таких случаях описание часто неполное или неструктурированное.

Технические детали

Полная детализация всех требований раздувает оценку до гигантских размеров, делая задачу нереализуемой в рамках одной итерации. Проводит исследование. До начала описания аналитик изучает конкурентов, анализирует их решения, а при необходимости проводит интервью с пользователями, чтобы убедиться в востребованности функциональности.

Иногда на этом этапе становится понятно, что задача утратила актуальность или требует значительно больше ресурсов. В таких случаях она переводится в статус «Отказ» либо возвращается в статус «Ожидает анализ». Если задача имеет достаточные вводные и чётко определённые границы, аналитик может сразу перейти к этапу «Анализ».

Подготовка аналитической постановкиНа этапе «Анализ» формируется аналитическая постановка, которая используется командой разработки. Для фиксации требований аналитик создаёт страницу в базе знаний и выбирает соответствующий шаблон — для пользовательской истории или исследовательской задачи. Шаблон помогает структурировать документ и не упустить ключевые элементы требований.

Отраслевые последствия

На ранних этапах проекта единых требований к формату постановок не существовало, из-за чего требования отличались по уровню детализации и осложняли работу команды. Со временем были сформированы шаблоны постановок и чек-листы, содержащие договорённости между upstream и downstream. При этом опытные аналитики могут выбирать удобный формат, а шаблон выступает ориентиром и опорой при подготовке постановки.

Шаблон постановки был совместно разработан командой аналитиков. В результате мы выделили следующие требования:Постановка должна содержать описание, в котором передается бизнес контекст реализации функциональности. В данной части аналитик должен указать:как функциональность работает сейчас (опционально), приложить ссылки на связанные постановки (опционально);как будет работать: отрисовать use case диаграмму (опционально);описать основной, альтернативные сценарии и исключения.

Каждый шаг сценария может превратиться в требование.

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.