Определение целей, результатов и продуктов проекта- pm-way

Работа над проектом и продуктом: в шкуре владельца

Проектная разработка

Хотя адепты гибких методологий и называют заказчика сайта Product Owner’ом — на деле же он таких функций не выполняет. Банкет оплачивает, иногда вторгается в уютный мирок заказной разработки со своей картиной мира и правочками. Но не больше.

У заказчика проекта минимум два оправдания, почему он не может быть тем самым овнером:

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

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

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

И дальше уже пошло-поехало: ТЗ, презентации, правочки. Стоп, снято, в продакшен.

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

Еще случай «другой истории» — когда у бизнеса есть доверенное агентство, взявшее на себя весь диджитал. Разные возникающие проекты агентство отдает аутсорс-продакшену.

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

Продуктовая разработка

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

И ни один нормальный продакт-овнер не спихнет такую важную миссию на аутсорсеров и не перепоручит безусому менеджеру. Другой уровень ответственности за результат переворачивает всё с ног на голову:

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

Теперь о том, как себя чувствует команда там и там.

Менеджер продукта и менеджер проекта — в чем разница

Проектная разработка

Менеджер проекта — это «свой парень». То есть, конечно, он немного из другой касты, но команда понимает: менеджер их защитит от неадекватных правок и нервотрепки.

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

С точки зрения экспертности проект-менеджера — он выступает для заказчика «консультантом по технологиям», дает экспертное мнение именно с точки зрения работы над проектом (а никак не с точки зрения бизнеса, здесь любая студия целиком полагается на экспертизу заказчика).

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

Продуктовая разработка

Вроде бы это тот же менеджер, вид сбоку, но нет. Главное отличие — продакт-менеджер является представителем бизнеса (умное слово: стейкхолдером).

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

На продукте внешней угрозы нет — все работают над одним большим делом. Следовательно менеджер для команды сам становится источником угрозы. Для них он — как номенклатурный работник для простых работяг.

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

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

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

Продукт проекта

Продукт проекта – материально измеримый результат проекта. Результат встреч с заинтересованными сторонами фиксация продуктов проекта. Описанный продукт проекта определяет результат, которые ожидает увидеть заинтересованные стороны в подтверждение факта завершения реализации проекта.

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

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

Рассмотрим пример продуктов организационного проекта по внедрению и развитию корпоративной системы управления проектами:

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

Рассмотрим пример продуктов строительного проекта для клиента:

Права собственности на землю и объект недвижимости.
Построенный дом.
Внутренняя отделка помещений.
Установленная мебель (кухня, встроенные шкафы и т.д.)
Охраняемая парковка.

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

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

Формы продуктов проектной деятельности

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

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

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

Дневник
путешествия по римским провинциям эпохи распада Империи и по СССР конца
1980-х гг. (видеомонтаж с собственным комментарием).
Популярное
пособие «Право на каждый день» (брошюра с рекомендациями и видеофильм).
Частотный
словарь английского молодежного сленга.
Главы из
учебника будущего «Биология и экология» 2500 года издания.
Манифест
Николая II «О даровании народу России Конституции», каким он мог бы быть.
Экологические
программы мониторинга питьевой воды, состояния радиационного фона и
воздушной среды в микрорайоне (по заказу управы района).
Сборник
научно-фантастических сочинений учащихся 6-го класса «Как принимали гостей
в средневековье».
Коллекция
софизмов, невозможных математических объектов и интересных чисел.

Основные требования к учебному проекту

Работа над проектом всегда
направлена на разрешение конкретной, причём социально-значимой проблемы —
исследовательской, информационной, практической. В идеальном случае проблема
ставится перед проектной группой внешним заказчиком. Например: учащиеся школы
посещают спортивный клуб, руководство которого заказывает проектной группе
дизайн оформления помещений клуба.

Планирование действий по
разрешению проблемы — иными словами, выполнение работы всегда начинается с проектирования
самого проекта, в частности — с определения вида продукта и формы
презентации

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

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

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

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

Таким
образом, проект — это «пять П»: проблема — проектирование
(планирование) — поиск информации — продукт — презентация. Шестое
«П» проекта — это его портфолио, т.е. папка, в которой собраны все
рабочие материалы, в том числе черновики, дневные планы, отчёты и др.

Продуктовая команда и команда «на потоке»

Проектная разработка

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

Причем в процессе такой яростной гонки один из гребцов встает посреди лодки и говорит: «ребята, меня позвали вон на тот круизный лайнер, до свидания!». После чего включает свой реактивный ранец и улетает в голубую даль.

