Итоги кейса про снабжение экспедиции
#кейс #что_почитать

Оценим возможные ответы на такие вопросы:
📍Кто владеет бюджетом?
📍Кто принимает решения по снабжению?
📍Кто будет непосредственно исполнять задачи, то есть заключать договоры с поставщиками, делать переводы за поставки, поставлять и доставлять провизию, заниматься погрузкой на борт?
📍Кто будет конечным потребителем результата?
📍Чьи интересы прямо или косвенно могут быть затронуты?
📍Кто может влиять на ход поставок?
📍Кто хотел бы получить выгоды, но не получит их?

Кто владеет бюджетом? Дирекция НИИ

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

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

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

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

Кто может влиять на ход поставок? Кроме непосредственных исполнителей и принимающих решения, есть регуляторные органы, которые могут остановить поставки, например, Санэпиднадзор.

Кто хотел бы получить выгоды, но не получит их? Не вижу кого еще можно указать, кроме уже перечисленных.

Резюме Все указанные в опросе должны быть включены в список заинтересованных сторон. Дополнительно нужно указать сам отдел снабжения, экспертов по экологии и культуре региона, участников логистического процесса (например, экспедиторов) и регуляторов вроде Санэпиднадзора.

Что почитать? О выявлении заинтересованных сторон в ИТ-задачах рассказывается, например, в книгах И. Корнипаев «Требования для программного обеспечения: рекомендации по сбору и документированию», К. Вигерс «Разработка требований к программному обеспечению». В этом канале есть статья Цена термина «заказчик» и недавний пост Заинтересованные стороны и их аналитики

Почему не удалось с первой попытки найти приоритеты?
#опыт #исследования

Продолжу рассказ о каскадных исследованиях, который начала тут.

Итак, если нужно понять насколько те или иные функции важны вашим пользователям, то можно использовать метод Кано. Этот метод широко используется UX-исследователями, ими об этом методе написано много и известные платформы для UX-исследований поддерживают этот метод (Fabuza, Oprosso, например).
Если коротко, то метод позволяет с помощью заданной матрицы вопросов ранжировать список функций по категориям
📍Обязательные — такие функции для пользователя из ряда само-собой разумеющихся, без которых продукт не может выполнять свое назначение. Например, телефон должен принимать звонки. У этой категории наивысший приоритет
📍Важные (Одномерные) — эти функции чем лучше работают, тем лучше отношение пользователя к продукту. Например, чем лучше разрешение экрана смартфона, тем больше удовлетворенность пользователей. У этой категории высокий приоритет
📍Интересные — эти функции вызывают «вау»-эффект, они не обязательно нужны для выполнения задач продукта, но могут вызывать интерес пользователей. Приоритет может быть средним или низким
📍Безразличные — такие функции лучше отложить или вовсе от них отказаться

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

Value vs. Effort. Метод Кано не сработал, пришлось выбирать другой метод, который помог бы отличить субъективное от объективного. При выставлении приоритетов это важно, чтобы не рекомендовать команде взять в работу задачу, которая просто кому-то из стейкхолдеров нравится, но не несет сколько-нибудь значимой ценности в контексте всего продукта и всех групп пользователей. Выручил подход Value vs. Effort, который предлагает сопоставить предполагаемую ценность функции с ожидаемыми усилиями по ее разработке.
Когда нужно расставить приоритеты функциям в части юзабилити, ценность можно подсчитать, если оценить время выполнения и частотность операций, на которые повлияет изменение. Например, чтобы скачать ежедневный отчет, пользователю приходится проделывать путь через несколько экранов и занимает это в среднем 1 мин с учетом прогрузки страниц и ложных кликов. Пользователь каждый день пробирается таким образом не менее чем к 10ти отчетам. Суммарно в месяц один пользователь проводят пол-дня в переходах между экранами, и если это в деньгах больше, чем затраты на разработку, то этим имеет смысл заняться.

Дальше нужно искать решение, которое реально повлияет на скорость выполнения операции, а не просто переставит местами элементы на экране, но об этом в следующий раз...

