BABOK и Инженерия требований
В блоге IIBA встретилась статья о том, что, аналитики работают с требованиями, но не всегда знают, что есть отдельная дисциплина посвященная требованиям. Если читать только BABOK, то можно упустить важные вещи. Прокомментировала от себя и получилось многобукв, поэтому детали пришлось оставить в Дзене

Как неудачное обозначение времени может оставить пользователя голодным

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

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

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

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

#книжки
Метод McKinsey. Использование техник ведущих стратегических консультантов для решения личных и деловых задач
Итан Расиел. Год выхода: 2012

Недавно оценила еще одну книгу. Издание 2012 года, некоторые инструменты с тех пор заметно больше развились, а методы, которые автор называет «причудливыми», уже получили распространение. Особенно занимательно выглядят примеры из начала карьеры автора в 1989 году. Тем не менее ход мысли при идентификации проблем бизнеса и поиске решений не слишком изменился с тех пор. Я даже удивилась как мало по моим ощущениям изменилось во взаимодействии с заказчиками, 90% примеров совершенно из сегодняшнего дня.

О чем книга? Тезисно расскажу о полезном. Детально лучше читать в самой книге, в ней всего 150 страниц. Текст построен так, что можно выбирать любой раздел в любой части книги и будет понятно, о чем речь.

📍Показан принцип поиска решения в McKinsey. Метод со сложной аббревиатурой MECE - Mutually Exclusive, Collectively Exhaustive. Его применение начинается с составления перечня проблем и анализа зависимостей между ними. Затем от списка проблем идет переход к формированию исходной гипотезы.

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

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

Кому может быть полезно? Бизнес-аналитикам любого уровня опыта будет полезно. Опытным — разложить опыт «по полочкам», начинающим — научиться видеть те «полочки», куда постепенно ляжет опыт.

Причины использовать Process Mining
#что_почитать

Хочу поделиться статьей The Top 10 Reasons Business Analysts Should Leverage Process Mining.
Тема Process Mining уже давно «на хайпе». Кажется, перед нами еще одна технология, которая лишит нас работы, автор довольно спокойно рассуждает об этом.

О чем статья? Речь о роли Process Mining в бизнес-анализе, не о том как работает анализ цифровых следов.
📍Автор считает, что как и генеративные ИИ, Process Mining неизбежно изменит работу бизнес-аналитика. Вопрос только в том, чтобы найти правильное применение этой технологии.
📍Process Mining много обсуждается, но его реальное применение пока не развито. Считается, что этот инструмент заменит традиционный анализ процессов, в реальности, он его только дополнит.
📍Последние 30 с лишним лет мы автоматизировали процессы, где-то выполняя документирование, а где-то нет. В результате многие процессы, решения, бизнес правила и клиентские пути глубоко спрятаны в системах. За пределами «видимости» невозможно применять традиционные техники, чтобы проанализировать правила, процессы и пути.
📍С другой стороны, Process Mining поможет с процессами в рамках систем, но не поможет понять взаимодействие человека с человеком. Для этого по-прежнему нужны старые добрые интервью, опросы, воркшопы и пр.
📍Автор указал 10 полезностей от использования Process Mining. Здесь я сохраню интригу и адресую вас к самой статье. Если вам интересно получить перевод всех 10 пунктов, то дайте знать в коментариях и я вернусь к этой теме.

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

Что почитать про Process Mining & Task Mining?

#что_почитать

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

📍Книга, которую рекомендовали в докладе о Process Mining на Flow: Van der Aalst, W.P.M. Process Mining: Discovery Conformance and Enhancement of Business Processes. Springer, Heidenberg, 2011
📍Статья из 2018 года, но вполне актуальная Process Mining: технология анализа процессов или способ визуализации хаоса?
📍Статья Интеллектуальная автоматизация: с чего начать?

Об ошибках в работе аналитика
#что_почитать

Делюсь статьей 5 Ways to Avoid Repeating Past Project Mistakes и своими примерами к перечисленным в ней частым ошибкам аналитиков. В статье сформулировано пять таких ошибок:
🔸Неправильно понимают свою роль в команде
🔸Поздно привлекают заинтересованные стороны к задаче
🔸Слишком рано занимаются совершенствованием документации
🔸Держат в фокусе “что”, а не “почему”
🔸Допускают разрастание границ задачи
Прокомментировала каждый тезис «от себя», получилась статья в Дзене

