При составлении бэклога или списка требований часто возникает проблема трассировки задач бизнеса на конкретные фичи продукта. Не всегда из набора фичей складывается ясная картина влияния продукта на целевые метрики бизнеса.

Impact Mapping — это мощная техника выстраивания соответствия целей и конкретных решений. Она позволяет быстро выявить полезную функциональность (и избавиться от бесполезной), приоритезировать состав функций продукта и сфокусироваться на решении задач бизнеса, а не запиливании фич.

Кроме того, техника дает каркас для выработки решений, не связанных с изменением продукта, а лежащих в области изменения процессов и маркетинга.

На мастер-классе участники самостоятельно попробуют применить Impact mapping на учебной задаче, получат фидбэк и разбор всех нюансов построения карт влияния.

Длительность мастер-класса - 2 часа.

Баттл с Сергеем Мартыненко про техники проверки требований.

Тезисы Сергея:

Системный аналитик производит тексты. В истории ИТ постоянно появляются попытки перевести все артефакты в форму диаграмм, но даже в диаграммах есть слова и подписи. Да и не всегда удобны диаграммы оказываются и для разработчиков и для согласующих. В общем, аналитик производит тексты - описания процессов, требования, технические задания. И это тексты на естественном языке. А естественный язык - это не формальная система. В словах куча неоднозначностей, умолчаний, двусмысленностей, недоговоренности, подразумеваемых значений... И если такие слова просачиваются в тексты требований - жди беды. В докладе я расскажу про требования к текстам требований (и даже приведу выдержки из соответствующих стандартов) и дам список "стоп-слов" - таких слов и выражений, при встрече которых в документе или на диаграмме у аналитика должна мысленно "загораться красная лампочка" и включаться сигнал тревоги. Очистим тексты аналитиков от двусмысленностей и неоднозначностей! Доведем тексты требований до совершенства!

 

Существенная часть работы аналитика - выявление потребностей заказчика и будущих пользователей продукта. Но как быть аналитику в ситуации, когда во время интервью на него вываливают целую кучу информации разной степени ценности: и настоящие потребности и боли, и преждевременные проектные и интерфейсные решения ("нам было бы удобнее, если бы вот здесь была большая кнопка "Подписать"), и разнообразные идеи, зачастую никак не соотносящиеся с реальными потребностями и никак не проверенные ("Нашим пользователям обязательно нужна функция загрузки своей фотографии в личный кабинет! Где она будет потом отображаться? Про это я ещё не думал! Но функция такая обязательно нужна!"). Кроме того, аналитик может получить ответы, отражающие не реальное положение дел, а желаемое или социально одобряемое ("Какие из-за наших ошибок бывают последствия? Никаких! Мы вообще сами никогда не ошибаемся. А если и ошибаемся - это из-за тех, кто дает нам неверную информацию. Или из-за глюков софта. Или ещё из-за чего-нибудь").

А самое главное - как найти ту ключевую проблему, которую действительно стоит решать, и отдача от которой будет наиболее высока? Особенно это важно, когда вы работаете над продуктом, использование которого добровольно для ваших пользователей.

В мастер-классе я покажу структуру интервью и вопросы, которые стоит и не стоит задавать во ремя интервью, чтобы вытащить из респондента значимую информацию и подтвердить или опровергнуть гипотезы. Мы потренируемся проводить интервью, разберем ошибки и попробуем подтвердить (или опровергнуть) некоторые гипотезы об аналитиках :)

Формат: мастер-класс. Число участников - до 40 человек. Время проведения - 1.5 часа

Требования, конечно, меняются. Иногда. Но гораздо чаще случается, что аналитик не до конца выдавил из заказчика и стейкхолдеров все требования, оставив множество умолчаний ("как нет этой функции? а мы думали, она будет! разве о ней нужно было отдельно говорить?")

Я расскажу и покажу техники, позволяющие задать нужные вопросы, выявить максимальное количество требований на ранних этапах анализа, и обсудить нужность этих требований и их приоритеты заранее, а не при сдаче-приемке. Как правило, после применения всех техник объем требований и юзкейсов для обсуждения возрастает в 1.5-2 раза.

Возможно, многие техники вы уже применяете, а о некоторых даже не слышали; я попробую свести их в единую систему.

Вот некоторые техники (только названия!): анализ именованных сущностей, расширенные матрицы CRUD, контекстный анализ/user centered design, анализ жизненного цикла и т.д.

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

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

В докладе хочу расказать - как происходят метаморфозы проекта, в какой момент проекту нужен аналитик. а в какой - менеджер продукта, когда они нужны оба и как они делят ответственность, и как выжить во всей этой катавасии.