Компания
27,11
рейтинг
2 декабря 2012 в 17:18

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

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

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

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

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

  1. “Бизнес” не умеет формулировать хорошие требования, потому что не понимает процесса разработки и технологических возможностей. Спецификация содержит представление заказчика о решении проблемы, докопаться до сути которой по документу сложно.

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

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


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

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

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

  1. User Personas Этот инструмент был заимствован разработчиками из интерактивного дизайна для максимального фокуса на проблемах и задачах пользователей. Описание Персон помогает команде разработки понимать нужды ключевых групп пользователей, формулировать и реализовывать требования с учетом их демографических данных, образа жизни и других общих характеристик.

  2. Impact mapping Это инструмент стратегического планирования, который помогает выстроить видение и предотвращает его потерю в “супе из фич” по ходу разработки. Карта влияний содержит цели бизнеса на следующую итерацию и помогает команде принимать решения в соответствии с ними. Также она защищает от недопонимания и ложных предположений о функциональности, помогает генерировать альтернативные идеи реализации, не требующие серьезных инвестиций в разработку.

  3. User Stories Формат описания требований в виде Пользовательских историй удобен для приоритезации, хранения и “приглашения” к более детальному диалогу бизнеса и разработки. Такой диалог должен случиться по принципу JIT (“точно вовремя”), то есть в момент, когда решение о разработке функциональности должно быть принято. Это позволяет не инвестировать много времени в детальную проработку требований, которые, возможно, не придется реализовывать. Такой формат использует язык бизнеса, содержит информацию о Персоне и Бизнес-ценности требования, с тем что бы поддерживать фокус разработчиков на видении и целях продукта/релиза/итерации.

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

  5. Kano Weighting Техника “взвешивания” требований, которая использует классификацию пользовательских предпочтений по 5-ти критериям удовлетворенности. Помогает ответить на вопрос — что является минимальным ценным объемом поставки продукта (MVP) и выбрать функциональность для реализации в следующей итерации.

  6. User Story Hamburger Инструмент декомпозиции требований, который позволяет в визуальной форме обсудить технические детали реализации и выбрать оптимальный с точек зрения красоты/сложности/стоимости путь. Полезен владельцам продуктов и разработчикам, которые испытывают трудности в разделении сложных историй на более простые с целью ускорения поставки и получения обратной связи. Так же полезен для явного обсуждения “достаточно великолепных” решений, как с точки зрения людей бизнеса, так и с точки зрения разработчиков.

  7. Specification by Example Инструмент организации приемочного тестирования, который влияет на процесс формулирования и управления требованиями. Позволяет улучшить взаимодействие бизнес-пользователей и разработчиков, повысить качество продуктов, снизить переобработку фич и “холостую” разработку на основе ложных предположений.

