Несложно догадаться, что вопросы «Как мы думаем, что должно быть в системе?» и «А что бабушке Любе нужно от системы в том контексте, когда она в нее полезет?» дадут разные результаты: разные единички скоупа окажутся необходимыми или лишними, плюс иной будет их приоритизация.

А раз разные результаты, то какой из них предпочтителен? Сдается, что эпоха продуктов, которые построены так, как видят правильным их разработчики или заказчик, которого в отношении продукта интересуют только деньги, прошла. Это была эпоха сложных систем, которым надо активно обучаться, чтобы постичь гений автора, и все равно частенько фрустрировать в процессе работы, озвучивая кривизну его рук. Мы все же в точке, когда продукт должен быть лучше, чем у конкурентов, потому что конкурентов — действующих или потенциальных — много, и чаще всего именно пользователи решат, пользоваться ли именно вашим решением. Мы часто действительно кайфуем от решений любого плана, сделанных «экспертами» по традиционному подходу «я художник, я так вижу»? Например, от того, как работают больницы, школы и многие подобные услуги. Когда-то читал замечательный кейс, в котором городские власти решили обратиться к UX-специалистам из IT для анализа и редизайна городской больницы и точек взаимодействия людей с ней. И внезапно, несмотря на серьезные инвестиции в это, новая больничка не просто повысила авторитет властей за счет резкого роста удобства для людей, но и стала существенно более доходной.

В общем, если вы все еще работаете по дивному процессу «Заказчик, расскажи , что там в системе нужно -> Ок, я это в виде фич или сторей сделяль -> Команда, узри постановку задачи!», предлагаю попробовать встроить сюда один или несколько описанных выше подходов — высока вероятность, что счастья этим стейкхолдерам вы принесете значительно больше.

Написал заметку о том, как я использую GTD: Мой GTD: процесс, инструменты и советы.
Если у вас похожий опыт и есть свои фишки и тулы, которыми готовы поделиться в комментах, буду рад 🤗

Мы ещё не закончили с циклом типовых ошибок 😊 Пришла очередь для типовых проблем со скоупом (#21).

В предыдущих заметках мы затрагивали скоуп (границы, рамки, объем решения) и то, что его чаще всего представляют и поддерживают в виде функциональных возможностей (фич, features), вариантов использования (use cases, UC) и пользовательских историй (user stories, US). Давайте обсудим проблемы, которые чаще всего наблюдаются в скоупах, сформированных с помощью каждой из этих техник. Мы не будем обсуждать, а) чем каждая из проблем чревата, дабы не сильно удлинять опус — каждый сам может поразмыслить над тем, где кроются серьезные риски, а где — удобство восприятия; б) очевидные вещи, применимые к любому логическому набору требований, которые еще дядюшка Вигерс постулировал: полнота и непротиворечивость.

Фичи:

- Пропуски aka ни одна мелочь не должна остаться за кадром. Да, я упомянул, что неполнота — вещь очевидная, но тут я хотел бы акцентировать внимание именно на «мелочных деталях». Скоуп в виде фич — это распил решения на части. Если после такого распила остались опилки, которые не «приклеены» ни к одной доске, то их нет в решении. Часто, например, выделяют фичу Аутентификация, в описании или дальнейшей декомпозиции которой ни слова о выходе из системы (log out). Этот пункт актуален и для US, но не актуален для UC — UC не покрывают весь скоуп решения исходя из самой их сути, что делает их ограниченными в применимости для этой задачи.

- Неоднородность. Какие-то фичи — большие куски, другие — «мелочи», которые ценными кусками решения назвать сложно. Возьмем для примера Telegram. Работа с сообщениями и аудиозвонки — вполне зачетные фичи. Настройка аватарки — так себе, в сравнении. Почему вся работа с сообщениями — это один большой кусок, а из управления профилем как схожего по масштабу куска выделена одна только операция? Получается, что среди, условно, 20 элементов одним будет вся работа с сообщениями, а ещё 10 — это подпункты работы с профилем? Акценты тут точно верно выставлены? Пункт вполне себе применим и к US, когда одни эпики действительно эпичны, а другие порой меньше, чем отдельно взятая история. Для UC, при этом, это не особо актуально, т. к. сама техника диктует, чем должен быть каждый из UC, что и обеспечивает однородность (ниже рассмотрим это).

- Подача одним сплошным списком. Если фич немного — ок. Если их, например, 20+, то задумайтесь: не проще ли для восприятия и дальнейшего управления ими поделить решение вначале на 5 элементов, а затем каждый из них декомпозировать на ряд дочерних? Аналитик структурирует все, что можно структурировать. Если в вашем скоупе идут подряд такие фичи для Telegram, как Отправка сообщения, Редактирование сообщения, Настройка аватарки, Ночной режим и Редактирование параметров группы (или, что еще печальнее, они идут вперемешку), вселенная не шепчет, что их можно сгруппировать по функциональным областям / фичам более высокого уровня абстракции? Для US также есть понятие эпиков, которое можно еще дополнить рядом уровней: темы/стримы/любой_ваш_термин_позволяющий_выстроить_наглядную_структуру. UC, при этом, не могут быть разного уровня абстракции, но их также можно как визуально, так и в тексте сгруппировать по областям.

Варианты использования:

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

- Когда UC — не операция. UC — это вариант использования, операция над решением. Если среди ваших UC Отправить сообщение, Создать группу и Совершить звонок затесалось что-то типа Интеграция с Google-аутентификацией, то вы смешиваете «Что полезного юзер может сделать с системой» с «Что в решении нужно реализовать».

