2 заметки с тегом

проектирование

Ликбез: менеджер проектов vs менеджер продуктов

​Люди из непродуктовых компаний часто спрашивают, чем отличаются менеджер проектов (Project Manager) и менеджер продуктов (Product Manager). 

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

Несмотря на то, что в ресторане блюда приготовлены правильно, вам сейчас они не подошли. Для вас это неправильные блюда. А мороженое — подходящее, правильное.

Разница между менеджером продукта и менеджером проекта примерно такая же, как между понятиями «сделать правильный продукт» и «сделать продукт правильно». 

Когда создается что-то новое — компьютерная игра, гоночный автомобиль, онлайн-сервис выдачи кредитов, смартфон, — то открывается проект. Собирается проектная команда и назначается менеджер проекта. Он будет отвечать за то, что в результате проекта получится продукт с согласованными заранее свойствами.  
Машина сможет разгоняться до 1500 км/ч, смартфон будет со встроенным счетчиком Гейгера, а для получения кредита не понадобится никаких документов вообще. Менеджер проекта будет отвечать за то, что этот продукт появится на рынке 1 января 2030 года, а перерасход бюджета не будет значительным. ) 

Менеджер проекта отвечает за то, что продукт будет создан правильно.

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

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

Менеджер продукта отвечает за то, что будет создан правильный продукт.

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

Еще раз: менеджер проекта делает продукт правильно, а менеджер продукта делает правильный продукт.

Важно: менеджер проекта и менеджер продукта — это роли. Часто их совмещает один человек. Это разумно для больших продуктов, которые делает несколько продуктовых команд, как в Авито. Или для маленьких продуктов с одной командой — как в стартапах, для экономии.

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

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

(c) Сергей Колганов aka http://t.me/psilonsk

4 мес   проектирование

Как ставить задачи правильно

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

  1. Первое правило хорошо поставленной задачи — начните ее с глагола, а не с существительного.
    Плохо (отглагольное существительное):
    Тестирование модуля Х.
    Разработка функции Y.
    Хорошо (глагол):
    Протестировать модуль Х.
    Разработать функцию Y.
  1. Больше конкретики — конкретную задачу легче делать и проще контролировать. Задача создается, чтобы ответить на вопрос «что сделать?», а не «что делать?».
    Плохо (неконкретно):
    Обдумать риски в проекте А.
    Наметить дальнейшие шаги в проекте В.
    Хорошо (конкретно):
    Составить реестр рисков в проекте А.
    Создать план проекта В.
  1. Каждой задаче нужен срок исполнения. Нет дедлайна — нет стимула делать. Дедлайны дисциплинируют и помогают планировать.
    Плохо (нет срока):
    Создать документ D.
    Хорошо (есть срок):
    Создать документ D к 31.12.2020.
  1. Должны быть требования к результату. Нужно описать, что именно должно получиться, и что вообще считается выполненной задачей. Критерии выполнения — это важно.
  1. Описание должно включать все нужные для работы материалы. Исполнитель не должен бегать по разным источникам, по крупицам собирая информацию о задаче. Все, что ему нужно для выполнения, должно быть описано и приложено к задаче. То же касается любых ресурсов, которые нужны для выполнения задачи. Хочешь хорошего результата — создай человеку условия для работы.
4 мес   проектирование   работа   сервис