The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Каждый программный проект, над которым мы работаем, начинается с документа «Product Vision». Мы создаем его во время этапа «Thinking». Несмотря на то, что документ состоит всего из двух страниц на английском языке, его разработка является наиболее трудоемкой задачей во всем проекте.
Есть несколько хитростей и рекомендаций, которыми я хотел бы поделиться.
Мы обычно разрабатываем Видение Продукта в четырех разделах: утверждение о продукте, заинтересованные стороны и потребности, функции и требования к качеству.
Product Statement
Product Statement - это однопараграфное заявление о намерениях, объясняющее абсолютно незнакомому человеку, о чем и для чего предназначен данный продукт. Оно очень похоже на английскую фразу “elevator pitch”. В этом заявлении должны быть ответы на следующие вопросы, желательно в указанном порядке:
“Кто является заказчиком?”
Что она хочет?
Что предлагает рынок сейчас?
Что не так с существующими предложениями?
Как наш продукт исправит это?
Вы должны ответить на все эти вопросы, используя не более 60 слов в сумме. Если вам нужно больше слов, значит, у вас неправильное понимание продукта, над которым работаете. Если вы можете ответить на них, используя всего 20 слов, ваш продукт покорит мир.
Кстати, не путайте “Предложение о продукте” с Миссией, которая является гораздо более широким заявлением об общей цели вашего бизнеса. У вас может быть сотня продуктов, но только одна миссия. Например, Disney говорит, что их миссия заключается в том, чтобы “делать людей счастливыми”. У них есть сотни продуктов, которые помогают им достигать этой миссии. И у каждого продукта есть свое собственное Предложение о продукте.
Я нахожу эти статьи полезными: The Product Vision, Agile Artifacts: The Product Vision Statement, The Art of Agile Development: Vision.
Stakeholders and Needs
Этот раздел должен перечислить всех, чья жизнь будет затронута продуктом (в положительном или отрицательном смысле). Ваш список заинтересованных лиц может включать: спонсоров, разработчиков, пользователей, конкурентов, государство, банки, провайдеры веб-хостинга, Apple Store, хакеров и т.д.
Очень важно перечислить как положительных, так и отрицательных заинтересованных сторон. Если ваш продукт будет автоматизировать рутинные ручные операции, не забывайте, что кто-то может быть сокращен из-за этого. Независимо от того, насколько “хорош” ваш продукт, всегда есть и “злой” аспект. Изобретение iPhone порадовало миллионы людей, но также вызвало много проблем для Nokia и Blackberry. Возможное изобретение вакцины от рака сделает миллионы людей здоровее, но также лишит работы тысячи онкологов. Мой посыл в том, что у любого проекта есть как положительные, так и отрицательные заинтересованные стороны.
Каждому участнику необходимо иметь список потребностей. Они должны быть простыми и прямолинейными, такими как “зарабатывать деньги”, “увеличивать прибыль”, “делиться фотографиями” или “размещать веб-сайт”.
Я бы рекомендовал определить одну или две потребности для каждого заинтересованного лица. Если их больше трех, подумайте еще раз - вы действительно понимаете, что нужно вашим заинтересованным лицам?
Ваш проект будет считаться успешным, если вы удовлетворите все потребности всех ваших позитивно настроенных заинтересованных сторон и обезвредите отрицательные.
Эта статья Stakeholder Needs and Requirements из SEBOK будет полезной.
Actors and Features
В этом разделе мы перечисляем актеров (сущности, взаимодействующие с продуктом) и ключевые функциональности, которые они используют. Это наиболее абстрактное определение функциональных требований продукта. Оно не требует детализации. Вместо этого оно должно быть на очень высоком уровне и абстрактным. Например, вот как может быть описано наше взаимодействие с известным продуктом в двух строках:
User can post tweets, read tweets of his friends,
follow new friends and re-tweet their tweets.
Ясно ли для незнакомца, о чем мы здесь говорим? Абсолютно нет - что такое “твит”, что означает “подписаться” и что такое “ретвит”? На эти вопросы нет ответов в документе Видения Продукта, но ясно, что у пользователя будут доступны четыре основных функции. Все остальные функции будут похожи на них.
Twitter - это многомиллиардный бизнес с многомиллионным продуктом. Однако нам удалось объяснить его ключевые особенности всего лишь двумя строками текста. Вы должны сделать то же самое со своим продуктом. Если вы не можете уместить все его функции в две-три строки, переосмыслите свое понимание продукта, который вы собираетесь разработать. Также прочитайте о “дилемме набухания функционала”.
Каждому актеру должно быть как минимум три, но не более шести характеристик. Если их больше, их следует как-то группировать. Если их меньше, разделите их на более мелкие и подробные характеристики.
Quality Requirements
В этом разделе перечислены все важные нефункциональные требования. У любого продукта может быть сотни требований к качеству, а также сотни функций. Однако документ Видения Продукта должен быть сфокусирован на самых важных из них. Рассмотрим несколько примеров:
Any web page must open in less than 300ms.
Total cost of ownership must be less than $5000/mo.
Mobile app must be tailored for 10+ popular screen sizes.
Mean time to recover must be less than 2 hours.
DB must be scalable up to 5Tb without cost increases.
Также очень важно, чтобы требования были измеримыми (как каждый из этих примеров). Каждая строка в этом разделе является сообщением для разработчиков продукта. Они будут читать этот документ, чтобы понять, что является наиболее важным для спонсора проекта. Например, такие требования к качеству бесполезны: “пользовательский интерфейс должен быть привлекательным”, “веб-сайт должен быть быстрым” или “система должна быть стабильной”. Они неизмеримы и не могут быть протестированы. Все, что они делают, это отвлекают разработчиков. Если вы не можете сделать строгое и измеримое заявление о своих качественных целях, лучше ничего не писать. Лучше сказать ничего, чем устанавливать ложные или двусмысленные цели здесь.
Постарайтесь сделать этот раздел кратким. Здесь должно быть не более шести требований к качеству.
Remove Noise
Каждый раздел не должен быть длиннее двадцати строк. Даже если вы разрабатываете Google-убийцу с бюджетом в 50 миллионов долларов, ваш документ Vision должен быть не более двух страниц.
Для большинства моих клиентов это очень сложное и утомительное задание. Они обычно обращаются к нам с 50-страничным документом, в котором подробно описывают свои бизнес-идеи со всеми важными деталями. Из этого документа нам нужно выделить только информацию, которая действительно имеет значение.
Документ «Видение продукта» должен оставаться на самом высоком уровне абстракции для своего читателя. Документ должен занимать менее минуты на прочтение от начала и до конца.
Если вы не можете сказать это кратко, значит, вы недостаточно хорошо понимаете свой продукт.
Example
Вот пример очень простого видения продукта для убийцы Facebook:
```text Statement Facebook doesn’t allow users to purchase “likes”, our social network will have this.
Stakeholders and Needs Sponsor: to raise investments. Developer: to earn money by programming. Users: to share photos and purchase popularity. Bank: to make commission on every purchase. Government: to protect society against abusive content. Competitors: to wipe us off the market.
Actors and Features User can create account, upload photos, share photos, send personal messages, like other photos, purchase likes. Admin can ban user accounts, view summary reports, authorize credit card transactions, configure system parameters, monitor server resource usage. Bank can process credit card transactions.
Quality Requirements Any page must open in less than 300ms. Availability must be over 99.999%. Test coverage must be over 80%. Development pipeline must be fully automated. Interfaces must include web site and iOS/Android app. ```
Diplomacy
Мы следуем всем этим рекомендациям в наших проектах в Zerocracy. Вы также можете использовать их в своих проектах, но имейте в виду, что процесс определения Видения Продукта может быть очень болезненным. Иногда вы можете обидеть клиента, упрощая их “великую” бизнес-идею. “Действительно? Я готов заплатить $250,000 за что-то потрясающее, а вы говорите, что у вас всего десять строк для этого? Что за?”
Чтобы обойти данную ситуацию, разделите документацию клиента на две части. Первая часть будет помещена в документ “Product Vision”; вторая будет называться “дополнительная документация” и будет содержать всю ценную информацию, полученную от клиента. Вы можете использовать эту документацию позднее, в ходе разработки продукта.
Но не позволяйте себе упрощений. Не допускайте, чтобы ваш клиент (или кто-либо еще) заставлял вас накачивать Продуктовое видение. Документ должен быть очень кратким и ясным.
Без текста песни, только утверждения.
П.С. Кроме всего перечисленного, мы обычно размещаем Глоссарий сверху.
Translated by ChatGPT gpt-3.5-turbo/35 on 2023-09-06 at 18:04