- Когда UC — не ценная для конечного юзера операция. Например, Выбрать получателя сообщения. Ну выбрал я его, а дальше что? Применимо ли такое в контексте «я иду в систему, чтобы выполнить UC и уйти из системы с полными штанами счастья?». Может, выбор получателя сообщения — это всего лишь шаг в рамках некоего действительного полезного для юзера UC? Да, если это априори не полезный UC (включаемый куда-то или расширяющий что-то) — вполне себе вариант, но не как самостоятельная операция в списке «что полезного можно сделать с системой».

- Когда UC — не разовая операция. Например, Управление сообщениями. Что это за действие такое? Аналитик в таком примере, вероятно, решил абстрагировать CRUDL для сообщений и иные дополнительные действия с ними в некую общую область, и это похвальная затея, но UC так не работают. Зачем нарушать понятие и специфики UC как техники, если можно просто очертить это областью или иным термином, который группирует UC по тематике?

- Когда актер для UC — не внешний агент. UC — это варианты использования решения: что с решением может сделать кто-то/что-то. Послать запрос в Google-аутентификатор, например, — это действие системы, которое, скорее всего, триггерится каким-то действием пользователя в рамках полезного для него UC. И UC как раз и будет полезная операция юзера над решением, которая будет как формулироваться иначе (например, Войти в систему с помощью Google-аккаунта), так и описываться внутри иначе и со стороны пользователя.

Пользовательские истории:

Описанное для фич выше актуально и для US, но есть и свои особенности. И вытекают они из того, что US в agile-контексте — это не только техника распила решения на единички скоупа с целью накопления поддерживаемой базы знаний. Это еще и постановки задачи, и элемент планирования и контроля проекта — если мы, конечно, про «правильные» US говорим.

- Нарушение Independent в INVEST. Сразу оговорюсь, что это актуально и для фич, просто для US это акцентировано явно.
Что может нарушить этот принцип? Во-первых, пересечение US. Например, Пересылка письма и Ответ на письмо как US для почтового клиента, если представить, что обе истории в плане критериев приемки включают в себя форматирование и отсылку конечного письма (т. е. разработчику нужно будет реализовывать одинаковые вещи в рамках обеих историй). Разбейте на три US: Отправка письма, Ответ на письмо и Пересылка письма. В таком случае общая часть будет реализована как постановка задачи до двух рассматриваемых историй, и пересечения не будет.
Второе, что нарушает зависимость, — это порядок реализации. Например, между историями Отправить письмо и Переслать письмо из примера выше выстроился определенный порядок реализации. Такая зависимость не страшна и без нее не обойтись в вашем бэклоге. Если это будет спланировано в контексте релизов так, чтобы не противоречило данной зависимости, то и не вопрос.

- Нарушение Small в INVEST. Давайте поделим то, что упомянули выше, на две сферы применимости US. Первая — это напилить систему на доски, чтобы понять скоуп (например, в рамках discovery для нового решения или в качестве обратного инжиниринга при формировании скоупа уже существующего решения). В это задаче — как и с фичами — без разницы, смолл или не смолл будут ваши единички скоупа. Но на каком-то этапе перед вашими US встают новые задачи: стать инструкцией для разработки/тестирования и единицей планирования в контексте проекта и его итераций. И вот уже для этой задачи классики гласят, что US должны быть small enough. Для каждой команды это означает свое (например, US должна влезать в спринт в плане сроков или в 1/6 спринта в плане трудоемкости), но в целом нужно иметь в виду, что в игру вступает еще и этот параметр, и помнить про SPIDR и refinement.

- US попилена не как требования, а как кусок дизайна. Подобное, естественно, актуально и для фич и юз кейсов, но для них такая проблема наблюдается существенно реже — думается, из-за того, что фичи и юз кейсы редко отправляются как таски в разработку сами по себе. Например, Отправка сообщения в Телеграм — полезная штука для юзера. Мы можем эту US пилить и дальше — например, по SPIDR, но только если это по итогу все еще представляет ценность для юзера как кусок функциональности. Мы не можем пилить эту историю на девелопмент-задачи, например UI для отправки сообщения, Таблица и процедуры в БД для отправки сообщения и т. д. и все еще называть получившееся историями в скоупе решения.

- US не отражают эволюционную поставку. Сложно сказать, что это актуально для фич и UC — в этом пункте мы смотрим на US в контексте второй задачи: инструкция для разработки/тестирования и единица планирования в контексте проекта. Одной из специфик agile-проектов, как мы знаем, часто является стремление реализовать вначале самокат, а затем постепенное допиливание его до космического корабля. Благое стремление, но и ваш скоуп должен поддерживать это на этапе, когда эта самая вторая задача становится актуальной. Отправка сообщения — это не минимально возможная единица декомпозиции. Тот же SPIDR диктует нам, что по концепции «самокат -> космический корабль» мы можем вначале сделать простую отправку, потом — с аттачментом, затем — с форматированием, затем — с эмоджи, затем — со стикерами, затем — голосовые и т. п.

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

