The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Каждый программный проект, над которым мы работаем, начинается с документа Видение продукта. Мы создаем его во время фазы размышлений. Несмотря на то, что документ состоит всего из двух страниц английского текста, его разработка является наиболее трудоемкой задачей во всем проекте.
Есть несколько хитростей и рекомендаций, которыми я хотел бы поделиться.
Мы обычно разрабатываем Видение продукта в четырех разделах: утверждение о продукте, заинтересованные стороны и их потребности, функции и требования к качеству.
Product Statement - это однопараграфное заявление о намерениях, объясняющее абсолютному незнакомцу, о чем и для чего предназначен данный продукт. Оно очень похоже на эскалаторное предложение. Заявление должно отвечать на следующие вопросы, предпочтительно в указанном порядке:
Что она хочет?
Что сейчас предлагается на рынке?
Что не так с существующими предложениями?
Как наш продукт исправит это?
Вы должны ответить на все эти вопросы, используя не более 60 слов в сумме. Если вам нужно больше слов, значит, ваше понимание разрабатываемого продукта неправильное. Если вы можете ответить на них, используя 20 слов, ваш продукт покорит мир.
Кстати, не путайте «Заявление о продукте» с Миссией, которая является более общим заявлением об общей цели вашего бизнеса. У вас может быть сто продуктов, но только одна миссия. Например, компания Disney говорит, что ее миссия состоит в том, чтобы делать людей счастливыми. У них есть сотни продуктов, которые помогают им достичь этой миссии. И каждый продукт имеет свое собственное заявление о продукте.
Я нахожу эти статьи полезными: Видение продукта, Артефакты Agile: Заявление о видении продукта, Искусство Agile-разработки: Видение.
Этот раздел должен перечислять всех, чья жизнь будет затронута продуктом (положительно или отрицательно). Ваш список заинтересованных сторон может включать: спонсоров, разработчиков, пользователей, конкурентов, правительство, банки, провайдеры веб-хостинга, Apple Store, хакеров и т. д.
Очень важно перечислить как позитивных, так и негативных заинтересованных сторон. Если ваш продукт собирается автоматизировать рутинные ручные операции, не забывайте о том, что кто-то может остаться без работы из-за этого. Независимо от того, насколько “хорош” ваш продукт, всегда есть “злой” аспект. Изобретение iPhone сделало миллионы людей счастливыми, но также вызвало много проблем для Nokia и Blackberry. Возможное изобретение вакцины от рака сделает миллионы людей здоровее, но также сделает тысячи онкологов безработными. Моя точка зрения заключается в том, что в любом проекте есть и позитивные, и негативные заинтересованные стороны.
У каждой заинтересованной стороны должен быть список потребностей. Они должны быть простыми и понятными, например, “зарабатывать деньги”, “увеличивать прибыль”, “делиться фотографиями” или “размещать веб-сайт”.
Я рекомендую определить одну или две потребности для каждой заинтересованной стороны. Если их больше трех, подумайте еще раз - вы действительно понимаете, что нужно вашим заинтересованным сторонам?
Ваш проект будет считаться успешным, если вы удовлетворите все потребности всех положительных заинтересованных сторон и нейтрализуете отрицательные.
Эта статья о потребностях и требованиях заинтересованных сторон из SEBOK будет полезной.
В данном разделе мы перечисляем актеров (сущности, взаимодействующие с продуктом) и основные функциональности, которые они используют. Это наиболее абстрактное определение функциональных требований продукта. Оно не должно быть подробным, а должно быть очень общим и абстрактным. Например, вот как взаимодействие с известным продуктом может быть описано всего лишь двумя строками:
Понятно ли для незнакомца о чем мы говорим здесь? Абсолютно нет - что такое “твит”, что означает “подписаться” и что такое “ретвит”? На эти вопросы нет ответов в документе о видении продукта, но ясно, что пользователь будет иметь доступ к четырем основным функциям. Все остальные функции будут похожи на них.
Twitter - это многомиллиардный бизнес с многомиллионным продуктом. Однако нам удалось объяснить его основные функции всего двумя строками текста. Вам следует сделать то же самое с вашим продуктом. Если вы не можете поместить все его функции в две-три строки, пересмотрите свое понимание продукта, который вы собираетесь разработать. Также ознакомьтесь с “дилеммой перегруженности функциями.”
Каждому актеру должно быть предоставлено не менее трех и не более шести функций. Если их больше, их следует как-то группировать. Если их меньше, разбейте их на более мелкие и подробные функции.
В данном разделе перечислены все важные нефункциональные требования. У любого продукта может быть сотни требований к качеству, а также сотни функций. Однако документ “Видение продукта” должен быть сосредоточен на наиболее важных из них. Рассмотрим некоторые примеры:
Также очень важно, чтобы требования были измеримыми (как каждый из этих примеров). Каждая строка в этом разделе является сообщением для разработчиков продукта. Они будут читать этот документ, чтобы понять, что наиболее важно для спонсора проекта. Например, следующие требования к качеству бесполезны: “пользовательский интерфейс должен быть привлекательным”, “веб-сайт должен быть быстрым” или “система должна быть стабильной”. Они неизмеримы и не поддаются тестированию. Все, что они делают, это отвлекают разработчиков. Если вы не можете сделать строгое и измеримое заявление о ваших целях качества, лучше ничего не писать. Лучше ничего не говорить, чем ставить ложные или неоднозначные цели.
Постарайтесь сделать этот раздел коротким. Здесь должно быть не более шести требований к качеству.
Каждый раздел не должен превышать двадцати строк. Даже если вы разрабатываете убийцу Google с бюджетом в 50 миллионов долларов, ваше Vision-документ должен быть не более двух страниц.
Для большинства моих клиентов это очень сложная и утомительная задача. Они обычно обращаются к нам с 50-страничным документом, объясняющим свои бизнес-идеи со всеми важными деталями. Из этого документа мы должны выделить только информацию, которая действительно имеет значение.
Документ Product Vision должен удерживать своего читателя на самом высоком уровне абстракции. Документ должен занимать меньше минуты для прочтения от начала до конца.
Если вы не можете сделать его кратким, значит, вы недостаточно хорошо понимаете свой продукт.
Вот пример очень простого видения продукта для убийцы Facebook:
Diplomacy
Мы следуем всем этим рекомендациям в наших проектах в Zerocracy. Вы также можете использовать их в своих проектах, но имейте в виду, что процесс определения Визии Продукта может быть очень болезненным. Иногда вы можете обидеть клиента, упрощая его “великую” бизнес-идею. “Действительно? Я готов заплатить 250 000 долларов за крутое решение, а вы говорите, что у вас всего десять строк? Ха!”
Чтобы избежать такой ситуации, разделите документацию клиента на две части. Первая часть будет включена в документ Визии Продукта; вторая часть будет называться “дополнительная документация” и будет содержать всю ценную информацию, полученную от клиента. Вы можете использовать эту документацию позже в процессе разработки продукта.
Однако не идите на компромиссы. Не позволяйте клиенту (или кому-либо еще) заставить вас раздувать Визию Продукта. Документ должен быть очень коротким и ясным.
Без лирики, только утверждения.
P.S. Все это мы обычно помещаем в начало Глоссария.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-22 at 10:21
