7 способов лучше понимать потребности пользователей и доносить их до команды разработки

Чем лучше команда разработки понимает потребности пользователей, тем больше вероятность того, что качество решения будет выше, система — успешной, а команда — более мотивирована развивать систему дальше. В этой статье мы рассмотрим некоторые практики, которые помогают делать работу по выявлению и описанию потребностей пользователей чуть качественней, чем делаем её обычно. Каждая практика сопровождается обилием ссылок на дополнительные материалы по теме. Статья не про то, как проводить интервью с заказчиками. Но используя принципы, которые в ней описаны, вы сможете проводить интервью более глубоко и качественно.

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

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

Итак, поехали!

---

Содержание:

• Документировать выявленные потребности.

• Проверять описанные потребности через верхнеуровневый чек-лист.

• Проводить более глубокий анализ проблемы.

• Использовать DSM (design structure matrix).

• Записывать «выученные уроки», чтобы не наступать на одни и те же грабли дважды.

• Выявлять пропущенные требования качества.

• Release early, release often.

1. Документировать выявленные потребности

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

Документирование позволит:

• Лучше понять эти самые потребности: когда перед глазами есть текст, то гораздо проще найти в нем ошибки, логические неточности, сформировать вопросы, про которые не подумал в первый раз, подвергнуть формальному анализу — об этом почти вся остальная часть статьи. Когда этот текст находится у тебя «в голове» в виде неструктурированного и часто «аморфного» ощущения, то такой анализ сделать практически невозможно.

• Лучше коммуницировать с командой: когда есть текст, то любой участник может точно так же найти в нем неточности и задать вопросы. Одна голова хорошо, а несколько — лучше 🙂

• Быстрее подключать к проекту новых людей.

• Валидировать решение: понять, что реализованная функциональность решает то, ради чего она задумывалась.

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

Дополнительные материалы по теме:

• Статья «Не пишешь = не думаешь. Мышление письмом/моделированием»

• Книга «Как делать полезные заметки»

2. Проверять описанные потребности через верхнеуровневый чек-лист

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

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

Проверяем контекст и пропущенные ролевые описания. Должно быть как-то так:

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

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

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

• Решаемые ролью задачи должны быть связаны с бизнес-сценариями, а не со сценариями работы пользователя внутри системы. Чтобы понять, выбрана ли задача правильно, можно воспользоваться такой эвристикой: получает ли человек в этой роли за выполнение этой задачи зарплату. Например, офицеру безопасности платят не за составление «поискового запроса в DLP-системе», а за проработанный инцидент ИБ: своевременно выявлен нарушитель; выявлено и предотвращено намерение «слива» конфиденциальной информации и пр. Либо могут быть описаны задача и гипотеза сценария внутри системы, но проведена цепочка причинно-следственных связей до бизнес-сценария.

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

Дополнительные материалы по теме:

• про роли, потребности, системные уровни (то, что определяет «язык» описаний) — в книге «Практическое системное мышление 2022»;

• про чек-листы — в книге «Чек-лист. Как избежать глупых ошибок, ведущих к фатальным последствиям»;

• про причинно-следственные связи и пропущенные цепочки в объяснениях:

  • статья и видео Максима Дорофеева про обоснование причинно-следственных связей;

  • статья «Cause-effect diagrams: A pragmatic way of doing root-cause analysis»;

  • статья «Ожидая короткие понятийные расстояния».

3. Проводить более глубокий анализ проблемы

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

Получаем и документируем ответы на вопросы:

В чем состоит проблема/потребность, для которой нужна новая функциональность?

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

Как пользователи сейчас решают задачу? Описание текущего бизнес-процесса.

Выясняется то, как сейчас пользователь закрывает потребность/решает проблему. Текущим решением проблемы может быть необязательно наш продукт, это может быть другой софт или административные меры в организации. Если пользователь вообще никак не закрывает потребность и даже не пытается её решить, то это повод насторожиться — возможно (но не обязательно!), выбранная проблема недостаточно важна для наших потребителей, и они не будут готовы заплатить за её решение.

Какие проблемы пользователи испытывают с текущим решением? Как они сейчас эти проблемы решают?

Это те проблемы, которые мы планируем решить разработкой новой функциональности.

Какие проблемы испытывает наша компания с текущим решением? Как мы их решаем? Есть ли у конкурентов такая функциональность?

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

Дополнительные материалы по теме:

• Книга «Спроси маму: Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?»

• Книга «Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели»

• Метод Event Storming

4. Использовать DSM (design structure matrix)

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

Часто изменение одного модуля требует внесения изменений в другой связанный модуль, но так как эти связи не всегда можно удерживать в голове и вспомнить в нужный момент, то необходим дополнительный инструмент: матрица связанности модулей — DSM (design structure matrix).

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

Пример упрощенной матрицы для модулей автомобиля:

Метод применяется рекурсивно. Например, в рамках разработки одной функциональности изменили Модуль 1, по матрице выявили, что изменения в этом модули могут затрагивать Модуль 2. Анализируем выявленную связь и понимаем, что нужно вносить изменения и в Модуль 2 тоже. В свою очередь эти изменения в Модуле 2 затрагивают Модуль 10 и Модуль 15. Принимаем решения о доработке и этих модулей. Проверяем, как эти изменения связаны с другими модулями системы и т.д. При этом при проработке требований к этим связанным модулям могут возникать точечные вопросы к бизнес-сценариям. Также этот способ позволяет не забывать те модули, которые часто упускаются из виду.

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

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

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

Дополнительные материалы по теме:

• Cайт dsmweb.org

• Статья «Applying The Design Structure Matrix To System Decomposition And Integration Problems: A Review And New Directions»

5. Записывать «выученные уроки», чтобы не наступать на одни и те же грабли дважды

Записываем проблемы, с которыми сталкиваемся в процессе разработки новой функциональности и используем как чек-лист. Такой список будет постоянно пополняться. Тут важно не лениться и все записывать — в текущем моменте нам кажется, что мы никогда не совершим такую же ошибку снова (она очевидна!), но проходит несколько недель и замотавшись в проектной суете можно наступить на те же грабли второй раз. А чек-лист всё надежно сохранит и вместе с привычкой регулярно к нему обращаться может сэкономить командам разработки очень много времени и сил. У нас список таких «выученных уроков» на текущий момент получился объемом примерно как вся эта статья, а некоторые из пунктов были обобщены и добавлены в верхнеуровневый чек-лист.

Примеры:

• При изменениях в версиях совместимого third-party ПО (СУБД, ОС, Антивирусы и пр):

  • Какие предыдущие версии этого ПО поддерживаем? Поддерживаем ли их вообще или оставляем только одну новую?

  • Поддерживаем ли обновление со старых версий этого ПО?

  • Есть ли разница в поддержке third-party на разных операционных системах, на которых работает наш продукт (например, версия СУБД для InfoWath Traffic Monitor на Astra/CentOS/RHEL). Если разница технически есть, то уточняем у менеджера продукта необходимость поддержки на всех или только на какой-то конкретной ОС.

  • …

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

6. Выявлять пропущенные требования качества

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

В качестве чек-листа можно использовать список типов требований качества из книги Системноинженерное мышление:

7. Release early, release often

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

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

Дополнительные материалы по теме:

• Книга «Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели»

• Книга «Why Greatness Cannot Be Planned: The Myth of the Objective»

На этом всё. Будем рады ответить на вопросы в комментариях!

Автор статьи: Габдуллин Ильшат @g1r