Как сделать описание продукта проекта

Обновлено: 06.07.2024

Презентация на тему: " Описание продукта Содержит описание характеристик продукта либо сервиса, который должен быть создан (разработан) в ходе проекта. Описание продукта обычно." — Транскрипт:

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

4 Пример продукт концерта - счастливое настроение слушателей или слава, пришедшая к группе. результат сам факт проведения концерта, который зафиксирован в договорах с концертным залом, музыкальным коллективом, 1000 проданных билетов, оборот в тенге и 7 вышедших в СМИ репортажей. То, какие результаты должны быть у проекта, определяет проектировщик.

5 Продукт и Результат Образование, душевное состояние, желания, стремления Получен ли продукт и насколько он хорош?

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

8 ЗАДАЧИ : Задачи - конкретные результаты, которые можно измерить или оценить и направленные на достижения цели, улучшают ситуацию и решают проблему в результате реализации проекта. Задачи проекта должны: быть настолько ясными и точными, соотноситься с целью проекта, определены по шкале времени по срокам ее достижения. Каждая задача должна быть сформулирована таким образом, чтобы Вы были способны понять, что Вы ее достигли. Задачи – не являются процессом это конечный результат.

11 Пользуйтесь критериями …….. при формулировке заданий, целей: Sspecific конкретность Mmeasurable исчисляемость Aachievable достижимость Rrealistic реалистичность Ttime-bound определенность во времени

12 Процессы инициации проекта В группу процессов инициации проекта входят два процесса: Процесс разработки Устава проекта. Процесс определения заинтересованных сторон проекта. Область знаний Группа процессов инициации 4. Управление интеграцией проекта 4.1 Разработка Устава проекта 5. Управление содержанием проекта 6. Управление сроками проекта 7.Управление стоимостью проекта 8.Управление качеством проекта 9.Управление человеческими ресурсами проекта 10.Управление коммуникациями проекта 10.1 Определение заинтересованных сторон проекта 11.Управление рисками проекта 12.Управление закупками проекта

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

14 Разработка Устава проекта Процесс разработки Устава проекта - это процесс разработки документа, который санкционирует начало проекта или начало фазы проекта В Уставе проекта обязательно санкционируются все требования заинтересованных сторон проекта. Проект считается формально открытым тогда, когда утвержден его Устав. Как правило, в момент разработки Устава проекта назначается Менеджер проекта (Руководитель проекта).

15 Устав проекта документирует бизнес- потребности, текущее понимание потребностей заказчика, а также новый продукт, услугу или результат, который планируется создать, например: назначение или обоснование проекта; измеримые цели проекта и соответствующие критерии успеха; требования высокого уровня; описание проекта высокого уровня; риски высокого уровня; сводное расписание контрольных событий; сводный бюджет; требования к одобрению проекта (что составляет успех проекта, кто решает, что проект оказался успешным, и кто подписывает проект); назначенный менеджер проекта, уровень ответственности и полномочий; имя и полномочия спонсора или другого лица (лиц), утверждающе го Устав проекта

18 План верхнего уровня

21 План затрат(бюджет) проекта

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

23 Информация о целях и ценностях является основной для успешного управления заинтересованными сторонами. Она дает возможность предсказывать, как заинтересованные стороны будут реагировать на проект и его результаты. Выходом данного процесса является Реестр заинтересованных сторон проекта. Заинтересованные стороны можно разделить на: внутренние внешние

24 Реестр заинтересованных сторон (Шаблон) Заинтересованная сторона (организация/ФИО/Должность) Категория (внешний/внутренний) Роль в проекте Требования Ожидания Степень влияния Заинтересованность (приверженность) Важность поддержки Что будем делать Сроки Бюджет Содержание Другое (в рамках управления отношениями)

25 III лекция (8 февраля 2012 год): Планирование проекта IV лекция (10 февраля 2012 год): Реализация проекта Мониторинг и контроль проекта Завершение проекта

26 Литература: Грей К. Ф., Ларсон Э. У. Управление проектами: практическое руководство – М.: Дело и сервис, 2003 Дитхелм Г. Управление проектами. В 2 т.: Пер с нем. – СПб.: Издательский дом Бизнес-пресса, 2004 Управление проектами /И.И.Мазур, Н.Г.Ольдерогге, В.Д.Шапиро. Москва, Разу М.Л. и др. Управление проектами. – М.: ИНФРА-М, Руководство к Своду знаний по управлению проектами - Четвертое издание (Руководство PMBOK).