Что почитать?
Модель Кано — инструкция по применению
12 методов приоритизации продуктовых целей: RICE, WSJF, KANO и прочие
Как использовать модель Кано для продуктового анализа

Юбилейный дайджест
#что_почитать #навигация

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

📍Как неудачное обозначение времени может оставить пользователя голодным
📍Что если, это допущение...
📍Об ошибках в работе аналитика
📍Что важнее цель или средства?
📍Цена термина «заказчик»

Как это понимать?
#опыт #мысливслух #субботнее

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

Мне всегда было интересно наблюдать, что так же как есть «ложные друзья переводчика», то есть слова схожие по звучанию, но отличающиеся по смыслу в разных языках, так же есть и «ложные друзья аналитика». Я имею в виду термины, значения которых могут значительно различаться в зависимости от предметной области.

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

Есть слово «клиент», которое в разном контексте приобретает разные оттенки. Для юриста это человек, с которым заключен договор, а операционист может так назвать любого обратившегося по какому-либо вопросу. Фраза «оформить профиль клиента» может означать и «внести данные договора в систему» и «внести данные нового потенциального клиента» в зависимости от того, кто ее произносит. При проектировании системы это может быть важным различием и есть риск понять разницу только после внедрения, если не уточнить значение термина.

Под этим постом Quiz, который показывает еще один хитрый термин. Как бы вы его «перевели»?

Как ID клиента оказался номером телефона и вдвое увеличил стоимость задачи
#кейс #опыт

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

Для участников ИТ-команд выглядит абсурдной ассоциация между «ID клиента» и «номер телефона». Часто к слову «идентификатор» прибавляется слово «уникальный», и так как номер телефона может меняться, он ни в коем случае не может уникально идентифицировать запись клиента. Это совершенно верно в контексте ИТ-решения.

Что если обратить внимание на данные экранных форм в решениях для колл-центров (Dialer системы)? Чаще всего на рабочем месте оператора колл-центра и при входящем звонке, и при исходящем обзвоне, единственная легко читаемая информация, на которую можно опереться — номер телефона. Если в таких системах есть интеграция с CRM, то могут быть подтянуты данные из договора клиента и его номер в реестрах компании, но это не всегда удобно, так как большинство списков на экране и в том числе окошко входящего звонка точно содержат номер телефона и не обязательно данные из CRM. Так возникает ситуация, когда оператор колл-центра значение номера телефона назовет «ID клиента», не вникая в нюансы уникального соответствия между клиентом и его номером телефона.

Когда аналитик впервые оказывается в предметной области, то он может решить, что термин имеет только одно вполне очевидное значение. Цена ошибки — двойная стоимость разработки. Выручают небольшие лайфхаки
📍если вы слышите термин впервые, проговорите его с заказчиком в явном виде, даже если думаете, что вам все понятно. Лучше показаться дотошным чудаком, чем заставлять команду переделывать функционал.
📍если проговорить не получается или ответ запутанный, то нарисуйте макет экрана, хотя бы в виде контуров на бумаге и на нем покажите пример отображения информации. Разница между UID и номером телефона будет явно заметна.
📍если макет не применим и речь не об экране, а о логике функционала, то на примере проговорите ожидаемую логику и/или покажите как вы понимаете пример данных до и после ее применения

Научит ли эксперт по бизнес-анализу аналитике?
#мысливслух #что_почитать

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

Можете представить, что были времена, когда ни системных аналитиков, ни аналитиков данных в индустрии не было явно выделено? И это всего-навсего лет 20 назад, когда я начинала работать. Было название «бизнес-аналитик», аналитики с таким названием и общались с заинтересованными сторонами, и составляли постановки задач на системном уровне. На тот момент это была новая дисциплина, по хайпу похожая на теперешний хайп вокруг роли владельца продукта. Довольно быстро пришло время, когда недостаточно знать название роли, чтобы понимать круг обязанностей, потому что требовался акцент на разные задачи и предметные области. Еще немного и аналитиков в ИТ стало больше двух видов.