Сегодня затронем тему ассампшнов (assumptions, предположения, гипотезы, допущения). В контексте цикла ошибок её можно сформулировать как «отсутствие работы с ассампшнами» (#22), что может серьезно повлиять на качество прорабатываемой информации, включая требования. По наблюдениям, чем сеньорнее аналитик, тем активнее он в работе «обкладывается» ассампшнами — о причинах поговорим ниже.

Как обычно, начнем с кораблей, бороздящих просторы. Для аналитика любая информация, включая требования, может быть фактом или чем-то близким к нему, а может — предположением. Предположение — это некое утверждение, которое принимается за истину, когда нет возможности в этом удостовериться. Например, утверждения «В этом канале, в основном, постятся материалы по бизнес-анализу» и «В этом канале 300+ подписчиков» — на данный момент факты, а «Материалы канала подписчикам нравятся» — предположение, которое можно вывести из ряда косвенных наблюдений (наличие одних реакций, отсутствие других, общение с отдельными читателями) — нет разумной по эффортам возможности получить более достоверную и статистически полную информацию. При этом, любое предположение может оказаться неверным, в чем, собственно, и есть их суть.

Соответственно, аналитику полезно не просто аккуратно подмечать, где он оперирует фактами VS ассампшнами, а вести с ними отдельную работу (фиксировать в явном виде, трассировать на них связанную информацию/требования, периодически проверять их валидность — стали ли они фактом или были опровергнуты, плюс явно коммуницировать их стейкхолдерам).
Чем меньше у аналитика возможностей выяснить надёжную информацию, тем больше у него ассампшнов. Именно поэтому в пресейле это популярный инструмент. Когда пресейл-команде дают один созвон с заказчиком, после чего закрывают коммуникацию с источником информации, им придётся формировать коммерческое предложение, исходя из имеющихся предположений на базе намеков, здравого смысла и расклада Таро, ибо ответ “мы не можем предложить бюджет/сроки, у нас крайне мало информации” никого не устроит. Поэтому хорошие пропоузалы всегда имеют отдельную секцию Предположения, где описано то, на каких допущениях строится та или иная информация в документе.

Возьмем за пример планы на отпуск — это также проект, и у решения в контексте этого проекта есть требования, пусть вы и не пишете для них спецификацию. На этапе discovery вы прорабатываете бизнес-требования, суть/образ решения и его скоуп. Допустим, у вас есть некая цель («Релакснуть душой и телом»), есть уже конечное решение («Отпуск в Испании») и есть скоуп в виде каких-то единиц (к примеру, это наполнение отпуска как в плане подготовки, так и проведения: «Получить визу», «Купить билеты», «Забукать отель», «Посетить место А», «Отдохнуть в месте Б» и т. п.).

Что может стать причиной ассампшнов?
1) Невозможность проверить информацию в принципе, т. к. это гипотеза о том, что будет в будущем. Например, элемент «Получить визу» сработает, только если в момент обращения эти визы будут выдавать, что есть неопределенность. Соответственно, вполне себе ассамшпн здесь «В июле 2024 г. визу в Евросоюз в РБ возможно будет получить». Или же ваш спонсор на проекте (речь уже идет про категорию ЗЛ для IT-проекта, а не спонсора вашего отпуска) выдвигает бизнес-цель «Заработать миллион баксов на продаже продукта в течение месяца после его релиза». В попытках удостовериться в ачиваблности этой цели вы выходите на простую математику «100000 юзеров * 10$ за подписку». И если стоимость подписки — это факт, т. к. спонсор явно высказал вам, что планирует ее таковой сделать, то то, что 100000 юзеров приобретут и установят продукт — это точка вне вашего или его контроля; это гипотеза спонсора, которую он сформулировал на базе чего-либо (анализ схожих продуктов, опросы, влажные мечты и пр.). «100000 пользователей приобретут продукт в течение месяца» — это предположение.

2) Невозможность (или нежелание — но количество подобных ассампшнов лучше сокращать) вами или ЗЛ в моменте удостовериться в валидности информации. Например, на этапе планирования отпуска у вас нет возможности проверить, какая обычно погода в целевом месте в июле. Но вы, вроде как, слышали, что она подходит для релакса на пляже. Соответственно, вы строите выбор решения на ассампшне «В Испании в месте X в июле, как правило, подходящая для пляжа погода». Или, например, на этапе пресейла контакт со стороны заказчика говорит вам, что сотрудники его отдела не будут пользоваться мобильными устройствами для доступа к целевой системе. Хозяин-барин, конечно, но полезно было бы все же напрямую с пользователями проработать сценарии использования системы — мы знаем, что «передатчики» требований могут ошибаться, и в идеале всегда стоит выходить на авторов. Нам, однако, надо решать, будет ли адаптация веб-системы под девайсы частью пропоузала. Соответственно, отсутствие такой фичи в скоупе в пропоузале может базироваться на предположении «Сотрудники будут использовать систему только с настольных устройств».

3) Ассампшны, которые являются неявной установкой у вас или у ЗЛ. Подмечать подобное — отдельное искусство (ранее тут, кстати, была ссылка на статьи про когнитивные искажения, которые часто становятся причиной подобного). Например, «Пляжный отдых — лучший для меня вариант расслабона». Это может идти как установка по умолчанию, но полезно подвергать подобные вещи критическому осмыслению и смотреть на них с долей скепсиса. На этом ассампшне базируется выбор типа решения для достижения бизнес-требования, однако так ли вы уверены в том, что это истина? Стейкхолдер, например, говорит вам, что в его бизнес-процессе действие X приведет к повышению оценки его работы со стороны начальства, а потому в систему это пипец как надо заложить. Так ли это на самом деле или стейкхолдер оперирует некой гипотезой, основанной на сформировавшемся убеждении? Можно ли это перепроверить непосредственно у начальства?

Где пригодятся ассампшны: везде, где мы фиксируем информацию для ЗЛ — Vision and Scope, SRS, ТЗ, планы на БА, User Stories в Confluence и т. п. Ассампшны могут быть на уровне бизнес-требований, выбора и обоснования решения, скоупа решения, а могут быть и на более низких уровнях — в требованиях ЗЛ и к решению. Ассампшны могут также быть в описании бизнес-процессов, ваших планах на бизнес-анализ, описании технических решений — ну то есть везде, где мы оперируем информацией.

Что с ними нужно сделать:

