Заказная разработка. Часть первая — идеальная

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

И сразу 3 важных отступления:

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

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

3. Я кайфую с каждой картинки, которая родилась в процессе этого рассказа)

   Погнали!

Начнем с модели Что-Как

Все начинается с того ЧТО надо сделать, после чего ищется человек(подразделение, организация), который знает КАК это можно реализовать. Он в свою очередь задаёт свои запросы ЧТО и ищет других исполнителей КАК.

Эта моделька позволяет не только декомпозировать работы по функциям, но и увидеть, что каждый уровень реализации состоит из 2-х областей:

1. область вопросов;

2. область решений.

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

Но если на дизайн директор влиять не может, то на что же может?

Этот вопрос непосредственно связан с ответственностью, посмотреть на которую мы попробуем через другой инструмент — Impact Mapping.

Визуализируем

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

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

И тогда Ценность — это то, к какой из целей(их важность) и насколько быстро продвинет каждое из решений. Решения, расположенные в порядке убывания их ценности — и есть бэклог продукта.

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

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

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

Как-то так

Прекрасно!

Теперь объединим эти две модели: дадим каждому блоку ответственного и разделим на области вопросов/решений

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

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

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

До скорой встречи!