- PVSM.RU - https://www.pvsm.ru -

7 Продуктовых техник, на которые стоит обратить внимание разработчику

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

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

Чуть лучше дело обстоит в продуктовой разработке, особенно в стартапах, где генерация требований равномерно распределена по всему жизненному циклу работы над продуктом. Благодаря принципам Lean StartUp [1]: построить -> измерить -> изучить, продуктовые команды работают более короткими циклами. На входе каждой итерации — новая порция требований для «эксперимента», в формулирование которых часто вовлечена вся команда.

В заказной разработке я наблюдаю 3 типа проблем, связанных с ожиданием готовых требований от клиента:

  1. “Бизнес” не умеет формулировать хорошие требования, потому что не понимает процесса разработки и технологических возможностей. Спецификация содержит представление заказчика о решении проблемы, докопаться до сути которой по документу сложно.
  2. “Бизнесу” не хватает времени на проработку требований. Часть вариантов использования системы, не продуманная заранее, вбрасывается в ходе разработки. Чем меньше практик, поддерживающих итеративный процесс (CI, автоматизированное тестирование, ограничение по количеству фич в работе), тем сложнее вносить изменения в требования.
  3. “Бизнес” и “разработка” говорят на разном языке. Как следствие — ложное понимание требований, не проясненные предположения, вытекающие из них 'сюрпризы' в момент демонстрации. Несуществующую систему сложно описать на бумаге. Отсюда вытекают проблемы, которые можно обобщить словами заказчика: “Я не знаю точно чего хочу, но точно знаю чего не хочу”.

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

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

Ниже — обзор продуктовых техник, которые могут в этом помочь.

  1. User Personas [2] Этот инструмент был заимствован разработчиками из интерактивного дизайна для максимального фокуса на проблемах и задачах пользователей. Описание Персон помогает команде разработки понимать нужды ключевых групп пользователей, формулировать и реализовывать требования с учетом их демографических данных, образа жизни и других общих характеристик.
  2. Impact mapping [3] Это инструмент стратегического планирования, который помогает выстроить видение и предотвращает его потерю в “супе из фич” по ходу разработки. Карта влияний содержит цели бизнеса на следующую итерацию и помогает команде принимать решения в соответствии с ними. Также она защищает от недопонимания и ложных предположений о функциональности, помогает генерировать альтернативные идеи реализации, не требующие серьезных инвестиций в разработку.
  3. User Stories [4] Формат описания требований в виде Пользовательских историй удобен для приоритезации, хранения и “приглашения” к более детальному диалогу бизнеса и разработки. Такой диалог должен случиться по принципу JIT (“точно вовремя”), то есть в момент, когда решение о разработке функциональности должно быть принято. Это позволяет не инвестировать много времени в детальную проработку требований, которые, возможно, не придется реализовывать. Такой формат использует язык бизнеса, содержит информацию о Персоне и Бизнес-ценности требования, с тем что бы поддерживать фокус разработчиков на видении и целях продукта/релиза/итерации.
  4. User Story Mapping [5] Подход, позволяющий получить высокоуровневую модель требований, которая описывает типы пользователей и сценарии их взаимодействия с продуктом. Создание карты пользовательских историй может быть одним из типов мозгового штурма перед началом разработки продукта. Вместе с тем, этот инструмент может использоваться для планирования релиза и выбора функциональности которая в него войдет.
  5. Kano Weighting [6] Техника “взвешивания” требований, которая использует классификацию пользовательских предпочтений по 5-ти критериям удовлетворенности. Помогает ответить на вопрос — что является минимальным ценным объемом поставки продукта (MVP) и выбрать функциональность для реализации в следующей итерации.
  6. User Story Hamburger [7] Инструмент декомпозиции требований, который позволяет в визуальной форме обсудить технические детали реализации и выбрать оптимальный с точек зрения красоты/сложности/стоимости путь. Полезен владельцам продуктов и разработчикам, которые испытывают трудности в разделении сложных историй на более простые с целью ускорения поставки и получения обратной связи. Так же полезен для явного обсуждения “достаточно великолепных” решений, как с точки зрения людей бизнеса, так и с точки зрения разработчиков.
  7. Specification by Example [8] Инструмент организации приемочного тестирования, который влияет на процесс формулирования и управления требованиями. Позволяет улучшить взаимодействие бизнес-пользователей и разработчиков, повысить качество продуктов, снизить переобработку фич и “холостую” разработку на основе ложных предположений.

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

Автор: Natatara

Источник [9]


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/razrabotka/21611

Ссылки в тексте:

[1] Lean StartUp: http://en.wikipedia.org/wiki/Lean_Startup

[2] User Personas: http://www.infoq.com/presentations/pragmatic-personas

[3] Impact mapping: http://impactmapping.org/

[4] User Stories: http://en.wikipedia.org/wiki/User_story

[5] User Story Mapping: http://www.agileproductdesign.com/presentations/user_story_mapping/index.html

[6] Kano Weighting: http://en.wikipedia.org/wiki/Kano_model

[7] User Story Hamburger : http://gojko.net/2012/01/23/splitting-user-stories-the-hamburger-method/

[8] Specification by Example : http://specificationbyexample.com/

[9] Источник: http://habrahabr.ru/post/161029/