Я заканчивал менеджерить свой первый ecom проект в заказной разработке. Это было время ретроспектив и рефлексий о проделанной работе. А в моем случае, ещё и возможность сравнить полученный опыт с прошлым - работой в продуктовых командах. Своими мыслями и выводами я поделюсь с вами, поскольку нет лучшей формы для анализа, чем рассказ другому человеку.
И сразу 3 важных отступления:
Я хочу, чтобы мой страх(а он есть) получить критику, осуждение и минусов в карму проиграл моим же желаниям высказаться и ощутить радость от пользы, которую кто-то из вас сможет для себя получить;
Я надеюсь, что эту статью увидят люди, создающие продукты. Скорее всего, они не считают себя таковыми, а называются директорами, руководителями подразделений, менеджерами, в конце концов. Но обращаюсь я именно к этой их профессиональной субличности;
Я кайфую с каждой картинки, которая родилась в процессе этого рассказа)
Погнали!
Начнем с модели Что-Как
Все начинается с того ЧТО надо сделать, после чего ищется человек(подразделение, организация), который знает КАК это можно реализовать. Он в свою очередь задаёт свои запросы ЧТО и ищет других исполнителей КАК.
Эта моделька позволяет не только декомпозировать работы по функциям, но и увидеть, что каждый уровень реализации состоит из 2-х областей:
область вопросов;
область решений.
Между которыми проходит граница работы постановщика задачи и её исполнителя. А границы - это про права и обязанности. И если генеральный директор рассказывает дизайнеру какого цвета должны быть кнопки на сайте, то кто в итоге будет ответственный за низкую конверсию? Впрочем, про это позже.
Но если на дизайн директор влиять не может, то на что же может?
Этот вопрос непосредственно связан с ответственностью, посмотреть на которую мы попробуем через другой инструмент - Impact Mapping.
Визуализируем
Все начинается с бизнеса, который должен поставить цели и выразить их в конкретных измеримых метриках.
На втором этапе цели начинают гонять через работу с пользователем, аналитику и тестирование. В результате, находятся способы их достижения - Решения.
И тогда Ценность - это то, к какой из целей(их важность) и насколько быстро продвинет каждое из решений. Решения, расположенные в порядке убывания их ценности - и есть бэклог продукта.
Последний этап - это вариант реализации выбранного решения. На этом этапе появляется Цена - это то, сколько будет стоить(времени, денег) реализация выбранного решения.
Но это ещё не конец! Оптимальным, достаточным выбранное решение будет только в том случае, если мы вернем Цену на этап 2 и повторим оценку. Найти наилучшее сочетание Цены и Ценности - есть задача по нахождения кратчайшего пути к достижению бизнес-целей, обозначенных в начале.
И совсем уж для красоты, можно ещё ещё раз замкнуть систему, вернув полученный бэклог на первый этап и убедиться, что полученные сроки и цена позволят бизнесу достичь своих целей.
Как-то так
Прекрасно!
Теперь объединим эти две модели: дадим каждому блоку ответственного и разделим на области вопросов/решений
Вот теперь мы получили упрощенную, но идеальную систему. Систему, в которой бизнес отвечает за стратегию и говорит языком метрик, в которой продакт-менеджер формирует решения, в обосновании которых использует, в том числе, стоимость этих самых решений. И все это держится на обратных связях.
Ну а ломать эту модельку об реальность технических заданий, доп.соглашений и дедлайнов я буду в следующей своей статье. Просто потому, что найти мотивацию на две небольших задачи легче, чем на одну большую :-)
Если в этом месте кто-то из ваш уже прикинул свои рабочие процессы на эту схему, посмотрел кто какие роли занимает и как взаимодействует - буду рад любым вашим комментариям. Обязательно учту их не только в следующей публикации, но и лично для себя.
До скорой встречи!
