Web Analytics Made Easy - StatCounter
Главная Блог Миф продуктового подхода в процессах разработки

Миф продуктового подхода в процессах разработки

Миф продуктового подхода в процессах разработки

По мотивам Да кто вообще такой этот продуктовый разработчик?

Преамбула

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

В ролях

Менеджер проекта, директор проекта

Менеджер проекта

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

Менеджер продукта он же маркетолог

Менеджер проекта

Менеджер по продукту они же т.н. продакт-менеджер ничем не отличается от маркетолога, это человек в проекте отвечающий за анализ спроса и соответствие разработки этим задачам. Очевидно, что достигается это соответствие не беготнёй между рабочими местами разработчиков, а исследованием рынка, формированием плана и взаимодействием с руководством проекта.

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

Менеджер проекта

Результатом проекта является продукт. Можете даже записать себе куда-нибудь, если трудно запомнить. На этом заканчивается холивар проектного и продуктового подходов. Поле боя освещено полностью.

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

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

Уберите от экранов маркетологов

Менеджер проекта

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

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

Могу пилить, могу не пилить

Менеджер проекта

Представим себе стандартного разработчика. Ему всё равно для какого проекта писать код. Его задача - соответствие результата поставленной задаче. Забивать его голову проблемами борозжения большого космоса кораблями значит – как минимум – трату его времени, как максимум – уничтожение процессов способных принести результат. Ничего нового в организации работы нет со времен доисторического человека.

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

Менеджер проекта

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

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

Может всё намного проще? Может просто кто-то хочет получать свой оклад размывая ответственность?

Переменчивая среда

Менеджер проекта

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

Где здесь разница продуктового и проектного подходов? Вы проект делаете без учёта требований среды, а в продукте их учитываете? В проекте программист пишет код, а в разрабатывая продукт космический корабль к Альфе Центавра пилотирует?

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

Если реально востребованными на рынке функциями продукта становятся 2 из 10, то никто вам не мешает заложить в бюджет необходимый объём дополнительных работ. Может вся проблема в том, что маркетологам вместо бесполезных зомбо-собраний больше времени тратить на свои прямые обязанности? Глядишь, и функции будут правильно проектироваться не отрываясь от реальности и планирование ресурсов выйдет на новый уровень подняв окупаемость?

Зачем нужно MVP?

Менеджер проекта

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

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

Сухой остаток

Менеджер проекта

Что у нас осталось от темы после того как всё пустословие отброшено? Осталась группа единомышленников, которая делает работу, которая должна принести всем доход. Есть совладельцы, которые вкладывают деньги, но и в прибыли участвуют процентно. А есть просто сотрудники, которые работают за фиксированную зарплату и не участвуют в рисках и не делят прибыль. Всё честно - полномочия соответствуют ответственности.

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

Источники