Чем лучше команда разработки понимает потребности пользователей, тем больше вероятность того, что качество решения будет выше, система — успешной, а команда — более мотивирована развивать систему дальше. В этой статье мы рассмотрим некоторые практики, которые помогают делать работу по выявлению и описанию потребностей пользователей чуть качественней, чем делаем её обычно. Каждая практика сопровождается обилием ссылок на дополнительные материалы по теме. Статья не про то, как проводить интервью с заказчиками. Но используя принципы, которые в ней описаны, вы сможете проводить интервью более глубоко и качественно.
Статья будет полезна аналитикам, Product Owner'ам, руководителям проектов и всем, кто так или иначе связан с работой по выявлению и документированию потребностей.
Каждую практику можно использовать независимо, а можно применять их все — как вам удобнее в конкретном проекте.
Итак, поехали!
Содержание:
Документировать выявленные потребности.
Проверять описанные потребности через верхнеуровневый чек-лист.
Проводить более глубокий анализ проблемы.
Использовать DSM (design structure matrix).
Записывать "выученные уроки", чтобы не наступать на одни и те же грабли дважды.
Выявлять пропущенные требования качества.
Release early, release often.
1. Документировать выявленные потребности
Ключевая практика, которая сильно недооценивается. Очень часто донесение потребностей до команды ограничивается устным разговором и остается только в головах у тех, кто принимал в нем участие. Дело усугубляется тем, что каждый участник мог понять всё по-своему и в таком искаженном виде донести информацию до других членов команды.
Документирование позволит:
Лучше понять эти самые потребности: когда перед глазами есть текст, то гораздо проще найти в нем ошибки, логические неточности, сформировать вопросы, про которые не подумал в первый раз, подвергнуть формальному анализу — об этом почти вся остальная часть статьи. Когда этот текст находится у тебя "в голове" в виде неструктурированного и часто "аморфного" ощущения, то такой анализ сделать практически невозможно.
Лучше коммуницировать с командой: когда есть текст, то любой участник может точно так же найти в нем неточности и задать вопросы. Одна голова хорошо, а несколько — лучше :)
Быстрее подключать к проекту новых людей.
Валидировать решение: понять, что реализованная функциональность решает то, ради чего она задумывалась.
Это трудоемкий процесс, но пренебрегать этим не стоит, особенно в сложных проектах. Просто начните документировать "как можете", а дальше улучшайте с помощью описанных ниже практик. Например, проверяйте через верхнеуровневый чек-лист, про который будет написано ниже.
Дополнительные материалы по теме:
2. Проверять описанные потребности через верхнеуровневый чек-лист
С помощью этого чек-листа можно проверять свои артефакты или артефакты, которые вы получили на вход от заказчика, бизнес-аналитика, Product Owner'а или других источников.
Проводим "тест на коробку из-под обуви": берем формулировки и заменяем в них все названия системы на "коробка из-под обуви". Если смысл формулировки не меняется, то это повод насторожиться, скорее всего пропущена важная специфика вашей предметной области. "Система должна помогать проводить расследования" -> "Коробка из-под обуви должна помогать проводить расследования". Ну да, в нее можно, например, складывать бумаги по расследованию, чтобы не потерялись — вполне себе помощь в расследовании! Но для команды разработки такая формулировка бесполезна.
Проверяем контекст и пропущенные ролевые описания. Должно быть как-то так:
Из описания можно понять контекст использования запрашиваемой функциональности: кто принимает участие в автоматизируемом системой процессе, какие есть смежные системы, какова их функция и пр. Для понимания контекста помогут несколько конкретных примеров из "жизни заказчика", где возникает необходимость в этой функциональности. Обращаем внимание на язык — если в нем слишком много внутренних терминов из нашей системы, а не терминов из предметной области заказчика, то это повод насторожиться.
Из описания можно определить роли, для которых делается доработка или которые она затрагивает косвенно или напрямую.
Для каждой роли понятны задачи, которые система должна помочь решить человеку, находящемуся в данной роли. В некоторых случаях система должна не помогать, а наоборот, создавать максимум препятствий для решения задачи. Например, для "негативных ролей": мошенников, недобросовестных администраторов и пр.
Решаемые ролью задачи должны быть связаны с бизнес-сценариями, а не со сценариями работы пользователя внутри системы. Чтобы понять, выбрана ли задача правильно, можно воспользоваться такой эвристикой: получает ли человек в этой роли за выполнение этой задачи зарплату. Например, офицеру безопасности платят не за составление "поискового запроса в DLP-системе", а за проработанный инцидент ИБ: своевременно выявлен нарушитель; выявлено и предотвращено намерение "слива" конфиденциальной информации и пр. Либо могут быть описаны задача и гипотеза сценария внутри системы, но проведена цепочка причинно-следственных связей до бизнес-сценария.
Проверяем полноту и корректность причинно-следственных цепочек. Связь между задачей и бизнес-сценарием не должна иметь пропущенных причинно-следственных цепочек. Пример пропущенных цепочек:
> Офицер безопасности хочет получить информацию про файлы, который Петров копировал с рабочего компьютера на флешки 12 декабря 2021. Ему нужен этот список, чтобы обеспечить безопасность своей организации. Пропущена цепочка или несколько цепочек, где объясняется для чего ему эта информация, что он с ней будет делать и как это приводит к обеспечению безопасности. От информации в пропущенных цепочках будет зависеть, например, атрибутный состав события копирования на флешку (только метаданные файлов, их содержимое и пр.), а от этого может сильно зависеть архитектура решения. |
> Через API нужно выгружать список пользователей и действий, которые они совершили в нашей системе. Это нужно, чтобы руководитель смог сделать отчет и выявлять среди своих подчиненных самых неэффективных. Пропущена цепочка, связанная с тем, как именно руководитель будет принимать решение об эффективности сотрудников. От этого может сильно поменяться состав данных, которые нужно выгружать через API. |
Дополнительные материалы по теме:
про роли, потребности, системные уровни (то, что определяет "язык" описаний) — в книге "Практическое системное мышление 2022";
про чек-листы — в книге "Чек-лист. Как избежать глупых ошибок, ведущих к фатальным последствиям";
про причинно-следственные связи и пропущенные цепочки в объяснениях:
статья и видео Максима Дорофеева про обоснование причинно-следственных связей;
статья "Cause-effect diagrams: A pragmatic way of doing root-cause analysis";
3. Проводить более глубокий анализ проблемы
Такой анализ позволяет лучше понять проблему: насколько она частая, насколько актуальная для заказчиков. Занимает больше времени, чем верхнеуровневый чек-лист, но позволяет выявить больше деталей. Также позволяет делать описание в более структурированном виде. Можно применять как до верхнеуровневого чек-листа, так и отдельно от него.
Получаем и документируем ответы на вопросы:
В чем состоит проблема/потребность, для которой нужна новая функциональность?
Выясняется общая пользовательская задача или проблема. Это может быть как "широкая"/жизненная/рабочая/общая потребность, по сути не связанная с нашим продуктом, так и как проблема, возникающая именно при использовании нашего продукта (эвристику см. в практике "Верхнеуровневый чек-лист"). Проблема может быть описана как в виде пошагового сценария, так и просто текстом. Если есть информация, то добавлять описание, как часто встречается эта проблема, когда она встречалась последний раз — дает понимание, что это действительно важная задача, которую нужно решать.
Как пользователи сейчас решают задачу? Описание текущего бизнес-процесса.
Выясняется то, как сейчас пользователь закрывает потребность/решает проблему. Текущим решением проблемы может быть необязательно наш продукт, это может быть другой софт или административные меры в организации. Если пользователь вообще никак не закрывает потребность и даже не пытается её решить, то это повод насторожиться — возможно (но не обязательно!), выбранная проблема недостаточно важна для наших потребителей, и они не будут готовы заплатить за её решение.
Какие проблемы пользователи испытывают с текущим решением? Как они сейчас эти проблемы решают?
Это те проблемы, которые мы планируем решить разработкой новой функциональности.
Какие проблемы испытывает наша компания с текущим решением? Как мы их решаем? Есть ли у конкурентов такая функциональность?
Изменения в продукте могут быть вызваны необязательно потребностями заказчиков, а также потребностями нашей компании. Например, большие затраты отдела внедрения на обновление системы у заказчиков; большое количество обращений в техподдержку с типовыми вопросами и пр.
Дополнительные материалы по теме:
4. Использовать DSM (design structure matrix)
При первичной проработке решения часто учитываются только видимые/очевидные модули системы, которые нужно доработать или создать. Но так как в системе много связей, то изменения в смежных модулях не всегда очевидны. Их можно забыть и это выявится только на поздних этапах работы над новой функциональностью. Если иметь список связанных модулей, то можно задавать вопросы "наверх", то есть от нашей системы к надсистеме (организации заказчика, в бизнес-процессах которой участвует наша система): какая информация о бизнес-сценариях/потребностях нужна, чтобы принять решение о том, как должна выглядеть доработка в том или ином модуле системы? Какой информации нам не хватает, чтобы принять это решение? Не повлияет ли изменение в связанном модуле на другие бизнес-сценарии?
Часто изменение одного модуля требует внесения изменений в другой связанный модуль, но так как эти связи не всегда можно удерживать в голове и вспомнить в нужный момент, то необходим дополнительный инструмент: матрица связанности модулей — DSM (design structure matrix).
В столбцах и в строках размещаются сами модули, а на пересечениях — степень зависимости между ними, либо флаг, указывающий на наличие зависимости и опциональный комментарий, поясняющий суть зависимости.
Пример упрощенной матрицы для модулей автомобиля:
Метод применяется рекурсивно. Например, в рамках разработки одной функциональности изменили Модуль 1, по матрице выявили, что изменения в этом модули могут затрагивать Модуль 2. Анализируем выявленную связь и понимаем, что нужно вносить изменения и в Модуль 2 тоже. В свою очередь эти изменения в Модуле 2 затрагивают Модуль 10 и Модуль 15. Принимаем решения о доработке и этих модулей. Проверяем, как эти изменения связаны с другими модулями системы и т.д. При этом при проработке требований к этим связанным модулям могут возникать точечные вопросы к бизнес-сценариям. Также этот способ позволяет не забывать те модули, которые часто упускаются из виду.
Ниже пример того, как выглядят связи в одном из наших продуктов (на скриншот поместилось меньше половины модулей, а качество картинки ухудшено специально):
Ячейки с красным флажком — это связи, где добавлено текстовое примечание о том, на что следует обратить особое внимание.
Составить такую матрицу для своего продукта может быть трудоемким делом, особенно если это большой продукт. Но в конечном счете, это окупится сторицей, а поддержание матрицы в актуальном состоянии не займет много сил в времени.
Дополнительные материалы по теме:
Cайт dsmweb.org
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