1. Учиться подмечать, критически осмысливая получаемую и прорабатываемую нами самими информацию. Уверены ли мы или стейкхолдер в этой информации или это предположение, которое в идеале стоило бы валидировать (удостовериться в истинности и превратить в факт)? Лучше всего, конечно, сразу ассампшны устранять, т. к. они — источники неопределенности и несут риски.

2. Если превратить в факт не получается, то фиксировать отдельно (в отдельно вынесенном разделе или любым иным обособленным от основной информации способом) — глава Assumptions в V&S, глава Assumptions в SRS, отдельные страницы в Confluence, отдельные секции/разделы на уровне каждой User Story, отдельная ветка в вашей mind map (если вы в виде карты памяти, например, брейнстормите ваш отпуск) и т. п.
Зачем? Нам придется дальше с ними работать, и ассампшны, зашитые глубоко в 500-страничную документацию, мы едва ли выудим быстро и полно.

3. Трассировать на них информацию, которая на них базируется или от них зависит. Например, в vision statement для примера выше «Решением будет являться отдых в Испании в июле…» стоит встроить в явном виде трассировку на ассампшн про погоду, который сам по себе будет зафиксирован в отдельно вынесенном месте (см. п. 2): «Решением будет являться отдых в Испании в июле (см. AS-1)…»

Зачем? Как и любая трассировка — в первую очередь, для импакт анализа. Если мы получим информацию, которая подтвердит/опровергнет ассампшн, нужно точно понимать, на что это повлияет. Например, узнав, что погода в этом году в июле будет фиговой, мы быстрым поиском по ID найдем 5 связей ассампшна с планами/требованиями и быстро поймем, где и что нужно теперь менять.

4. В явном виде доносить и акцентировать их стейкхолдерам, когда мы коммуницируем информацию, основанную на них. Это могут быть подобные посылы:
- «Вот анализ решений и наши рекомендации. Обратите внимание на секцию «Предположения». Анализ решений и рекомендации справедливы только при условии, что сформулированные предположения верны.»
- «Вот наше коммерческое предложение. В секции с предположениями описано то, на чем мы основывались, формируя бюджет и сроки. Если у вас есть комментарии или возражения по поводу предположений, дайте знать, и мы переработаем предложение исходя из новых условий.»
Этот пункт часто используется для прикрытия собственной попы или попы команды, и вполне справедливо. В условиях нехватки информации легко сделать ошибку, которая будет стоит репутации или даже более серьезных санкций команде. «Мы сделаем этот кусок работы за месяц!» — заверение, которое строится на ряде ассампшнов («Если наше понимание фичи, описанное тут, верно», «Если ничего больше в плане требований не будет вкинуто», «Если вот у этого сервиса есть доступно описанный API и он актуален»). Одно дело, когда мы даем серьезные обещания без пояснения подобного контекста, другое — когда мы делаем явными подобные неявно подразумеваемые вещи — в канале уже была заметка на тему явной настройки ожиданий.

5. Периодически перепроверять актуальность ассампшнов. Можно привязать это к старту итераций или любым иным ключевым точкам, а можно просто по графику или принципу «когда глаз наткнется». С течением времени ситуация может проясняться, и ассампшны могут либо становиться фактами (что есть круто и нам нужно актуализировать это, убрав эти ассампшны), либо опровергаться — что, с одной стороны, не круто, т. к. может повлиять на актуальность связанных бизнес-целей, выбора решения, скоупа, требований к решению любого плана, сроки, бюджеты и пр., но с другой — очень крут сам факт того, что выстроив с ними работу, мы это подметили и дали знать об этом стейкхолдерам, а не просто пустили на самотек. Весьма вероятно, что подобное стейкхолдеры оценят и скажут нам «спасибо, бро, от души!».

Доброго понедельника всем!

Очередная порция материалов в вашу кибитку:

- О личных планах развития БА и матрице компетенций: https://www.youtube.com/watch?v=a1fivBqUmzo
Любопытный контент, на мой взгляд, начинается где-то в районе 52 минуты — частичный пример матрицы скиллов.

- From BA to Senior BA: 3 Tips — довольно очевидные, на первый взгляд, но очень верные замечания. Эти пункты часто были моей личной болью при “взращивании” сотрудников. В статье мало деталей и примеров, но она может заставить задуматься и искать, где и как копнуть глубже, особенно если трассировать при чтении на собственный опыт и текущую позицию.

- 4 Thinking Traps of Ineffective Leaders — так как у нас тут канал про лидерство и успешный успех, то вот. На самом деле, заменив “leader” на “BA”, советы не теряют в полезности.

- A comprehensive list of Scrum and Agile Terminology — Project management — черт его знает, кому интересно читать словари, но вдруг вы в моменте готовитесь к собеседованию 🙂 Именно этот словарик довольно хорош.

Поделюсь парой недавних интересных менторских кейсов. Они объединены невеселой темой “На меня на работе глядят, как на чмо”. Может, пригодится кому-то в копилку идей для собственных ситуаций.

#1

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

Как решали:
1) Начали с того, чтобы понять, куда часики утекают: активный трэкинг рабочего времени. Провели такой эксперимент в течение недели. В целом, результат оказался вполне обоснованным и разумным, но, во-первых, страдала видимость работы для внешних наблюдателей (для начальника, в частности — эту часть отложили порешать чуть позже), а во-вторых — митинги, митинги, митинги: их оказалось безумно много, и аналитик сидит на них по принципу “авось будет что сказать”.

2) Решили проактивно показать трэкинг начальнику под соусом “спасибо за указание на проблему — я пытаюсь её усердно решать, и вот как…” Плюс предложили для начала переработать систему участия аналитика во встречах в качестве пробного решения.

Что получилось:
1) Начальник искренне респектнул за саму инициативу (что само по себе вин), при этом со скрипом, но согласился на то, чтобы аналитик участвовал только в ключевых митингах, где у него есть активная роль по умолчанию.