Детальную информация о каждой технике вы найдете по ссылкам, я лишь хотела обратить внимание на их существование. Вопросы практического применения этих инструментов буду рада осветить в отдельных статьях или при личном контакте.
Автор: @Natatara
SCRUMguides
рейтинг 27,11
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Комментарии (18)

  • 0
    Все эти техники предполагают, что мы знаем целевую аудиторию продукта. Но в реальной жизни это очень трудно технически, потому что:

    1. Пользователи, которые готовы ответить на вопросы интервью не обязательно входят в большинство пользователей продукта.
    2. Телеметрия позволяет определить «куда кликают», но не позволяет определить «зачем кликают». Интерфейс Windows 8 делался на основе телеметрии. И получил просто огромное количество критики.

    В результате «показале десяти знакомым, провели опрос на сайте, собрали фидбек — сделали. Оказалось никому не нужно.» — суровая правда жизни.
    • +7
      Чаще даже так: «Я показал жене, ей не понравилось, переделайте...». И это независимо от уровня проекта. А в идеале — да, все верно, все перечисленные техники очень полезны.
      • 0
        это хорошо когда жена, был случай «маме показал» =)
    • 0
      Мне показалось, что автор в бОльшей степени имел в виду разработку ПО для корпоративных заказчиков. Там ситуация с целевой аудиторией более определенная.
      Продукты, ориентированные на широкого пользователя, требуют чуть-чуть других подходов, и их успешность часто сводится к лотерее «попал, не попал». И если о том, что «не попал» компания-разработчик узнает на стадии бета-тестирования — можно считать, что ей повезло.
      • 0
        Мне показалось, что автор в бОльшей степени имел в виду разработку ПО для корпоративных заказчиков. Там ситуация с целевой аудиторией более определенная.


        Почему, если не секрет? Всегда можно пойти и поговорить с 2000+ офисными работниками заказчика, которые разговаривают на языке предметной области, компьютер понимают как телевизор с одноклассниками, не хотят ничего менять а хотят пива? :) Или, может, с представителем со стороны корпортативного заказчика, для которого компьютер — это тот же телевизор понятно с чем, но ему при этом надо еще бюджет отмыть и в свои офисные игры поиграть? :))
        • +1
          В таком случае, мы имеем представление о должностных обязанностях пользователей. Т.е. мы знаем, что они должны делать. А хотят они это делать или нет, нас не касается.
          Я согласен с вашими аргументами относительно овощной природы большинства пользователей, и это говорит о бесполезности опросов и фокус-групп. Автор их не предлагал. Использование Персон подразумевает другой подход.
          Мы не спрашиваем у юзеров, чего они хотят — они все хотят большую кнопку «Сделать хорошо!». Мы предполагаем их потребности исходя из их обязанностей. А удобство интерфейса из условий их работы. Эта информация у нас есть.
          А бегать вокруг них и спрашивать: «Ну, скажите, пожалуйста, что вам не нравится? Ну, расскажите, чего вы хотите?» — это нарываться на билет в пеший эротический тур. :-)
          Кстати, о потребностях и удобстве — помните, многие сильно ругали рибоны, когда они только появились? А сейчас это считается одной из самых удачных находок в области GUI за последнее время. Вот яркий пример того, что юзеры не знают, чего они хотят, пока не привыкнут к этому.
      • +1
        В продуктах широкой аудитории к вариативному набору описанных выше техник добавляется следование принципам Lean StartUp, один из которых — измерение.

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

        Метрики имеют особое значение для стартапов, особенно, нацеленных на массовый рынок. Лучший материал на эту тему в 5-ти минутном ролике Dave McClure — Startup Metrics for Pirates. Можно нагуглить более полезный и обширный материал по запросу «AARRR», но в этом видео Дейв просто душечка.
    • +1
      если вы что-то разрабатываете и не знаете ЦА — вы что то делаете не так.
      Вы пишите «продукт ради продукта», который нужен лишь вам или вашим воображаемым друзьям.
      Ваш продукт не решает проблемы пользователя, потому что если бы решал проблему — узнать у тех, у кого это проблема есть: как бы они хотели ее решить или устроит их ваше решение — вообще не сложно.
      Если это все же сложно — значит вы решаете надуманную проблему.
    • +1
      «Желание — 1000 возможностей, нежелание — 1000 причин».
  • +1
    “Бизнес” не умеет формулировать хорошие требования, потому что не понимает процесса разработки и технологических возможностей. Спецификация содержит представление заказчика о решении проблемы, докопаться до сути которой по документу сложно.

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

    “Бизнес” и “разработка” говорят на разных языках. Как следствие — ложное понимание требований, не проясненные предположения, вытекающие из них 'сюрпризы' в момент демонстрации.

    Если разработчик не понял задание, но сделал, то это проблема разработчика. Знание предметной области бизнеса — первое требование к разработке.
    • 0
      А бизнес и не должен уметь формулировать хорошие требования

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

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

      «Гамбургер истории» — несмотря на несерьезное название позволяет избежать довольно серьезных разногласий в том, какой способ реализации минимален и достаточен с точки зрения бизнеса (инвестиций в его исполнение) и разработки (качества, рисков, стоимости поддержки). Такие открытые обсуждения помогают сторонам с часто полярными интересами понять мотивы друг друга, не разрабатывать откровенно слабых решений и не заниматься излишним их «золочением» (Over Processing в терминах Lean TPS)
      • +1
        Истории пользователя, по моему мнению, это то, чем меньше всего нужно забивать голову. Приведу простой пример. Иван Иванович — фермер, решил расширить свой бизнес, путем автоматизации полевых работ. Он закупил два модных трактора, которые умеют рассказывать в режиме реального времени, какие GPS-координаты у техники на данный момент времени. Это натолкнуло Ивана Ивановича на мысль, что нужно бы написать некое ПО, которое сообщало бы о нецелевом использовании оборудования трактористами Вениамином и Илларионом. Давайте спросим у наших доблестных трактористов, какую функциональность нужно заложить в программу, чтобы им было что-то удобнее делать. Они расскажут, что неплохо было бы, чтобы программа травила анекдоты пока они гоняют по полю, дабы им не заснуть. Давайте спросим Ивана Ивановича об аналогичном. Он скажет, что неплохо было бы раз в сутки заходить в программу и видеть, что тракторы гоняли за пределы отведенной траектории. Вот тут начинается полет мысли «архитектора»… В реальности из всего придуманного полезно будет сделать одну вещь из пожеланий — отправка SMS Ивану Ивановичу с координатами трактора, если он выехал от разрешенной области передвижения дальше чем на 10 метров, и еще создать алгоритм оптимизации траектории движения, дабы минимизировать затраты на ГСМ. Первое решение помогает понять, что есть решения получше, чем рисует в голове заказчик, а второе — что он использует микроскоп для забивания гвоздей.
  • +1
    Формат Истории пользователя такой:
    Как <Пользователь>, я хочу <Действие с системой>, что бы <Бизнес-ценность>.

    Для описанного выше примера история может быть сформулирована так:

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

    Можно еще подумать над формулировкой и улучшить ее. Цель Истории — сделать понятным: кто и для чего будет использовать функциональность. Как только мы видим намек на техническое решение посередине <Действие с системой>, начинаем задавать больше вопросов о <Бизнес-ценности>.

    Записываем такие бизнес-требования чуть наперед. А детали и способ реализации обсуждаем «точно вовремя» — когда Иван Иванович сказал что готов заплатить за эту функциональность. Хорошо работает в итеративных подходах с приоритезацией требований и доступом к «телу заказчика» для уточнения деталей.
    • 0
      А теперь представьте, что случится с разработчиком и фермером, когда они узнают, что трактор все это умеет «из коробки»? Ему задаются координаты полигона, выезд за пределы которого приводит к выключению двигателя и уведомлению о нештатной ситуации? :)

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

      Самое смешное, что фермеру не нужно ПО по уведомлению о нецелевом использовании техники. Эту проблему можно решить административным путем, а не программой. Программа гипотетически может сократить расходы, на практике все будет прозаичнее — про нее забудут через пол года.
  • +1
    Давайте теперь составим Историю с другой стороны

    Так мы систему для кого разрабатываем? Конфликтующие требования вижу я :)

    Для поиска альтернативных (не требующих разработки) решений — отлично «Impact mapping» подходит. В ментальной карте будет ветка целей («Уменьшить кражи»), под ней — две Персоны, которые помогут добиться этой цели («Фермер» и «Сторож»), под ними — будут действия Персон («Уведомление» для Фермера и «Ружье с солью» для Сторожа). На мозговом штурме — фермер решит, стоит ли идти по первой ветке или Петра Петровича с ружбайкой будет достаточно.
    • 0
      Я бы задал вопрос, а нужна ли система вообще? Нужно ли уменьшать кражи? Понимаете какая фигня, бизнес зачастую готов нести определенные потери, только бы не увеличивать мнимый «порядок» в процессах, и, соответственно, расходы на поддержания этого псевдопорядка. Если вы скажете, что ваша программа сэкономит целых 10 000, то вам могут рассмеяться в лицо, потому что на фоне миллионных заработков это чуть меньше чем пшик.
      • 0
        А если сама программа при этом будет стоить 100 000, то становится совсем не интересно.
  • +1
    > Если разработчик не понял задание, но сделал, то это проблема разработчика. Знание предметной области бизнеса — первое требование к разработке.

    На нашем примере это не прокатит. В банке даже сами пользователи не знают всей предметной области, что уж говорить о программистах? Тут уже либо программируй, либо разбирайся в предметке, и предметкой занимаются бизнес-аналитики. А разработчики знакомятся с предметкой по ходу проекта, и то, кто с чем работал.
    Разработчик тут максимум что может сделать — это поставить под вопрос какие-то части задания, которые кажутся нелогичными в купе с предыдущими заданиями.

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

Самое читаемое Разработка