При трудоустройстве по-прежнему обязательно нужно уточнять ожидания от роли, которую в компании называют «бизнес-аналитик». Разница только в том, что 15-20 лет назад это было новым и не всем понятным, а сегодня очень много вариантов может быть скрыто за одним и тем же названием. Думаю, не так важно назову я себя «бизнес-аналитик» или «эксперт в бизнес-анализе», все равно не удастся избежать путаницы. Были у вас забавные истории связанные с разницей между анализом и аналитикой?

Вот тут есть хорошая статья о разных видах аналитиков.

Очень вредно не ездить на бал, когда ты этого заслуживаешь
#мысливслух #конференции

Сегодня еду на конференцию Analyst Days. Поделилась этим в офисе и услышала от коллеги что-то вроде: «И когда вы все находите время по конференциям ходить?». Меня эта фраза зацепила. Подумала как сформулировать причину и пришла к двум тезисам.

🕰Было время, когда я развивалась в профессии вдали от заметной профессиональной движухи. Мероприятий было мало и на них нужно было куда-то ехать, что не всегда получалось. Поэтому сейчас, когда всего много и есть возможность участвовать, бывает грустно пропустить, не пообщаться и не узнать как другие аналитики решают задачи, обобщают свой опыт, используют разные техники и т. п. Когда стало много форматов он-лайн, легко могла подняться в 4 утра, чтобы, например, подключиться к семинару Карла Вигерса. Видимо, это называется «синдром упущенных возможностей» :)

🗃Вы замечали, что чем быстрее решишь одну задачу, чем быстрее получишь следующую и не одну? Забавно, что получается замкнутый круг: чем больше нагрузился задачами — тем меньше учишься и общаешься — тем быстрее теряешь ценность как специалист и выгораешь — тем хуже решаешь задачи… Карета может превратиться в тыкву. Получается, что нужно отложить рутину и найти время на конференцию как раз для того, чтобы не выгореть и качественнее решать те самые задачи из-за которых нет времени ходить на конференции.

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

Посмотрим, что будет в этот раз.

Analyst Days – 17, день первый
#конференции #analyst_days

Люблю слушать синьоров, не в смысле роли в корпорации, а мастеров в профессии, известных спикеров и авторов. В этот раз главным впечатлением был доклад Анатолия Левенчука Интеллект-стек для инженеров и менеджеров. Наблюдения, знания, опыт были поданы с такой энергией и провокацией, что 40 мин прошли на одном дыхании. Доклад о наборе знаний и практик мышления, которые требуются, чтобы проектировать и воплощать в реальность сложные системы вплоть до космических кораблей. Может ли аналитик построить космический корабль в сегодняшнем процессе работы с размытой ответственностью за решения?

В ИТ считают, что действия с моделью, как с куклой вуду, могут что-то менять в реальном мире. Переставил стрелки на схеме что-то поменялось? Умение отделить объекты модели и объекты реального мира определяет некий интеллект-стек, то есть мыслительные практики, которые мы используем, чтобы разобраться в реальном мире. Составляющие этого стека: системная инженерия, риторика, этика, эстетика, алгоритмика, логика, онтология, теория понятий, математика, физика, семантика...

Основные моменты мне откликнулись в докладе
📍Аналитик - это сложная роль. Исследуем, анализируем, но это не похоже на научные исследования, которые будут применены в промышленности. Предложенные решения проходят на следующий круг и зависят от решений менеджмента, который не имеет экспертизы в индустрии, а иногда и в предметной области
📍Чтобы строить сложные системы, не достаточно знать только инструменты вроде архитектурных принципов или нотаций… Нужно сочетание интеллекта и эрудиции. Например, одна из задач аналитика давать названия объектам предметной области. Как отделить объект от фона (контекста) и дать название, которое удастся не просто найти, но и удержать в использовании? Нужно, видимо, уметь больше, чем просто полистать словарь

Видео вчерашней конференции еще недоступны, поэтому поделюсь не менее провокационным докладом Системное мышление 2020 Анатолия Левенчука на Analyst Days-11

Analyst Days – 17, день второй
#конференции #analyst_days

Второй день Analyst Days прошел для меня в докладах по теме discovery. Пользовательские исследования уже давно в сфере моих интересов, поэтому меня очень порадовало, что в программе не менее пяти докладов были на исследовательские темы. Однако discovery в контексте этих докладов - активность аналитика, в результате которой рождаются функциональные требования, определяется объем задач проекта и концепция дизайна. На продуктовых конференциях этот термин будет означать другое — поиск идей новых продуктов и точек роста для существующих.