2) По итогам недельного “спринта” (решения, кстати, строили по принципу “планнинг - > спринт с регулярными апдейтами - > ретро”) времени у аналитика стало существенно больше, стресса — меньше. Люди стали чуть чаще ходить к аналитику за уточнениями вне встреч, но именно что “чуть” — катастрофы (внезапно, Карл) не случилось. Вспомнилось при этом недавно увиденное в соседнем чате: “Думаете, поменять хедер на сайте легко? Аналитик две недели будет на митингах сидеть, чтобы эту проблему решить” 😂 При этом уже начинают наблюдаться побочные эффекты в виде более крутых и надежных требований и иных полезных работ, на которые высвободилось время.

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

#2

Проблема:
снова у человека ощущение, что он — центр вселенной и работает всю работу в этом мире, при этом есть сигналы, что команда считает иначе: аналитик на проекте — тупо ради мебели. По итогу это “бьёт по самоидентификации”.

Как решали и что получилось:
1) Совместно строили Исикаву, пытаясь забрейнстормить, откуда идут подобные сигналы и чем они могут быть вызваны.

2). Пару девелоперов, с которыми есть более-чем-формально-рабочий контакт, попросили заполнить опросник под условным грифом “Я хочу быть лучше; что вы обо мне думаете и что я могу сделать, чтобы быть более полезной”.

3) Подтвердилась, хоть и на примере пары человек, гипотеза о том, что команда, как и в предыдущем кейсе, не видит работу. Аналитик много общается с заказчиком (почему-то практически всегда письменно, что отнимает тонны времени — с этим будем также пытаться работать), и это остаётся невидимым для команды от слова “совсем”. При этом часть с документированием требований (то, что, собственно, ярко видимо для команды) остаётся в просадке за счет многих факторов, но в основном по незнанию того, как оно может быть иным. Общий посыл, который словили: “Документация — полное гуано, брезгуем ей пользоваться, приходится постоянно спрашивать.” Плюс вскрылось, что техническая часть у аналитика страдает. А точнее её практически нет, что также влияет на то, что команда едва смотрит в сторону БА на встречах. Такое, кстати, я описывал вот тут.

4) Точечных решений было много, но ключевые такие:

- Построили план по приведению документации в порядок: перенос в Confluence, построение структуры, работа с требованиями к данным, НФТ и пр. В AS IS была фактически только постановка задач в Jira в относительно свободном формате. Те же девелоперы, которые участвовали в опросе, на примере прототипа сказали, что огонь огненный. Для этого, правда, серьёзно пришлось подтянуть теорию/практику по тому, какими бывают требования, как с ними работать и документировать, в частности.

- Построили планы на техническую прокачку. Будем наблюдать, как это повлияет на самоощущение от работы и восприятие участия аналитика со стороны.

Итоговые мысли: на мой взгляд, корень проблем тут в том, что аналитик начал работать по принципу “разберусь в процессе” — без качественной теоретической хотя бы подготовки. Я вижу большую ценность в грамотно структурированной теории в голове, о чем также не раз тут писал — не зная, как оно должно быть “по учебнику” и какие вариации могут быть на практике, сложно видеть недостатки собственных процессов. Да, можно учиться и на ходу, но только звезды могут сойтись как удачно (ментор на работе научит; теория выведется, причем правильно, из практики “наощупь”), так и не очень (потеря репутации в команде, негативное влияние на проект, сильно ограниченная применимость вне текущего места работы). Конечно, лучше поздно, чем никогда, и все эти проблемы решаемы, но не покидает мысль, что путь изначально мог быть более правильным и менее болезненным.

Сегодня поговорим о user stories (US) и частых ошибках при их проработке (#23). Я затрагивал некоторые в предыдущих постах (тут и тут), но надежный как швейцарские час план подразумевает посвященный этому отдельный пост. При всем моем стремлении сделать это вкратце, заметка, скорее всего, в очередной раз задавит объемом: ну извините — как вы давно поняли, за форматом инстапостов не сюда 😊

1. US не отражают эволюцию продукта. Такое часто наблюдается, когда аналитик переходит в agile из традиционных подходов. Аналитик берет планируемую систему, нарезает ее на доски, и они становятся единицами скоупа, причем сложив эти доски воедино выходит полный статичный срез системы на какой-то момент времени. Что не учтено в этом, так это то, что US используются, как правило, в agile-разработке, которой свойственны короткие итерации и постоянная эволюция системы от MVP-самоката до космического корабля — это дает поэтапную проверку того, что мы делаем нужные вещи и быструю обратную связь от стейкхолдеров.

Как избегать: внимательно изучить SPIDR (подход к декомпозиции US) и всегда держать в голове, что подход «начинаем с малого и постепенно улучшаем» к любой функциональности может быть выигрышным для проекта (конечно, если подобное — в ногу с видением заказчика).
Например, у вас с заказчиком может быть вполне себе огненное видение фичи «Отправить письмо» для почтового клиента, который призван втоптать Outlook в грязь. И тут целесообразным может являться не кушать этот кусок целиком и сразу (хотя, если подумать, чем не фича или юз кейс сам по себе?), а разбить по Paths и Data из SPIDR, чтобы поставлять это постепенно: Отправка письма в базовом варианте, Указание СС, Указание BCC, Прикрепление файлов, Проверка заполненности темы и пр. — это разные истории в таком подходе.

2. Затронутый недавно в чате момент: нарезка «торта» по горизонтали, а не по вертикали. Да, user story — это постановка задачи (об этом детальнее поговорим в другом пункте), но это постановка задачи команде, а не ее отдельным ролям. User Story — это user (!) story. Это прирост функциональности, который несет ценность пользователям (может, кстати, и иным стейкхолдерам, а может — и прирост НЕфункциональности, но это уже полезные порой извращения за рамками темы). US — это не кусок БД или кода, который нужен для будущих свершений и который пользователи не заметят. Называйте такие куски кода тасками, спайками и пр., но краеугольным камнем бэклога являются полноценные куски торта, затрагивающие все его слои и несущие ценность для «едоков».

Как избегать: смотреть на US с описанной выше позиции и не дробить US на задачи отдельным исполнителям — команда сделает это без вас как аналитиков. Не работать с такими историями, как, например, БД для писем, UI для писем с мобилок, Структура микросервисов для отправки и т. п. Для юзера есть только Отправка письма, которую можно (и, скорее всего, стоит) разбить по примеру в пункте выше, а не на технические задачи фронтенду, бэкенду, DBA, дизайнеру и пр., называя их при этом все так же user stories.

3. «Большие» US. Все мы, надеюсь, в курсе про INVEST и Small в нем. И все равно зачастую не особо стремимся «декомпозировать, пока декомпозируется». Фишка в том, что с небольшими задачами команде обычно легче работать (до разумной степени, естественно), а US, еще раз напомню, — постановка задачи. Т. е. помимо эволюции продукта (пункт 1 выше) «дробление» US, скорее всего, облегчит команде планирование и контроль в рамках проекта.

Как избегать: если абстрагироваться от «процессы везде разные», то за дефолтный подход рекомендую взять следующий:
1) Декомпозируйте US до разумного максимума — дробите, пока сохраняется ценность в кусках для пользователей, но с учетом имеющегося у вас опыта оценки того, что такое эти истории для команды разработки в плане эффортов. Тот же самый пример: Отправка письма в базовом варианте, Указание СС, Указание BCC, Прикрепление файлов, Проверка заполненности темы — так я как аналитик могу разбить исходную историю, и каждый из этих кусков даст юзерам новую ценность в сравнении с тем, что было до их поставки.
2) Согласуйте с заказчиком/PO/любым лицом, кто является для вас ЛПР для бэклога, ок ли такая разбивка. Это может быть объединено с первым пунктом, если вы делаете эту работу совместно. Например, заказчик сомневается в том, что имеет смысл разделять CC и BCC — либо мы даем юзерам все сразу, либо нифига не даем. Ок, будем иметь в виду, что это либо одна история, либо две (для удобства разработки), но обязательно в одной итерации.
3) Несите получившиеся истории команде на refinement и по факту обратной связи корректируйте декомпозицию (т. е. снова split/merge, если нужно). Например, команда сказала, что CC и BCC надо объединить — это крайне схожая работа и делить это на две задачи смысла мало. Замечательно, учли фидбэк всех ЗЛ, а потому объединим в одну US.

4 и 5. Нет ценности или ценность-тавтология + абстрактный «пользователь». Про «нет ценности», думаю, понятно, т. к. первое, что мы узнаем про US, — это три компонента их statement/title. И пользу несет не столько описанная ценность на бумаге, сколько ментальное упражнение при ее формулировке — иногда вы или заказчик придете к тому, что ценность не получается сформулировать именно потому, что ее нет, и нафиг тогда эту историю.
Чаще встречается бесполезно или абстрактно сформулированная ценность. И тут же я затрону еще одну проблему, которая часто идет в связке — абстрактный пользователь.
Примеры: Как пользователь я хочу заказать услугу, чтобы осуществить заказ услуги; Как пользователь я хочу просмотреть каталог услуг, чтобы получить нужную мне информацию.
Что тут не так? В первом случае это «хочу заюзать функциональность X, чтобы заюзать функциональность X». А в чем, собственно, потребность данной категории пользователей? Если мы грамотно используем персоны (техника сегментации пользователей), то история может превратиться в нечто типа «Как одинокий работающий мужчина, я хочу заказать услугу уборки на дому, чтобы не тратить время на неинтересную мне уборку».
Во втором случае ценность абстрактна. Логично, да, что человеку нужна информация, но в чем мотивация/ценность этой информации? «Как человек, ищущий обучение БА, я хочу просмотреть каталог курсов, чтобы выбрать подходящее моим потребностям обучение». Тут мы также эмпатируем, примеряем на себя ситуацию этого человека и понимаем (или выдвигаем гипотезу), для чего конкретно человек будет пользовать функциональность. Это понимание может оказать огромное влияние на то, какие еще US мы дадим в системе именно этим людям и как построим их UX в рамках этих US — т. е. мы будем делать продукт для человека, ищущего обучение по БА, а не для непонятной нам абстракции «пользователь» с неизвестной мотивацией (ну пришел на сайт и пришел — хз, что ему там нужно).

Как избегать:
1) Избегайте, по возможности, «пользователей». Если не получается выделить роли (что вполне может быть актуальным для масс-продуктов), рассмотрите технику персон. Это всяко будет бОльшее погружение в ценности и потребности будущих пользователей, чем анализ их в виде безликой массы.
2) Узнавайте/обдумывайте действительную ценность/мотивацию US для целевой категории. Не для галочки, чтобы закрыть третий компонент абы было «по книжке», а для того, чтобы продукт был ориентирован на конкретных людей и закрывал их конкретные актуальные потребности.

