Создайте функциональные группы

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

 

 

Приоритетность характеристик

Опираясь на видение проекта и здравый смысл, определите приоритет каждого элемента в нисходящем порядке – от самого важной в каждом списке.

 

 

Определение первого выпуска

Как только вышесказанное будет сделано, обдумайте каждый важный шаг в движении к заказчику от первого дня до реализации и что является самой ценной частью идеи в рамках этих шагов. Такой выбор может быть сложным и в конце концов зависеть от мнения, но мнение заказчика – или того, кто представляет собой его бизнес, – имеет решающую роль. Конечный результат шагов – тот приемлемый минимум для заказчика, которого проект должен достичь в этом шаге. Это обычно называется минимально жизнеспособным продуктом (minimum viable product, MVP) или минимально жизнеспособным выпуском (minimum viable release, MVR).

 

 

Один из больших плюсов – быстрое получение важной обратной связи от конечных пользователей, однако, чтобы составить свое мнение, им необходимо что-то довольно существенное. Невозможно получить значимую обратную связь о техническом процессе, но о новой форме заказа VegBox – вполне. Естественно, это будет частью минимально жизнеспособного продукта.

Стоить помнить, что чем больше всего будет в минимально жизнеспособном продукте, тем больше времени потребуется для получения обратной связи, тогда как если продукт будет слишком мал, будет недостаточно информации для получения обратной связи. Вам придется найти баланс между прибылью и риском – никакого универсального правила тут нет. Постарайтесь найти точку, в которой вы получите полезные отзывы о чем-то, что поможет вам принимать обоснованные решения. Это будет полезно и для анализа рынка.

Также обращайте внимание на термины. Для кого-то слово «выпуск» будет означать доступный для использования продукт, для других – продукт, предназначенный для тестирования закрытой группой. Помните, что всегда существует возможность сначала представить продукт малой группе, а уже потом выпустить продукт соответствующим образом. Главное, не делайте допущений, что все понимают термины одинаково! Нет абсолютно правильных подходов – выберите тот, что лучше подходит вам.

 

Добавление характеристик

Как только определено, что будет в минимально жизнеспособном продукте (MVP) или минимально жизнеспособном выпуске (MVR), начинается настоящее веселье. Дополнительный функционал или новые характеристики продукта могут добавляться по частям или быть частью большого релиза. Это называется инкрементная поставка, и бизнесмены ее очень любят. Никаких больше долгих лет ожидания одного большого выпуска со всеми «свистульками». Выпуск продукта в Agile-разработке происходит быстро и часто. И, опять же, именно заказчик определяет, что и когда выпускать. Как минимум отдельный выпуск должен содержать одну характеристику, проверенную практикой.

 

 

Получение информации

Результаты нашего первого релиза – наш MVP – достаточно эфемерны, и нам нужно больше деталей, чтобы превратить их в полноценный продукт. Польза этих результатов заключается в том, что на данном этапе мы формулируем идеи, поэтому было бы бесцельно вырабатывать полноценный профиль продукта, который необязательно будет использован. Более чем достаточно выработать общее видение и сформулировать MVP, при этом не реализовывая сам продукт. На следующем этапе нам предстоит выяснить положительные и отрицательные стороны продукта. Классический инструмент решения данной задачи – пользовательская история.

Расскажи мне историю

Пользовательские истории (user story) – короткие простые описания характеристик продукта с точки зрения человека, который собирается его использовать. Обычно это пользователь или покупатель. Пользовательские истории обычно следуют простому формату.

Будучи <тип пользователя>, мне нужно <цель> по <причина>.

 

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

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

Никто не заставляет вас использовать пользовательские истории. Однако эти истории напоминают нам о важности коллективных обсуждений, и результаты этих коллективных обсуждений нередко важнее подробного плана работ.

 

ДАТА ДОСТАВКИ

БУДУЧИ НЕПОСТОЯННЫМ ПОКУПАТЕЛЕМ

МНЕ НУЖНА ГАРАНТИРОВАННАЯ ДАТА ДОСТАВКИ В МОМЕНТ СОВЕРШЕНИЯ ЗАКАЗА

ПО ПРИЧИНЕ ТОГО, ЧТО Я ДОЛЖЕН ЗНАТЬ, КОГДА ОЖИДАТЬ СВОЙ ЗАКАЗ, ЧТОБЫ ОН НЕ СГНИЛ ПОД ДВЕРЬЮ

 

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