Тема исследований, на мой взгляд, - это давняя и неизбежная зона развития для аналитиков всех видов. Пока еще такие доклады на Analyst Days оставляют ощущение нераскрытых вопросов, да и зрителей собирают меньше, чем доклады о docs as code или архитектуре. Пока еще приходится слышать много спорного:
📍мы провели интервью, где все вопросы были с вариантами ответов (получился опрос с затратами равными интервью и оценкой объема выборки под интервью, а не опрос)
📍 есть же какое-то исследование, что достаточно 5 интервью, так что мы провели их 5 (это о статье Якоба Нильсена, где говорится, что при итеративном проведении небольших частых юзабилити тестов достаточно 5 респондентов для каждой итерации, а вовсе не о том, что в общем случае этого достаточно для любого исследования)

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

Подборка статей о User Story
#что_почитать

В этот раз разбор тематических блогов принес несколько статей о пользовательских историях (ENG)

📍Шаблон User Story: Что это и почему он хорошо работает? Статья в блоге Майка Кона. Рассуждения о том чем хорош и какие имеет варианты стандартный шаблон записи из трех элементов «кто», «хочет что», «чтобы что»

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

📍Составить критерии приемки как профи Красочная статья с примерами критериев приемки. «Красочная» - это буквально, с разноцветными картинками и художественным сравнением пользовательской истории с эскизом художника, а критериев приемки с красками.

Что получится, если скрестить компьютер с фотокамерой?
#книжки #кейс #что_почитать

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

Книга Алана Купера «Психбольница в руках пациентов» сейчас чуть менее популярна, чем 5-10 лет назад. Понятно, что книга написана в 2004 году и примеры интерфейсов устарели. Большинство уже не помнят окошек Windows’95. Тем более удивительно, что не теряют актуальности сами идеи о различиях между проектированием ради функциональности и проектированием для людей. Это книга о разнице подходов в проектировании продуктов с точки зрения проектировщика-дизайнера и проектировщика-программиста. Рассуждение о том, что продукты оказались перегружены функциями не нужными их пользователям и почему так получается. В заголовок этого поста я вынесла название одной из глав книги. Как, думаете, что получится, если скрестить компьютер с фотокамерой?

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

В книге есть задачка для подтверждения тезиса, что не все свойства продукта можно описать перечислением его функций без описания целей пользователя. Описан продукт с помощью перечня функций и этот продукт имеет:
📍двигатель внутреннего сгорания;
📍четыре колеса с резиновыми покрышками;
📍трансмиссию, связывающую двигатель с ведущими колесами;
📍трансмиссию и двигатель смонтированные на ходовой части;
📍рулевое колесо.

Напишите в комментариях, о каком продукте речь? Завтра напишу ответ из текста книги.

Задачи или функции?
#книжки #что_почитать

Продолжение предыдущего поста о книге Алана Купера «Психбольница в руках пациентов»…

📍Что получится, если скрестить компьютер с фотокамерой? Имеется в виду, что перегруженная функциями система перестает напрямую выполнять свои задачи, а превращается во что-то сложное. Будильник с кучей настроек для некоторых пользователей выглядит как компьютер, а не как удобный будильник. Может получиться, что не пользователь управляет будильником, а будильник пользователем...
От себя дополню. В работе аналитика это может проявляться, например, в виде запроса пользователя ”сделайте выгрузку этого в Excel”. Причины запроса могут быть разными и одна из вероятных — работа с записями в системе перегружена непонятными пользователю приемами управления данными, а он хочет сам управлять записями понятным ему способом. Нужно не только обучить пользователя, но и поискать функции, которые для него избыточны.

