среда, 24 мая 2017 г.

Как мы пишем видение продукта

Каждый программный проект, с которым мы работаем, запускается из документа Vision. Мы создаем его во время фазы Обдумывание. Несмотря на то, что документ короток, две страницы текста, его разработка является самой кропотливой задачей во всем проекте.

Есть несколько трюков и рекомендаций, которыми я бы хотел поделиться.

Мы обычно разрабатываем видение продукта в четырех разделах: заявлении о продукте, заинтересованных сторонах и потребностях, функциях и требованиях к качеству.

Заявление о продукте

Заявление о продукте - это декларация о намерениях в один абзац, объясняющая совершенно незнакомому человеку, для чего этот продукт и для чего он нужен. Это очень похоже на лифт. Заявление должно отвечать на эти вопросы, предпочтительно в этом конкретном порядке:
 Кто заказчик?
 Что она хочет?
 Что такое предложение на рынке сейчас?
 Что не так с существующими предложениями?
 Как наш продукт это исправит?
Вы должны ответить на все эти вопросы менее чем за 60 слов. Если вам нужно больше слов, что-то не так с вашим пониманием разрабатываемого продукта. Если вы сможете ответить на них в 20 словах, ваш продукт покорит мир.

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

Я нахожу эти статьи полезными: The Product Vision, Agile Artifacts: The Product Vision Statement, The Art of Agile Development: Vision.

Заинтересованные стороны и потребности

В этом разделе должны быть перечислены все, чья жизнь будет затронута продуктом (положительно или отрицательно). В список заинтересованных сторон могут входить: спонсоры, разработчики, пользователи, конкуренты, правительство, банки, поставщики веб-хостинга, Apple Store, хакеры и т. Д.

Очень важно перечислить как положительных, так и отрицательных сторон. Если ваш продукт собирается автоматизировать рутинные рутинные операции, не забывайте, что из-за этого кто-то будет лишним. Независимо от того, насколько «хорош» ваш продукт, всегда есть «злая» сторона. Изобретение iPhone сделало миллионы людей счастливыми, но также вызвало массу неприятностей для Nokia и Blackberry. 
Окончательное изобретение противораковой вакцины сделает миллионы людей более здоровыми, но также сделает тысячи онкологов безработными. Я хочу сказать, что в любом проекте есть как положительные, так и отрицательные стороны.

Каждый участник должен иметь список потребностей. Они должны быть простыми и понятными, например «зарабатывать деньги», «увеличивать прибыль», «делиться фотографиями» или «размещать веб-сайт».

Я бы рекомендовал определить одну или две потребности для каждой заинтересованной стороны. Если их больше трех, подумайте еще раз - вы действительно понимаете, что нужно вашим заинтересованным сторонам?

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

Эти статьи будет полезна.

Актеры и особенности

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

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

Понятно ли для незнакомца, о чем мы говорим здесь? Абсолютно нет... что такое «твит», что значит «следовать» и что такое «ре-твит»? В документе Product Vision нет ответов на эти вопросы, но ясно, что у пользователя будут четыре основные функции. Все остальные функции будут схожи с таковыми.

Если вы не можете разместить все функции в 2-3 строках, пересмотрите свое понимание продукта

Twitter - многомиллиардный бизнес с многомиллионным продуктом. Однако нам удалось объяснить его ключевые особенности всего двумя строками текста. Вы должны сделать то же самое с вашим продуктом. Если вы не можете подогнать все свои функции в две-три строки, пересмотрите свое понимание продукта, который собираетесь разрабатывать. Кроме того, читайте о «дилемме раздумий функций».

У каждого актера должно быть как минимум три, максимум шесть функций. Если их больше, их необходимо сгруппировать. Если их меньше, разбейте их на более мелкие и более подробные функции.

Требования к качеству

В этом разделе перечислены все важные нефункциональные требования. Любой продукт может иметь сотни требований к качеству, а также сотни функций. Однако документ Product Vision должен быть сфокусирован на наиболее важных. Рассмотрим несколько примеров:
Любая веб-страница должна открываться менее чем за 300 мсек.
Общая стоимость владения должна составлять менее 5000 долл. США в месяц.
Мобильное приложение должно быть адаптировано к 10 + популярным размерам экрана.
Среднее время восстановления должно составлять менее 2 часов.
БД должна быть масштабируемой до 5 ТБ без увеличения затрат.
Лучше не говорить ничего, чем ставить ложные или неоднозначные цели

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

Попытайтесь сохранить этот раздел коротким. Должно быть не более шести требований к качеству.

Удалить шум

Каждая секция должна быть длиной не более двадцати строк. Даже если вы разрабатываете убийцу Google с бюджетом в 50 миллионов долларов, ваш документ Vision должен быть короче двух страниц.

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

Документ Vision Vision должен держать читателя на самом высоком уровне абстракции. Чтение документа должно занимать меньше минуты, от начала до конца.

Если вы не можете сделать его коротким, вы недостаточно хорошо понимаете свой продукт.

пример
очень простого видения продукта для убийцы Facebook:

Facebook не позволяет пользователям покупать «понравившиеся», наша социальная сеть будет иметь возможность этого.

Заинтересованные стороны и потребности
  • Спонсор: привлечение инвестиций.
  • Разработчик: зарабатывать деньги программированием.
  • Пользователи: обмениваться фотографиями и приобретать популярность.
  • Банк: совершать комиссионные при каждой покупке.
  • Правительство: защищать общество от оскорбительного содержания.Конкуренты: стереть нас с рынка.

Актеры и особенности
  • Пользователь может создавать учетные записи, загружать фотографии, обмениваться фотографиями, отправлять личные сообщения, как и другие фотографии, покупать понравившиеся.
  • Администратор может заблокировать учетные записи пользователей, просмотреть сводные отчеты, авторизовать
  • Операции с кредитными картами, настройка параметров системы,
  • Контролировать использование ресурсов сервера.Банк может обрабатывать транзакции по кредитным картам.

Требования к качеству
  • Любая страница должна открываться менее чем за 300 мсек.
  • Доступность должна быть более 99,999%.
  • Тестовое покрытие должно быть более 80%.
  • Разработка должна быть полностью автоматизирована.
  • Интерфейсы должны включать веб-сайт и приложение iOS / Android.

Дипломатия

Мы следим за всеми этими рекомендациями в наших проектах, в teamed.io. Вы можете использовать их и в своих проектах, но имейте в виду, что процесс определения видения продукта может быть очень болезненным. Иногда вы можете оскорбить клиента, упростив «отличную» бизнес-идею. «Правда? Я готов заплатить 250 000 долларов за что-то удивительное, и ты хочешь сказать, что у тебя есть только десять строк для этого?»

Не позволяйте клиенту заставлять вас разжижать видение продукта

Чтобы обойти эту ситуацию, разбейте документацию клиента на две части. Первая часть будет вписываться в документ Product Vision; Вторая будет называться «Дополнительная документация» и будет содержать всю ту ценную информацию, которую вы получили от клиента. Вы можете использовать эту документацию позже, в ходе разработки продукта.

Но не обрезайте углы. Не позволяйте клиенту (или кому-либо еще) принуждать вас к разжижению Vision Vision. Документ должен быть очень коротким и ясным.

PS. В довершение всего мы помещаем Глоссарий.

Комментариев нет:

Отправить комментарий