6. Нарушение границ US в критериях приемки.
Критерии приемки — это требования, детализирующие US, которые команде необходимо реализовать. То есть еще раз: то, что описано в КП, это инструкция к разработке в контексте именно данной US. Иная их трактовка может сбивать читателей с толку, если не согласована заранее.
Пример: US «Написать письмо» и ее КП:
1) Находясь в папке «Входящие», я вижу список полученных мной и неотсортированных по иным папкам писем.
2) Я могу отсортировать письма по теме.
3) Я могу открыть создание нового письма.
1 и 2 — это не часть данной истории. Это КП о просмотре писем и их сортировке. Этим КП не место в истории «Написать письмо». История должна начинаться с «Находясь в папке «Входящие», я могу открыть создание нового письма». Именно это требование будут реализовывать разработчики, расширяя продукт с некоего AS IS состояния до TO BE, в котором для пользователей теперь появится создание писем.

Как избегать: фактически, это уже описано — понять, что такое критерии приемки, и рассматривать их именно с этой позиции.

7. Привязка к UI, когда это вредит. Это частный случай нарушения Negotiable в INVEST (при условии, что за UI отвечаете не вы) и более общего «не лезь не в свой огород».
Когда мы говорим, что US должна быть Negotiable, мы имеем в виду, что на команду не должны быть наложены лишние ограничения, т. к. они ценные союзники в выработке решения и его деталей. Если вы что-то закладываете в требования (КП), то допускайте, что а) некоторые вещи — в целом вне вашей компетенции на проекте и не стоит в них вообще лезть в контексте требований (например, структура БД или технический алгоритм взаимодействия двух сервисов — ну то есть серьезно, это ваша часть работы и в команде нет людей, руки которые более прямо заточены на это?) б) заложенные КП не высечены в камне: а точнее, вы должны понимать, что в них является не обсуждаемыми требованиями, а что — решением, открытым к альтернативным идеям. И часто этим самым моментом является как раз UI.

Как избегать:
1) Прочитать вот эту заметку 😊
2) Определить, кто в команде занимается проектированием UI. И я имею в виду именно проектирование (формы, контролы, их типы, схематичное расположение, навигационная схема), а не визуальный дизайн (шрифты, цвета, попиксельное расположение, конкретные картинки и пр.)
3) Если это не вы, то не затрагивайте UI в КП для US:
«Я могу открыть создание нового письма», а не «Я могу нажать на кнопку «Создать письмо».
«Когда письмо успешно отправлено, система отображает мне список входящих писем», а не «Система перенаправляет меня на страницу «Входящие».
4) Если вы тот человек, который проектирует UI, игнорируйте описанное в этом пункте и пишите требования так, как привыкли 😊

8. Игнорирование short name для US.
Мелочь, которая, скорее, для удобства. Не раз замечал, что для многих по какой-то причине US — это полная формулировка (statement/title) из трех компонентов. И по-другому ссылаться на такую US люди не могут, ибо учебники гласят, что за отсутствие какого-либо из компонентов вас низвергнут в ад. Но не все понимают, что формулировка не равна названию. Отсюда и куча лишних слов в обсуждении истории с какими-либо стейкхолдерами.

Как избегать: понять, что у US кроме формулировки есть короткое имя/название, аналогичное фичам и юз кейсам, и использовать в обсуждениях и артефактах (например, в User Story Map) именно его. Примеры названий историй я не раз выше использовал и ссылался на истории именно по названиям, а не по «Как пользователь, я хочу написать письмо, чтобы…»

9. Чрезмерная детализация на старте. Спорный момент, на который сильно влияет то, как у вас построены процессы, поэтому трактуйте это как одну из best practices, которые стоит рассмотреть и оценить полезность в контексте именно ваших процессов. Agile свойственна постепенная проработка требований — в первую очередь, чтобы не делать лишнюю работу с риском ее бесполезности.
Пример: вы как истинный перфекционист сели и описали КП для всех US в вашей карте историй на 5 баллов: каждый негативный сценарий; сообщения и проверки во всех ситуациях; то, как система должна реагировать на юзера в полнолуние в високосные годы. Это то, чему нас учили в контексте написания спек, не так ли? Но есть нюанс: agile открыт к изменениям и построен, в целом, на этом. Представьте такие (абсолютно нормальные, стоит заметить) ситуации: через пару дней история выброшена на помойку по инициативе заказчика; после приоритизации история опустилась на дно бэклога aka сделаем через пару лет (что = не сделаем никогда); команда на refinement предложила иные решения или вообще похерила то поведение, которое вы описывали, ибо не юзабельно, дорого или технически невозможно. Все это мало того, что не есть эффективное использование вашего времени, так еще и затронет ваше эго и приведет к ненужным страданиям.

Как избегать: найти точку, в которой ваши эффорты будут just enough исходя из контекста. Есть agile-команды, в которых именно так и поставлен акцент и исходя из этого продуманы процессы постепенной проработки требований. Например, 1) вы быстро на глаз накидываете ключевые КП для всех историй в обозримые пару месяцев разработки, чтобы было что обсуждать с заказчиком и на что получать его первичный фидбэк, 2) вы дорабатываете КП на плюс условные 30% качества для историй в верхней части бэклога и несете их на refinement, 3) вы дорабатываете истории после refinement на базе выработанных решений, 4) вы дорабатываете истории еще на 20% после планнинга, 5) остатки вы дописываете в процессе реализации US, по мере обращения к вам исполнителей. Процесс не должен быть именно таким, но примерьте эту концепцию на свою ситуацию — вероятно, увидите возможность более рационального использования своего и стейкхолдеров времени.

10. База знаний вместо постановки задачи. Не раз уже упомянутая тема в канале, и я еще раз отошлю к замечательному докладу (на мой взгляд, must see для всех, дабы понимать упомянутые концепции, даже если вы с US не работаете): https://www.youtube.com/watch?v=qpwcE1rsBNg
Этот пункт, как и предыдущий, сильно зависит от ваших процессов — я лишь упомяну его в контексте «классического» взгляда на US по умолчанию.