📍Кейс про функции и свойства продукта. В кейсе сначала перечислены функции продукта
• двигатель внутреннего сгорания
• четыре колеса с резиновыми покрышками
• трансмиссия, связывающая двигатель с ведущими колесами
• трансмиссия и двигатель смонтированы на ходовой части
• рулевое колесо.
Можно решить, что этот продукт — автомобиль, а после называются задачи продукта
• быстро и легко срезает траву
• на этом удобно сидеть.
Получается минитрактор-газонокосилка.
Я вспоминаю этот пример, когда думаю о документировании требований к функциональности. Не каждому разработчику понравится, если описание задачи перегружено описанием контекста. Разработчику удобнее видеть четкий перечень «что нужно сделать». Зато при изменении требований через пару месяцев, когда уже забыто зачем внедрялось изменение, вы сами будете рады найти информацию о целях и задачах заинтересованных сторон. Эта информация может помочь при тестировании запланировать тесты соответственно контексту. Поэтому при документировании приходится балансировать между описанием функций и задач.

«Да», «Нет» и «Зачем» не говорить?
#что_почитать

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

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

📌Всегда спрашивайте «Зачем»: пример из опыта (ENG) Автора попросили распечатать документ, поставить подпись, отсканировать и приложить скан в e-mail. Я так и не поняла, подписал ли он в итоге документ, зато выполнил и описал в статье разбор причин, которые могли привести к такому винтажному процессу. В итоге пришел к выводу, что если целью была безопасность, то она осталась недостигнутой.

⚙️Как построить контекстную диаграмму? (ENG) Нет это не о С4, но по смыслу инструмент похож на диаграмму контекста в модели С4. Статья о визуализации обмена данными между системами на концептуальном уровне, что может быть полезно при определении объема задачи.

Часть контента из этого канала превратилась в статьи

🔖Термины-хамелеоны (на Хабре) о неоднозначных терминах, которые могут обнаружиться в предметной области ИТ-задач.

🔖Как прокормить экспедицию? (кейс про заинтересованные стороны в Дзене) о выявлении заинтересованных сторон и какие вопросы-подсказки помогут никого не забыть.

Масштабируемая структура требований
#что_почитать

В выходные было время почитать и встретилась статья, которой хочу поделиться. Это обзор статьи, оригинал по ссылке Splitting Requirements at Scale.

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

Пример он-лайн магазина. Шаги процесса могут иметь разные правила в зависимости от категорий товаров: для заказа одежды нужно выбрать размер и цвет, для заказа продуктов нужно указать вес, для заказа напитков нужно указать объем и количество. Так в трех направлениях могут быть разбиты требования. Если предположить, что магазин решит развивать и В2В, и В2С продажи, то вариантов правил для каждого вида заказов становится больше, в каждой категории товаров добавляется два вида сделок, по одному для каждого сегмента клиентов. Структура требований усложнится. А какие еще можно рассмотреть варианты?

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

Разбивка в Agile. Здесь основная идея — любое требование разбивать на имеющие бизнес-ценность малые части для реализации за спринт. Подход отличный, но может теряться общая структура того, чего требуется в итоге достичь.

Иерархия требований. Этот подход автор описал как предпочтительный. Требования разбираются на уровни абстракции и образуют иерархию. Например: Уровень процесса, уровень пользователя и уровень системы. Каждый уровень должен представлять проблему или ценность на заданном уровне детализации. Верхние уровни задают контекст для нижних, а нижние детализируют родительские. Пример на картинке ниже. При этом сами требования можно нарезать по структуре организации или решения, а можно по логике процесса end-to-end, что предпочтительнее. Детальные шаги при этом оказываются на самом нижнем уровне

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

Пример иерархии требований из статьи Splitting Requirements at Scale

Бэклог не может содержать все подряд
#agile #что_почитать

Некоторое время назад подписалась на рассылку от Майка Кона. Как большинство рассылок от профессиональных консультантов и блогеров она бОльшей частью содержит рекламу курсов, но есть письма, которые составлены в жанре «меня часто спрашивают». Такие рассылки оказались содержательными и я хочу поделиться с вами некоторыми текстами. Надеюсь, они вам тоже понравятся 🌱
_______

Бэклоги — это как десерт, с ними нужно иметь чувство меры. Слишком большой бэклог является признаком проблемы, так же как и очень большой кусок пирога с двумя ложками мороженого. Это относится как к бэклогу продукта, так и к бэклогу спринта. Размеры обоих должны быть в рамках разумного.