Нормальная ситуация.

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

Итак, что можно взять для себя хорошего, работая в потоковом продакшене:

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

В продуктовой команде всё немного по-другому.

Продуктовая разработка

Программисты, которые ушли из студии и устроились в продукт — как правило, говорят о том, что там спокойнее. «Бесконечный» характер работы и отсутствие того самого подгорающего фитилька (и плеяды новых проектов на очереди) делают рабочий темп медленнее и вдумчивее.

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

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

Ну это утрированно, но в целом так.

В продукте сильнее бизнес-составляющая. Собственно, та система координат, в которой работает вся команда, от продакт-директора до стажера — это целевые пользователи, конверсии, маркетинговые исследования и так далее. Просто так собраться кучкой и решить «а давайте следующий сайт запилим на Реакте!» — не получится. Маркетологи скажут, на чем, почему и зачем вы будете делать следующий сайт.

Чему можно научиться, работая в продуктовой команде:

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

Сложно сказать, где команде работается лучше. Потоковая разработка — это отличное место для прокачки и развития «по горизонтали». Продуктовая — для углубления в какую-то одну тему. Вряд ли вы встретите человека, который бы хотел вернуться в потоковую разработку после продуктовой — как ни крути, а в продукте спокойнее (правда, если это типичный стартап, то «спокойствие» будет выражаться во впахивании по 12 часов в сутки).

Теперь о менеджменте всего этого.

Работа над проектом и продуктом: в шкуре владельца

Проектная разработка

У заказчика проекта минимум два оправдания, почему он не может быть тем самым овнером:

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

И дальше уже пошло-поехало: ТЗ, презентации, правочки. Стоп, снято, в продакшен.

Продуктовая разработка

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

Теперь о том, как себя чувствует команда там и там.

Сила приоритизации

Матрица 2×2 для определения приоритетов

Hygger

Сперва мы разрабатываем Quick Wins. Это фичи, которые приносят больше всего ценности, но которые можно быстро и легко реализовать.
Далее – Big Bets. Эти фичи могут принести много ценности, но их сложно реализовать.
Потом – Maybes – задачи или фичи, которые не дадут много ценности, но их легко внедрить. Их можно оставить на потом.
Наконец, Time Sinks. На эти фичи вообще не стоит обращать внимания.

Метод ICE Scoring

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

Метод RICE Scoring

Reach (Охват). Уровень охвата измеряется количеством людей/событий за определенный период времени. Этот фактор предназначен для оценки того, на какое количество людей каждая фича или проект повлияет в течение определенного периода времени, и сколько ваших пользователей увидят такие изменения.
Impact (Влияние). Влияние показывает какой вклад приносит эта фича продукту. Ценность понимается по-разному в каждом продукте. Например, в B2B SaaS продукте фичи могут получать высокое значение, если они улучшают trial-to-paid конверсию, помогать привлечь новых пользователей, добавляют ценности продукту и отстраивают от конкурентов и др.
Confidence (Уверенность в оценке). Если вы считаете, что фича может иметь огромное влияние, но у вас нет данных для доказательства этого, Confidence позволяет проконтролировать этот момент. Confidence измеряют в процентах.
Effort (Трудозатраты). Трудозатраты оцениваются как количество «человеко-месяцев», недель или часов, в зависимости от потребностей.

Планирование по системе GIST

Goals (цели)
Ideas (идеи)
Step-projects (проекты)
Tasks (задачи)

I — Ideas (идеи)

“убьете” идеи заранее
оставите идеи даже если у них сейчас очень низкий приоритет
не выделите идеи от ТОП-менеджмента
не следуете моде

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

T – Tasks (задачи)

Agile-ориентированные инструменты для планирования

Цели обычно устанавливаются с прицелом на один год или нескольких лет.
Идеи постоянно собираются и приоритизируются

Важно не переставать искать новые идеи.
Проекты определяются в начале квартала. Команда выбирает цели и идеи, которые она хочет выполнить в этом квартале, и соответственно определяет проекты

Задачи разбиваются на 1–2х недельные итерации в соответствии с вашим методом разработки и корректируются ежедневно.

цели сформулированы на четверть вперед, это достаточно просто.
метрики — вы выбираете ключевые метрики, которые покажут ваше движение к целям и на которые вы будете влиять с помощью идей. Отличный пример – OMTM (One metric that matter) или AARRR (Pirates metrics).
идеи – это гипотезы о том, как повысить ваши метрики.
фичи/задачи — конкретные задачи для разработчиков и других членов команды для реализации идей.