В чем роль US на проекте? US — это ценный инкремент продукта (дополнение/изменение в продукте), плюс механизм планирования и контроля проекта и его итераций ("в спринт пойдут вот эти вот US, вот как мы их оценим, вот кто будет каждой заниматься" и пр.).

Что такое ведение базы знаний (спецификации) в виде US? Вы делаете US «Отправить письмо», отдаете в разработку, но в новом спринте заказчик хочет добавить сюда аттачмент файлов. Как вы поступаете, трактуя US как спецификацию/базу знаний? Обновляете историю до версии, условно, 2, дополняя КП требованиями к тому, как должен происходить аттачмент.
Что тут не так? Все так, если вы хотите вести актуализируемую базу знаний по системе. Однако, а в чем полезный инкремент для системы? В кусочке истории, который явным образом не выделен? Как выполнить оценить историю, как отдать US на разработку и тестирование? Как описать DoD (definition of done) для US, если US — это не сделанный в рамках спринта кусок, а актуализированная и усложненная US из прошлого? Вам придется дополнять это костылями, которые все равно введут новый термин и будут служить постановкой задачи вместо US — например, это привязанные к US задачи, которые в описанных процессах займут место US.

Что такое трактовка US в виде постановки задачи? Была US «Создание письма». Спринт закончился, US принята, DoD выполнен — US «выброшена» (осталась в анналах системы документации). Заказчик хочет теперь аттачменты? Ок, это новая US («Аттачменты файлов») и именно она фигурирует в верхушке бэклога как полезный инкремент продукта, именно ее будут планировать в спринты, оценивать, обсуждать, брать члены команды в работу и закрывать по DoD. И в этом и есть best practice по работе с историями.

В чем недостаток такого подхода? Если пользоваться только US как контейнерами требований, то вы остаетесь без базы знаний. Хорошая новость: она не всегда и нужна. Вам может казаться, что без нее не обойтись, но это только на первый взгляд. Большое количество проектов не требуют базы знаний в виде документации или же вполне допускают, что эффорты, которые будут сэкономлены на ее отсутствии с лихвой покроют ситуации, когда надо раскопать, как там сейчас работает какой-либо кусок. А иногда и комменты к коде или грамотная структура US в Confluence или ином месте (не в Jira, нет 😊) облегчат закрытие задач, стоящих перед актуализируемой базой знаний.
Плохая новость: иногда она таки нужна (часто меняются люди в команде, сложная логика системы, большие длительность и объемы проекта). И в таком случае нужно искать подход к тому, как сделать и то, и другое: и базу знаний вести, и задачи ставить команде. Ну или же думать, какими словами обозвать и в каких единицах выполнять оба эти процесса.

Привет всем!

Заметка о такой огненной штуке, как Impact Map, с примером, разбором и советами: https://shesterov.by/tpost/fzh1lezxp1-impact-map-i-user-story-map-kak-bistro-i

Ещё несколько занимательных статей на почитать:

Want to Communicate Effectively at Work? Eliminate These 5 Cognitive Distortions (https://betterprogramming.pub/want-to-communicate-effectively-at-work-eliminate-these-5-cognitive-distortions-679caa76cd2a): в продолжение темы о когнитивных искажениях, на этот раз в контексте коммуникаций. Интересно, полезно и познавательно.

Про OKR и Гарри Поттера (https://www.linkedin.com/posts/kirakuzmenko_%D0%B3%D0%B0%D1%80%D1%80%D0%B8-%D0%BF%D0%BE%D1%82%D1%82%D0%B5%D1%80-%D0%B8-okr-ugcPost-7196081864183341056-s_--): совсем не уверен насчёт полезности, плюс заметки со словом OKR заставляют мой глаз истерически дёргаться, но кайф тут именно в примере.

Top 10 Phrases To Include In Your Elevator Pitch (https://english4it.medium.com/top-10-phrases-to-include-in-your-elevator-pitch-8e177bcad5a3): от все того же классного канала про фразы, которые помогут звучать более модно. Огонь, как обычно.

Салют!

Подъехала вторая часть — о User Story Map и том, каким может быть процесс её проработки: https://shesterov.by/tpost/c447fei0c1-impact-map-i-user-story-map-kak-bistro-i

Пятничное чтиво-рассуждалка о стереотипах в бизнес-анализе (https://shesterov.by/tpost/3dgtau3211-stereotipi-v-biznes-analize).
Если появится желание доказать несостоятельность доводов — не сдерживайтесь, буду рад обсудить 😊

Салют!
Еще одна подборка статей для нескучных вечеров:

- В очередной раз можно освежить в памяти SPIDR — на этот раз в подаче от Дениса Гобова: https://www.artofba.com/post/spidr-how-t-decompose-user-story. Активно читающие канал вряд ли найдут что-то новое для себя, а для еще не знакомых с этой техникой — отличный повод изучить эту штуку в огненной обертке.

- О том, как проводить Скрам-ретроспективы полезно: https://medium.com/beyond-agile-leadership/3-essential-practices-in-sprint-retrospective-to-unleash-agile-teams-potential-a0e2963c70d9. Так-то об очевидных вещах, но кратко и систематизировано.

И немного о технике (осторожно, внутри статей много букв):

- Understanding the Top 10 Software Architecture Patterns (https://www.designgurus.io/blog/understanding-top-10-software-architecture-patterns): отличный гайд для новичков — рекомендую проштудировать, если принципы построения программных систем совсем в новинку.

- Гайд постарше, но от этого не менее замечательный — What is code (кстати, один из материалов, которые мы рекомендуем в качестве технической подготовки к курсу): https://www.bloomberg.com/graphics/2015-paul-ford-what-is-code/. Для тех, кто в IT недавно или как раз планирует путешествие, must read.