- определение критериев успешности завершения проекта.

2. Разработка стратегического плана проекта:

- формирование основных подходов к реализации проекта;

- определение основных этапов реализации проекта.

Определение основных работ проекта:

- формирование ИСР двух уровней;

- разработка укрупненного расписания проекта;

- определение стоимости проекта.

Подготовка собственно обоснования.

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

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

Таким образом, при подготовке обоснования важно выполнить основные процессы планирования, сформировав ИСР двух уровней и расписание проекта. Процессы разработки плана проекта описаны ниже. Менеджер в каждом конкретном случае сможет применить упомянутые подходы для снижения степени риска в своем проекте.

3. Основные понятия этапа подготовки обоснования проекта;

Понятие целей проекта

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

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

- подготовить формализованное описание целей проекта;

- обеспечить мониторинг результатов вместе с функциональными лидерами проекта;

- осуществлять контроль и мониторинг прямых контактов с заказчиком;

- сформулировать основания для выполнения проекта (потребности, для удовлетворения которых проект предпринимается);

- описать результаты проекта — перечень результатов, достижение которых необходимо для завершения проекта;

- сформировать критерии приемки проекта — критерии, которые должны быть выполнены до приемки результатов поставки проекта;

- сформировать измеримые критерии успешности проекта — сроки, стоимость, качество и т.п.

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

Понятие продукта проекта

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

Понятие продукта проекта является ключевым для формирования всех последующих управленческих решений. Описание продукта документирует характеристики продукции или услуг, для производства которых предназначен проект. Фактически описание продукта является прообразом ТЗ на проект.

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

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

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

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

Все были согласны с бригадиром. . Они забыли один свой веселый разговор, когда они, семеро, сидя тут же, в чайной, толковали.

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

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


Как в фильме Начало (Inсeption), реальность в продуктовой разработке имеет определенную вложенность слоев. В зависимости от того, какая роль вам выпала, ваше “начало” в проекте может произойти раньше или позже, но всегда приятнее быть в числе создателей новой реальности, не так ли?

Эта статья — вступительная часть к трилогии о том, что собой представляет в гибкой продуктовой разработке:

  • Готовность Начать
  • Готовность Завершить
  • Готовность Выпустить

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



КОМАНДА ОТКРЫТИЯ ПРОДУКТА
Product Discovery Team

  • ценности продукта для бизнеса
  • удобства продукта для пользователей
  • реализуемости продукта в рамках времени и технологий

Минимальный “комплект” это хакер (технологии), хастлер (маркетинг) и дизайнер (юзабилити). Когда я говорила “никогда не экономьте на команде”, я имела в виду вот что: эти три роли — это “гены” вашего продукта. Вы никогда не знаете вначале, какой продукт вы “вырастите”, но профессионализм команды открытия, важен практически так же, как здоровые гены в физическом теле.

КОМАНДА ОТКРЫТИЯ: UX Дизайнеры
Из этих трех составляющих команды открытия, сложнее всего найти хорошего “дизайнера”. Дизайном эта функция называется условно — слишком большой метаморфозе подверглась профессия дизайнера за последние 10 лет. Здесь имеется в виду роль проектировщика архитектуры взаимодействия пользователя с продуктом. Так что хакеры в своем понимании дизайна как архитектуры, ближе к истине, чем люди бизнеса, которые представляют симпатичные картинки. Дизайн — это UX (архитектура взаимодействия), которая впоследствии дополняется Usability (удобством) и UI (красотой).

Многие владельцы продуктов, сталкиваясь со сложностью поиска хорошего дизайнера, решают аутсорсить эту функцию профессиональному агентству. Что ж, это может быть выходом, если вы создаете продукт “на заказ”. Но если речь идет о вашем, родном продукте, то аутсорсить проектирование UX и работу с пользователями, это все равно что аутсорсить отцовство.

Если хотите сэкономить на разработке — найдите людей, которые достаточно сыты самореализацией в корпоративном мире, гордостью за свои рейты на oDesk’е и экономическим благополучием. Несколько моих знакомых, ярких хакеров существенно опустились в гонорарах, потому что наступил период поверить в чей-то продукт и начать считать его своим. Это особенное чувство, вы знаете. Вам нужны такие люди, которые готовы пойти ва-банк, веря как в вашу идею так и в свое генетическое превосходство.