Бэклог спринта. Бэклог спринта может стать слишком громоздким, если участники команды начнут использовать его в качестве отстойника для собственных задач.
Например, мой коллега недавно готовил презентацию к конференции Scrum Gathering в Новом Орлеане в мае 2024 года. Эта работа важна для него и выгодна нашей компании, поэтому я ее поддерживаю, но она не включена в бэклог спринта, потому что никто кроме него ей не занимается. Просто один человек готовит презентацию и время от времени интересуется нашим мнением. Выполнение этой задачи не является общей целью, никто не скажет: «Он сегодня заболел, поэтому сегодня я поработаю над его презентацией».
Если другим участникам команды нужно знать про вашу работу, или они могут заменить вас в выполнении этой работы, тогда эту задачу можно включить в бэклог спринта, в ином случае, ей там не место.

Бэклог продукта. Бэклог продукта может стать слишком большим если в него включено слишком много незавершенных идей.
Будучи владельцем продукта, я не хочу забивать бэклог продукта, включая в него каждую идею, которая у меня появляется. Для этого я завожу другой список, тоже своего рода бэклог, который я называю накопителем. Идеи находятся в этом списке до тех пор, пока я либо не перемещу их в бэклог продукта, либо откажусь от них. Я не пытаюсь скрыть что-то от команды, помещая это в накопитель, я просто не хочу загружать кого-либо своими идеями, пока я их не обдумал. Это как новый рецепт Флоридского лаймового пирога. Я поместил его в закладки, но не внес его составляющие в список покупок. И когда я соберусь его приготовить, мне хватит одного кусочка!

Поддерживая бэклог спринта и бэклог продукта в разумных рамках, вам будет проще добиться успеха с Agile.

Оригинал тут (ссылка на Яндекс Диск).

Пользовательские истории и нефункциональные требования
#кейс #agile #субботнее

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

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

Одушевленные системы и неодушевленные пользователи
#мысливслух #кейс #agile

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

📍Я предложила для уже сформулированного свойства решения определить, кто в нем может быть заинтересован и для чего. Получилось, что к следствию нужно придумать причины. На практике это случается, хотя по сути не выглядит нормальным порядком вещей. Обычно именно в таких случаях получаются формулировки с одушевлением систем «Я, как Система хочу, чтобы пользователь указывал логин и пароль, чтобы правильно логировать действия пользователя» или формулировки, где пользователю присваивается неестественное поведение «Я, как пользователь хочу войти в Систему, чтобы быстрее перейти к бронированию». Если человек действительно хочет скорее перейти к бронированию, то ввод логина и пароля будет восприниматься как помеха, а не как ожидаемая функция.

📍Как любые другие нефункциональные требования, требования к авторизации относятся к системе в целом. При реализации большинства историй будет важно учесть, что заявленный «кто» должен быть авторизованным пользователем. Получается, что общие характеристики системы так или иначе должны учитываться в критериях приемки любой истории или любая история должна наследоваться от нефункциональной...Может получиться громоздкая и неочевидная структура.
Прежде чем формулировать нефункциональное требование в формате истории я бы посоветовала подумать как эта история будет использоваться командой? Формат отдельной истории для требования к авторизации полезен, только если действительно нужен вашей команде как элемент бэклога. Иначе такое требование лучше не маскировать под историю, а фиксировать вместе с другими нефункциональными требованиями короткой фразой. Например, «Доступ к функциям должен предоставляться на основании ролей пользователей и схемы разграничения прав доступа между ними». Будет достаточно сослаться на это требование из других историй и задач, где необходимо.

Возвращаясь к субботнему опросу скажу так… На мой взгляд, лучше всего показывают контекст требования истории вида «Я, как пользователь хочу иметь Личный кабинет, чтобы хранить данные для автоматического заполнения полей при бронировании» и «Я, как специалист по кибербезопасности хочу знать, кто имеет доступ к бронированию и перс.данным». При этом с точки зрения планирования разработки эти истории слишком крупные и их придется разбивать на более конкретные. Так что подумайте как такой формат будет работать именно в вашей команде?