Может ли Agile-коуч писать плохие пользовательские истории?
#user_story #agile

Майк Кон, автор книги ”Пользовательские истории: гибкая разработка программного обеспечения”, выложил для подписчиков своего блога богатый материал. Это примеры пользовательских историй, которые описывают функциональность ранней версии сайта Scrum Alliance. Они были созданы в начале 2004 года. Конечно, я запаслась переводом, чтобы использовать в учебных заданиях. Делюсь с вами частью материала. Выложила 7 страниц разных пользовательских историй на Яндекс.Диск.
Автор прокомментировал так: «Некоторые из них хорошие, некоторые не очень. Не смотря на это я даю полный набор, как демонстрацию того, что я считал тогда подходящим началом бэклога продукта для этого сайта.»

Вот несколько примеров. Как считаете, какие из них не очень хорошие?
📍Я как пользователь сайта, могу читать новости на домашней странице чтобы быть в курсе новостей agile.
📍Я как пользователь сайта, имею доступ к старым новостям, которых уже нет на домашней странице, для того чтобы просматривать то, что я помню из прошлого или то, о чем мне сообщили другие.
📍Я как пользователь сайта, могу отправлять новости редактору по эл.почте, чтобы их рассмотрели к публикации. (Заметка: это может быть просто ссылка на почту редактора)
📍Я как редактор сайта, могу указать такие даты на новости: Дата начала публикации, Дата зачисления в «старые новости», дата окончания публикации (Start Publishing Date, Old News Date, Stop Publishing Date соответственно), таким образом статьи публикуются в и в течении соответствующих дат. Эти даты означают когда новость начинает отображаться на сайте, когда она перестает отображаться на домашней странице и когда она будет удалена с сайта (может не быть удалена никогда).
📍Я как пользователь сайта могу подписаться на ленту новостей RSS, таким образом я легко буду информирован.
📍Я как редактор сайта, могу назначать приоритет новостям, чтобы обозначить какие статьи я хочу наиболее явно отобразить на сайте.

Как я провела сентябрь и получила новые привычки
#опыт #размышления

Сложно удержаться от подведения итогов в конце месяца... Каналу всего две недели, а я наузнавала столько, что по ощущениям, мы здесь уже гораздо дольше.
Пока еще страшновато от мысли, что мало иметь материал для рассказа, нужно научиться рассказывать так, чтобы это было интересно читать. Можно же запросто быть мастером в своей профессии, но не понимать нюансов подачи информации. Есть что включить в план развития.
📍Оказалось, текст должен передавать что-то от личности и опыта его автора, потому что читать сухое описание книг и статей не интересно даже тем, кто по несколько часов в день занимается технической документацией.
📍Выяснилось, что фото с неудачным примером формата времени, вызывает больше реакций, чем описание даже самой полезной книжки. Нужно не забывать наблюдать больше случаев из жизни.
📍Стало понятно, что потребуется не только дисциплина, но и умение писать легко (не заглядывать в словари на каждом втором слове). Многие блогеры пишут о страхе чистого листа, но у меня почему-то его нет, а вот сделать текст непохожий на ТЗ пока сложно и требует времени.

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

Самое важное открытие сентября - здесь собрались те, кто готов меня поддержать. Можно двигаться дальше!

Собаки разговаривают, но только с теми кто умеет слушать
#что_почитать

Речь пойдет о статье про выявление требований для четвероногих пользователей. Оригинал тут How to use requirements gathering techniques to determine product requirements from non-verbal subjects, а здесь только обзор.

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

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

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

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

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

Что важнее цель или средства?
#опыт #размышления

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

Недавно в GetMentor устроили очную встречу в формате «эксперты для экспертов», где участники проекта делились своими мыслями и наблюдениями в менторстве. Я не смогла быть очно, но к счастью осталась запись. И знаете, что? Оказалось, что понять цель менторства — общая проблема и менторов и менти.
Менторы. В общем контексте одной и той же компании и единого корпоративного карьерного трека понятно чему учить. Вне такого контекста знания имеют другую ценность и нужно понять, чем реально можно помочь коллегам из других компаний. Поэтому вопрос «с чем помогу?» совсем непростой и ответ зависит в том числе от мотивации ментора:
🔸 Быть полезным и делать мир лучше?
🔸 Познакомиться с новыми сложными задачами из других предметных областей?
🔸 Заниматься ради денег и не париться насчет уровня задачи или заниматься только с мотивированными учениками?
Менти. Не каждый приходит с осознанным запросом на помощь. Общее — запрос возникает, когда человек «в ступоре» и не понимает как двигаться дальше:
🔸 Хотят получить новую работу в ИТ, но не знают что выбрать Анализ, Разработку, QA...
🔸 Уже знают, чем заняться, — готовятся к собесу. Не уверены, что хватит знаний.
🔸 Не ищут знаний, а ищут, того, кто решит его проблему. Вплоть до «я тебе экран пошарю и ты мне скажешь как решать».
🔸 Хотят развиться в профессии и ментор важен для составления трека развития.

Стало понятнее. Нужно немного поменять текст в моем профиле GetMentor...

Статьи про UI, про Демо и про требования
#что_почитать

Делюсь ссылками на отличные статьи от извеcтных мастеров (ENG)

📍AI: First New UI Paradigm in 60 Years
Статья от гуру UX Якоба Нильсена, в которой описано как менялось взаимодействие человека с компьютером и какая парадигма взаимодействия развивается сейчас. С момента выхода статьи в июне, ее отметили многие, потому что это и правда интересно.

📍Top 7 Ways to Engage Stakeholders in Sprint Reviews
Статья в блоге Майка Кона о том, что нужно, чтобы ваши заказчики не скучали на ваших Демо и вообще на него приходили. Ощущение, что известный мастер и на Демо моей команды побывал, так все откликается :)

📍Agile Requirements Gathering: Three Types of Requirements
Еще одна статья в блоге Майка Кона. Как работают требования в Agile, если разделить требования на три вида: известные, пропущенные и неожиданно появившиеся?

Что если, это допущение...
#субботнее #мысливслух

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

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

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

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

Как бизнес-аналитику преодолевать групповое мышление?
#что_почитать

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

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

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

Читать статью

Как я искала сложности и что из этого вышло
#опыт #исследования

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

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

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

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

Выбор респондентов Количество респондентов можно рассчитать с помощью калькуляторов. Если поискать по «количество респондентов для качественного исследования», то их найдется много, на курсе в ВШЭ нам советовали такой. Для расчета нужно знать объем целевой аудитории (сколько у вас всего пользователей) и понимать планируете ли вы сравнивать поведение разных групп или разные дизайны. В моем случае хватило 7-8 респондентов.

Критерии выбора респондентов я придумала такие:
📍Коллеги не общались по вопросам выявления требований в последние 6 месяцев. Хотелось услышать свежее мнение, а не общаться с руководителями, всегда готовыми перейти на язык выставления «хотелок».
📍Разделить респондентов на тех, кто меньше года работают в нашем подразделении (новички в продукте) и тех, кто работает дольше (опытные пользователи).

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

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

Итоги Критерием завершения исследования было по факту исчерпание списка респондентов, других метрик не было в задаче, хорошо, что список небольшой. Так как границы поиска не были заданы, то и отчет об исследовании получился огромным со списком из 30 инсайтов, часть из которых мы так и не смогли применить, а часть были далеко не новыми и уже хотя бы раз обсуждались заказчиками или уже лежали где-то на дне бэклога. Когда потом оценила время, потраченное на задачу, то получилось порядка трех недель чистого времени ушло на все интервью и из обработку — это цена неопределенности.

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

Заинтересованные стороны и их аналитики
#опыт #мысливслух #что_почитать

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

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

Что почитать? О выявлении заинтересованных сторон неплохо написано в статье тут

Как прокормить экспедицию?
#субботнее #кейс

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

Сценарий Центр морских экспедиционных исследований НИИ Океанографии организует экспедицию на научно-исследовательском судне с целью исследования динамики вод в некоторых точках Баренцева моря. Экспедиция планируется на 30 календарных дней. Экипаж судна составит 43, а членов экспедиции 120 человек. Отделу снабжения НИИ Океанографии поручено запланировать и выполнить заказ продуктов питания для членов экспедиции и экипажа.

Какие заинтересованные стороны могут быть вовлечены в задачу\проект отдела снабжения по обеспечению экспедиции?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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