Если вы уже имеете дело с аутсорсингом, постарайтесь максимально включить команду в процесс открытия продукта. Под командой я имею в виду небольшие полнофункциональные составы “грабителей банков” (цитирую Максима Ткачука), в которых каждый хорош в своей специализации, при этом понимая суть и доверяя исполнению других ролей в своей “банде”.

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

Оптимальный состав такой “боевой команды” — 3-5 человек. Вовлечение большего числа участников влечет за собой накладные расходы на общение. Но вы можете овладеть искусством фасилитации и научиться работать в малых группах над параллельными задачами, затем объединяя их результаты.

КОМАНДА ОТКРЫТИЯ: Хастлеры
Эта роль (hustler) умышлено оставлена без перевода. На самом деле, самые приличные варианты перевода это “энергичный человек” и “пробивной делец”, но все из них явно указывают на качества, которыми должен обладать ее носитель. Что бывает, если в команде есть просто “человек с идеей”, без пробивных бизнес-качеств? Получается бизнес трусогномов .

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

Итак, предположим, вы собрали команду открытия продукта. Что дальше?

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

ШАГ 1. Определяем цели и принципы создания продукта.

  • Личные цели основателей
  • Цели бизнеса или организации
  • Принципы функционирования продукта

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

ШАГ 2. Оцениваем возможности продукта

Это можно сделать используя такие инструменты, как Business Model Cancas или Lean Canvas. Или же ответив на вопросы оценки возможностей продукта по Кагану:

  1. Какую конкретно проблему решает продукт? (предложение ценности)
  2. Для кого мы решаем эту проблему? (целевой рынок)
  3. Как мы будем измерять успех? (метрики бизнеса)
  4. Насколько велики возможности? (объем рынка)
  5. Какие есть альтернативы? (текущие конкуренты)
  6. Почему наш продукт лучше подходит для решения проблемы? (наши отличия)
  7. Почему сейчас подходящее время? (окно рынка)
  8. Как мы будем запускать продукт? (стратегия выхода)
  9. Какие факторы критичны для успеха? (требования и риски)
  10. Беремся / не беремся?

ШАГ 3. Идентифицируем ключевых клиентов и пользователей

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

Будте внимательны к тому, являются ли ваши будущие пользователи вашими “избирателями”? Будут ли они использовать ваш продукт по собственной воле или в его внедрении будет заинтересованы над-структуры? Например, если вы разрабатываете банковский сервис, то удобство пользователя будет не самым главным критерием выбора и всегда будет уступать место надежности и безопасности решения.

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

  • убедиться в наличие проблемы
  • узнать какими средствами она решается сейчас
  • получить идеи о вашем решении проблемы

ШАГ 5. Строим карту опыта пользователя “как есть”

Для этого подойдет любой инструмент, вроде составления линии времени или карта историй пользователя, описанной в следующем шаге. Цель этой активности — получить системное представление о ситуации “настоящего” для того, что бы разработать лучшее предложение “будушего”.

ШАГ 6. Строим карту взаимодействия с продуктом

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

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

ШАГ 7. Выбираем минимальный ценный продукт (MVP)

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

1. Уже на этом этапе вы можете проверить свою идею о ценности, попросив обратной связи на несуществующий продукт. Это занимает время.

Я понимаю, что тысяча коров не расскажут как приготовить хороший стейк, и что если бы Генри Форд спросил своих пользователей чего они хотят, то ему пришлось бы совершенствовать лошадь. Именно поэтому, интервью с пользователями и получение обратной связи лучше доверить профессиональному UX дизайнеру.

2. На этом этапе вам уже понадобятся наброски интерфейса пользователя. Их создание занимает время.
3. На этом этапе важно подумать о метриках успешности первой версии продукта и заложить функциональность, помогающую эти данные добыть.

Тема метрик крайне важна и заслуживает отдельной статьи. Предваряя разговор о разных системах и подходах в их создании (например, AARRR, или NSP), скажу довольно банальную вещь, которая лишь может натолкнуть на размышления.

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

Думаю, этого для Начала, этого достаточно. В следущей части постараюсь пройтись по важным деталям шагов 4-6 и обсудить Готовность начать разработку.

Читайте также: