Когда мы заказываем костюм в ателье или дизайн интерьера, нас не просят прийти с готовыми мерками, выбранным фасоном или цветом потолка. Профессиональные модельеры и дизайнеры задают вопросы и предлагают решения на основе наших целей.
Однако, от заказчиков программной разработки, мы часто ожидаем получить готовую спецификацию требований.
Чуть лучше дело обстоит в продуктовой разработке, особенно в стартапах, где генерация требований равномерно распределена по всему жизненному циклу работы над продуктом. Благодаря принципам Lean StartUp: построить -> измерить -> изучить, продуктовые команды работают более короткими циклами. На входе каждой итерации — новая порция требований для «эксперимента», в формулирование которых часто вовлечена вся команда.
В заказной разработке я наблюдаю 3 типа проблем, связанных с ожиданием готовых требований от клиента:
- “Бизнес” не умеет формулировать хорошие требования, потому что не понимает процесса разработки и технологических возможностей. Спецификация содержит представление заказчика о решении проблемы, докопаться до сути которой по документу сложно.
- “Бизнесу” не хватает времени на проработку требований. Часть вариантов использования системы, не продуманная заранее, вбрасывается в ходе разработки. Чем меньше практик, поддерживающих итеративный процесс (CI, автоматизированное тестирование, ограничение по количеству фич в работе), тем сложнее вносить изменения в требования.
- “Бизнес” и “разработка” говорят на разном языке. Как следствие — ложное понимание требований, не проясненные предположения, вытекающие из них 'сюрпризы' в момент демонстрации. Несуществующую систему сложно описать на бумаге. Отсюда вытекают проблемы, которые можно обобщить словами заказчика: “Я не знаю точно чего хочу, но точно знаю чего не хочу”.
Очевидно, что и формулирование проблем и поиск технических решений будет проходить легче и эффективнее, если обе стороны — бизнес и разработка, будут вовлечены в этот процесс.
Как же помочь клиенту, горящему идеей продукта — сформулировать ее ясно, на языке бизнеса и проблемы. Как избежать навязывания решений, излишней и преждевременной детализации требований? Как сократить время на понимание рынка, пользователей, ценности требований и критериев успешности их реализации?
Ниже — обзор продуктовых техник, которые могут в этом помочь.
- User Personas Этот инструмент был заимствован разработчиками из интерактивного дизайна для максимального фокуса на проблемах и задачах пользователей. Описание Персон помогает команде разработки понимать нужды ключевых групп пользователей, формулировать и реализовывать требования с учетом их демографических данных, образа жизни и других общих характеристик.
- Impact mapping Это инструмент стратегического планирования, который помогает выстроить видение и предотвращает его потерю в “супе из фич” по ходу разработки. Карта влияний содержит цели бизнеса на следующую итерацию и помогает команде принимать решения в соответствии с ними. Также она защищает от недопонимания и ложных предположений о функциональности, помогает генерировать альтернативные идеи реализации, не требующие серьезных инвестиций в разработку.
- User Stories Формат описания требований в виде Пользовательских историй удобен для приоритезации, хранения и “приглашения” к более детальному диалогу бизнеса и разработки. Такой диалог должен случиться по принципу JIT (“точно вовремя”), то есть в момент, когда решение о разработке функциональности должно быть принято. Это позволяет не инвестировать много времени в детальную проработку требований, которые, возможно, не придется реализовывать. Такой формат использует язык бизнеса, содержит информацию о Персоне и Бизнес-ценности требования, с тем что бы поддерживать фокус разработчиков на видении и целях продукта/релиза/итерации.
- User Story Mapping Подход, позволяющий получить высокоуровневую модель требований, которая описывает типы пользователей и сценарии их взаимодействия с продуктом. Создание карты пользовательских историй может быть одним из типов мозгового штурма перед началом разработки продукта. Вместе с тем, этот инструмент может использоваться для планирования релиза и выбора функциональности которая в него войдет.
- Kano Weighting Техника “взвешивания” требований, которая использует классификацию пользовательских предпочтений по 5-ти критериям удовлетворенности. Помогает ответить на вопрос — что является минимальным ценным объемом поставки продукта (MVP) и выбрать функциональность для реализации в следующей итерации.
- User Story Hamburger Инструмент декомпозиции требований, который позволяет в визуальной форме обсудить технические детали реализации и выбрать оптимальный с точек зрения красоты/сложности/стоимости путь. Полезен владельцам продуктов и разработчикам, которые испытывают трудности в разделении сложных историй на более простые с целью ускорения поставки и получения обратной связи. Так же полезен для явного обсуждения “достаточно великолепных” решений, как с точки зрения людей бизнеса, так и с точки зрения разработчиков.
- Specification by Example Инструмент организации приемочного тестирования, который влияет на процесс формулирования и управления требованиями. Позволяет улучшить взаимодействие бизнес-пользователей и разработчиков, повысить качество продуктов, снизить переобработку фич и “холостую” разработку на основе ложных предположений.
Детальную информация о каждой технике вы найдете по ссылкам, я лишь хотела обратить внимание на их существование. Вопросы практического применения этих инструментов буду рада осветить в отдельных статьях или при личном контакте.
Автор: Natatara
