какие еще вы знаете примеры цифровых сервисов где использован продуктовый подход
Продуктовый подход — польза и для бизнеса, и для разработчика
Я продуктовый разработчик, но так было не всегда. Лет 5 назад я впервые услышал фразу «продуктовая разработка», но я тогда не совсем понимал, что это значит. Мне говорят — вот у нас продукт, ну а я пишу код и пишу, чего такого-то. Есть ТЗ — и славно, нет ТЗ — как говорится, и результат будет ХЗ
Но это на самом деле своего рода проектный подход. Вот есть у вас ТЗ, а за ним — много тяжелой, усердной работы. Люди упорно гребут, в голове у них только код. Потом проект закончился, все молодцы.
Потом что-то поменялось в моей работе — ТЗ не стало. Это такой следующий шажок. Вот мы в продукте работаем, а теперь у нас еще и ТЗ нет. И что делать? Началось осознание того, что происходит.
Во-первых, продукт не имеет четкого начала и конца. Нет каких-то границ. Вот в проекте у нас были границы. Например, количество функций, которые нужно сделать, количество разработчиков, которые работают над проектом, дедлайны всякие, когда проект должен закончиться. У продукта же таких границ нет, он живёт, и его надо развивать.
Приходит к нам бизнес и говорит — давайте экономить. Конкретно на SMS и на платежной форме. Мы соглашаемся. У нас так вышло, что в тот момент наша команда знала продукт лучше, чем владелец продукта, так бывает. Мы знали особенные кейсы, мы знали, что мы где-то лишних SMS немного тратим. А значит, примерно знали, где можно что поделать.
Так что мы взяли спринт на анализ, и за этот спринт мы не написали ни строчки кода. Вообще.
Зато мы много общались, много обсуждали, брейнштормили, накидывали гипотезы, оценивали их, предлагали, что можно сделать. Мы находили сценарии, где отправляются лишние смски, прикидывали, сколько этих SMS лишних мы отправляем. Мы же знаем стоимость одной SMS и, соответственно, знаем, сколько мы можем сэкономить. И по каждому сценарию примерно прикидывали, сколько будет стоить всё это сделать.
Затем мы из этих задач выстроили роадмап. В начало поставили такие низковисящие фрукты, которые легко сделать и которые дают явный эффект. А в конец — задачки посложнее, у одних из них эффект был послабее, а у других — более заметный.
Примеры задач
Например, вот задачка совсем простая. Есть пользователи, которые в настройках поставили галочку «логиниться только по паролю». А мы им зачем-то предлагаем логиниться по SMS. И они зачем-то эти SMS отправляют. Потом они вводят SMS, а потом они еще вводят пароль, хотя SMS можно было не вводить вообще. И пофиксить этот сценарий — это просто, что мы первым делом и сделали.
А вот посложнее задачка — перевести все SMS на пуши. Задачка достаточно грандиозная, у нас до сих пор идут работы, чтобы зафиналить этот перевод, потому что там много рефакторингов было, и мы написали много новых микросервисов и новые хранилки.
Вот мы написали роадмап, декомпозировали его, прикинули, составили план для каждой задачки, стали делать. Планомерно каждый спринт делали какую-то задачку, которая часть SMS срубала. И смотрели в реалтайме прямо на график, как меняется количество SMS. Мы видели, что продукт экономит. Прямо на глазах. Экономит — значит зарабатывает. Вот я смотрю на график и понимаю, что мы окупились в этот же спринт. Это очень круто по бизнес-эффекту. И понимаю, что мы как команда полезные. Мы окупаемся.
И еще на будущее вперед. Это же долгоиграющая штука, мы же теперь каждый месяц экономим много-много SMS. Меня лично это ощутимо мотивирует. И я очень рад осознавать, что я полезный.
Плюсы подхода
У этого подхода (когда разработчика пускают на ранний этап) есть несколько плюсов и для бизнеса, и для самих разработчиков.
Я начну с плюса для бизнеса. Разработчик может предложить решение по принципу Парето. То есть за 20% времени можно сделать 80% бизнес-эффекта, и бизнесу это в большинстве случаев ОК. Можно на раннем этапе привлечь разработчика и ограничить какое-то количество функциональности, чтобы сделать ни больше и ни меньше.
Разработчик, допустим, такой вот грамотный парень, бизнес-ориентированный, который понимает, зачем, что, как внутри рефакторить, он может предложить такой рефакторинг, который откроет портал в инженерный рай и оттуда начнут сыпаться фичи. Сами.
То есть не просто там кодить какие-то технически упоротые вещи, а именно сделать рефакторинг ради бизнеса. Ну мы так открыли портал в инженерный рай и оттуда насыпалось на форму оплаты несколько новых фич. Среди них — новый способ оплаты, да еще и пару багов пофиксили одним рефакторингом.
А ещё разработчик может на раннем этапе оценить стоимость разработки задачи. Понятно, что если это какая-то нереальная вещь, у нее сомнительный бизнес-эффект, ее можно дальше не прорабатывать и не собирать для нее какие-то бизнес-требования, а просто отложить и пойти дальше, что-то более приоритетное взять.
Разработчик, у которого есть знание доменной области и знание SQL, может посчитать количество SMS, которые отправляются в месяц по какому-то сценарию. И исходя из этого количества SMS можно понять, сколько денег эта задача принесет. То есть бизнес-эффект тоже можно оценивать с помощью разработчика. Причём для этого не нужен какой-то отдельный аналитик. Понятно, что разработчик это сделает с какой-то погрешностью, но все-таки это возможно.
Обычно у фронтендеров такой майндсет и такая насмотренность, что они могут набросать макет. А если этот человек в офисе, то он может этот макет людям показывать и проводить коридорное тестирование. Тоже плюс.
Самый главный пункт, на мой взгляд, это когда мы в команде задачу сами придумали, когда мы ее сами декомпозировали, предоценили, потом мы ее взяли делать, потом мы ее довели до продакшена и еще собрали постоценку (в идеале). Тут есть ощущение, что вот это моя фича, это наша задача, она становится частичкой нас. И отсюда большая мотивация, чтобы задачу протащить через все этапы, чтобы везде ее сопроводить, и в конце концов понять — была ли твоя работа полезной.
Отсюда следует первый плюс для разработчика — это дополнительная мотивация. Как я и сказал, когда я задачу прорабатываю, я с ней сближаюсь и хочу ее делать. И другие задачи я тоже хочу делать. Это работает сильнее, чем зарплаты и прочее. Вот просто хотеть делать задачи, чтобы чувствовать себя полезным.
Следующее — это прокачка скиллов. И хард-скиллы типа SQL, и софт-скиллы. Некоторым разработчикам сложно выйти из команды, чтобы пойти куда-то там наружу с другой командой договариваться. И вот это очень хороший толчок к развитию этого навыка.
Отдельным пунктом я вынес прокачку бизнес-мышления. Это очень важный навык для продуктового разработчика и не только. В принципе, если вы хотите основать стартап или занять ведущую роль в стартапе или в Big Tech компании, то понимать бизнес, понимать, как это работает на всех этапах, это прямо обязательно. И продуктовая разработка такого плана, когда ты задачу сам придумываешь и сам предоцениваешь, она заметно способствует тому, чтобы прокачаться в бизнес-мышлении.
Следующий пункт — нетворкинг. Когда человек идет из команды с кем-то общаться — с инфобезопасниками, с юристами, еще кем-то внешним — он приходит к людям, знакомится с ними. И в следующий раз, когда он к ним приходит, они знают, зачем он пришел и что ему надо, и многие вопросы решаются гораздо легче.
Ещё один пункт, я уже говорил про мотивацию, но есть еще мотивация другая. Когда приносишь больше пользы продукту, можно рассчитывать на взаимность. Когда есть реальный измеримый в деньгах эффект от твоей работы, можно рассчитывать и на какой-то быстрый хороший карьерный рост, на какую-то хорошую зарплату, и вот эта внутренняя мотивация — это тоже такое вознаграждение.
И последний пункт. Просто нравится. Попробуйте, может, вам тоже понравится.
Но есть нюансы
Мы в команде начинаем с того, что придумываем, а заканчиваем тем, что выкатываем в прод. А это же новые зоны ответственности, мы их раньше не брали на себя, и надо сделать это более качественно.И я тут не только про отсутствие багов, а больше про качественную предоценку и подготовку задач. У нас для того, чтобы сделать качественно, есть инструменты.
По сути, это чеклисты. Я рекомендую эти инструменты, даже если у вас не скрам, не аджайл, если вы вот это все ненавидите. Инструменты скрамовские, но вы можете их применять, даже если у вас вотерфолл — они просто помогут. Это не какие-то ограничители, это шпаргалки.
Вот есть шпаргалка для проработки задачи. Definition of Ready for sprint. Этот чеклист мы писали сами.
Это шпаргалка, но это не барьер. Мы можем на него посмотреть и подумать, что по задачке можно еще поделать предварительно, чтобы ее успеть в спринте. Но если владелец продукта говорит — надо, мы соглашаемся, мы ее возьмем, но мы ни на что не коммитимся.
То есть с большой вероятностью там вскроется какая-то неизвестность в спринте, которая нас затормозит, и мы что-то не сможем. Увы, такое бывает. Но не барьер, это важно.
А вот Definition of done — это барьер. Что такое Definition of done?
Бывает же, что программист говорит: — Я сделал.
А у него спрашивают: — Что ты сделал?
Отвечает: — Я код написал.
Если программист говорит, что он написал код, это даже не всегда значит, что он его отладил. Но для бизнеса нет никакой ценности от написанного кода. Просто написанного кода. Потому что нужно еще отладить, поревьювить, поправить после ревью, оттестировать, вывести в продакшен, обвесить мониторингом и собрать постоценку. Это в идеале.
DoD — чеклист, который позволяет договориться, когда говорить “Сделано” по задаче. Про DoD я сказал, что это барьер. Почему барьер? Потому что мы договорились с бизнесом, что мы продукт поддерживаем вот на таком уровне качества, не ниже. Этот чеклист — он про фиксацию уровня качества. Не Definition of Done команды, не Definition of Done компонента, а Definition of Done всего продукта.
И если мы что-то по Definition of Done, не успели за спринт сделать — печальная ситуация, но бывает. То мы берем эту несделанную работу и кладем ее в бэклог. И продакту нужно понимать, что есть некоторая несделанная работа, техдолг. Что ее придется потом когда-то сделать. А если ее не делать, она нас в будущем затормозит.
Мы все делаем сами. И чеклисты мы сами составляли, и процессы мы можем сами двигать как-то, если видим потребности, мы сами прорабатываем задачу, мы сами катим ее в продакшн, мы сами собираем постоценку.
Через это мы получаем некоторые профиты. Пять лет назад я не особо задумывался, пишу код и пишу. Это когда ты приходишь, в 9 утра начинаешь писать код, в 6 вечера можешь закончить и уйти домой.
Потом что-то менялось, и в какой-то момент пришло осознание — то как мы работаем, то зачем мы на работу приходим, оно очень сильно влияет на качество нашей жизни в целом.
На ментальное здоровье, на физическое здоровье, на отношение с близкими. Мы на работе проводим 80% времени. И очень важно то, как мы на работе кайфуем.
Я вам очень советую задуматься о ваших рабочих процессах и попробовать взять на себя больше ответственности по задачам. Вы можете попросить об этом своих тимлидов и менеджеров. А если вы сами тимлиды, то вы можете эту ответственность ребятам дать.
Если вам интересен взгляд на продуктовую разработку изнутри — подписывайтесь на мой TG-канал «Product Developer».
Продуктовый подход в цифровой экономике
Продукты можно разбить на группы, исходя из их особенностей:
Продуктовый менеджмент – комплекс действий по управлению продуктом на всех стадиях его жизненного цикла.
Жизненный цикл продукта – полный набор всех состояний («этапов»), через которые проходит продукт с момента появления первых идей о необходимости продукта до полного вывода продукта с рынка. Включает в себя поиск идей продукта, планирование продукта, проектирование продукта, разработка продукта, запуск и масштабирование, оптимизация и поддержка продукта. Этапы можно сгруппировать в три большие фазы:
Особенности продуктового менеджмента:
Особенность жизненного цикла продукта в условиях цифровой экономики: резкая динамика, быстротечность, высокая конкуренция, постоянное эволюционирование (создание новых или аналогичных продуктов на базе существующих и связанных с ними).
В цифровой экономике необходим специфичный цифровой продуктовый менеджмент на весь период существования продукта. Главный ресурс цифрового продуктового менеджмента – амбициозная продуктовая команда во главе с компетентным продакт-менеджером («владельцем продукта»).
Успешность продукта определяется во многом тем, насколько команда разработки учитывает интересы и потребности целевой аудитории. Целевая аудитория – это группа людей, которые вероятнее всего начнут пользоваться продуктом. Поэтому решающее значение для жизненного цикла продукта имеет то, как целевая аудитория воспримет продукт и какое ценностное предложение представлено целевой аудитории.
И. Роджерс (Е. Rogers) разделил всех потребителей на 5 групп по признаку «инновационной восприимчивости»:
В новой цифровой реальности государственные услуги должны существовать в формате продуктов цифровой экономики (цифровые продукты, цифровые сервисы, цифровые образы, цифровые двойники).
Граждане ожидают от государства высокого качества услуг, которое повысит их уровень и качество жизни. А бизнес-сообщество ожидает поддержки государства в создании лучших условий для ведения бизнеса (открытых данных, нормативных актов и т.д.). Изменения системы госуправления направлены на создание продуктов, которые позволят производить комплексные услуги для граждан и бизнеса.
Сервисное государство ориентировано на потребности людей и обеспечение услуг необходимого качества, условий, при которых гражданин будет тратить минимум сил и ресурсов для получения услуги, а предприниматель – для начала и ведения бизнеса.
Совершенствование технологий предоставления государственных услуг опирается на:
Что такое продуктовый подход к разработке мобильных приложений и чем он отличается от проектного
Практическое руководство от команды студии мобильной разработки Winfox для тех, кто хочет сделать рабочий продукт.
Можно вложить в разработку приложения пару миллионов рублей, нанять разработчиков из рейтинга Рунета, а на выходе получить приложение, которое не нужно пользователям. А можно сделать рабочий продукт небольшой командой и в сжатые сроки: приложение будет решать проблемы клиентов, они будут его устанавливать и использовать, и вы достигнете бизнес-целей. Вся разница в подходе: первый нацелен на процесс, а второй — на результат.
Мы в Winfox рекомендуем использовать второй подход. Он называется продуктовым.
В этом цикле статей мы расскажем про продуктовый подход к разработке мобильного приложения и поделимся опытом. Вы узнаете:
Статьи будут полезны тем, кто только задумывается о создании своего продукта, ищет разработчиков или уже начал делать приложение. Тезисы и примеры, которые мы приводим, помогут понять преимущества продуктового подхода и использовать его при создании приложения.
Продуктовый подход в широком смысле — это задача сделать правильный продукт. То есть тот продукт, который действительно нужен людям.
Первыми использовать продуктовый подход стали айти-компании, но потом их опыт переняли маркетологи, управленцы, дизайнеры и специалисты из других областей.
Продуктовый подход к разработке мобильных приложений — это задача проверить идею заказчика и найти продукт, который нужен пользователям и который решает их задачи, а потом упаковать этот продукт в приложение и помочь бизнесу на нем зарабатывать.
Суть продуктового подхода — в обнаружении продукта. Проверка идеи на старте позволяет заказчику не потратить деньги впустую, а разработчикам — не вкладывать знания и силы в проект, который не принесет бизнесу ни рубля. Разберем на примере, как происходит создание приложения с продуктовым подходом и без него.
Разработка без продуктового подхода. Иван начитался статей про то, как молодые предприниматели создают приложения и зарабатывают на них миллионы. И подумал: «А чем я хуже? У меня куча уникальных идей». Иван решил сделать приложение, в котором человек сможет купить парковочное место, когда захочет оставить машину у торгового центра или рядом с домом. Предприниматель бегло изучил рынок и понял, что такого сервиса нет. Вот она, золотая жила! Иван нашел разработчиков, заплатил им и они сделали приложение. Оно хорошо выглядит и интуитивно понятно, но водители не стали его устанавливать. Им просто не захотелось заморачиваться: удобнее искать места по старинке, а не открывать очередное приложение и скроллить бесконечную ленту с похожими вариантами.
Разработка с продуктовым подходом. Иван не стал полагаться только на себя и решил проверить, насколько его идея рабочая. Предприниматель нашел разработчиков, которые используют продуктовый подход. Разработчики провели анализ рынка и конкурентов, определили целевую аудиторию, быстро сделали MVP и протестировали его на потенциальных клиентах. Выяснилось, что приложение не пользуется популярностью — оно не нужно людям. Иван понял, что вкладываться в разработку приложения нет смысла: он только зря потратит деньги.
Разработчики предложили Ивану посмотреть в другом направлении. Водители часто не могут найти машину на огромной парковке торгового центра: это проблема. Было бы хорошо сделать приложение, которое эту проблему решает. Иван захотел проверить гипотезу с помощью MVP: за две недели приложение установило больше тысячи пользователей. Идея работает, на ней можно зарабатывать. В итоге Иван получил приложение, которое приносит ему несколько сотен тысяч в месяц. Разработчики собирают обратную связь от пользователей, постоянно дорабатывают и улучшают сервис, чтобы продукт максимально удовлетворял потребности клиентов. Доходность бизнеса растет.
Продуктовый подход помогает достигать бизнес-целей с минимальными затратами ресурсов и времени. Он избавляет заказчика и разработчиков от выполнения ненужных задач и усложнения процесса разработки.
Главная идея продуктового подхода — постоянное тестирование решений и идей, стремление адаптировать их к потребностям пользователя. То есть нацеленность на бизнес-результаты, а не желание скорее отдать заказчику код, получить деньги и забыть про приложение.
При проектном подходе разработчики стараются выполнить все пожелания заказчика, чтобы клиент остался доволен. Чтобы он потом вспоминал, как ребята работали над проектом: соблюдали сроки, всегда были на связи, четко следовали техническому заданию, а менеджер всегда расплывался в улыбке при встрече. Программисты не заморачиваются с тем, как будет работать продукт, принесёт ли он заказчику прибыль и закроет ли боли клиентов. Это не их часть работы.
Продуктовый подход — это всегда работа, направленная на конечный продукт и пользу, которую он приносит бизнесу. При продуктовом подходе другие приоритеты, тщательная проверка идеи на старте, более гибкий рабочий процесс. Рассказываем подробнее.
Определение целевой аудитории и ее проблемы — главная часть продуктового подхода. Тогда как многие сразу переходят к поиску и обсуждению идей, лучше сделать шаг назад и сначала тщательно определить свою целевую аудиторию и ее боль. А потом подумать, как можно позаботиться о пользователях и помочь им справиться с проблемой.
Например, вам нужно, чтобы пользователи вводили номер телефона в формате +7 (ХХХ) ХХХ-ХХ-ХХ. Так номер, который попадает в базу контактов, можно использовать для автоматических рассылок. Если пользователи будут вводить номера в других форматах, система их не идентифицирует — и рассылка не уйдёт. Это ваша задача. Но пользователям по большому счёту всё равно, как вводить цифры. Поэтому важно позаботиться о пользователях: помочь им делать так, как нужно вам, но при этом показать, что и для них это удобно. Хорошее решение — использовать маску ввода. Она исключает ввод данных в неверном формате, а пользователь видит в поле нужный формат телефона данных и вводит цифры в нем. Все довольны.
Продукт — это приложение, которое закрывает боли целевой аудитории и заботится о пользователях, а не просто помогает бизнесу решать свои задачи.
При продуктовом подходе разработчики не ждут от заказчика готовую концепцию, список требований к будущему приложению, свое видение бюджета и сроков реализации. Студия разработки подключается к проекту на этапе идеи и проверяет ее жизнеспособность. А потом вместе с заказчиком находит оптимальную экономическую модель и модель монетизации, с которыми приложение будет решать проблемы клиентов и приносить прибыль.
Представим, что вы хотите сделать приложение для поиска репетитора. Вы обратились с этой идеей к разработчикам, которые используют продуктовый подход. Ребята сначала проверят, насколько ваша идея жизнеспособна. Опросят знакомых, разместят опросы в социальных сетях, посмотрят динамику поисковых запросов по теме, изучат конкурентов, проанализируют потребности учащихся в тематических чатах и так далее. Если разработчики поймут, что идея рабочая, только тогда предложат вам дальнейший план действий. То есть возьмутся сделать MVP, чтобы тестировать продукт дальше, прикинут примерный бюджет и сроки.
Если мы понимаем, что идея заказчика не работает, говорим об этом прямо. Да, это может кому-то не понравиться: «Вы же исполнители, я вас нанял, чтобы вы делали то, что я говорю». Зато мы не делаем проекты в стол и отвечаем за каждый свой продукт. Мы уверены, что он работает.
Проект — это что-то, растянутое во времени. Продукт — это результат. А результат в бизнесе важно достигать как можно быстрее.
Допустим, вам нужно сделать приложение интернет-магазина. При проектном подходе вы сможете получать заказы от мобильных пользователей, когда приложение будет полностью готово: нарисован дизайн, прикручен весь необходимый функционал, проведено тестирование, исправлены баги. Это значит, что все время, пока вы работаете над приложением, вы упускаете выгоду: пользователи просто не могут заказывать ваш товар со смартфона и отдавать вам деньги, у них нет для этого инструмента.
При продуктовом подходе не нужно ждать, когда все будет идеально (в реальном мире так все равно не бывает). Вы можете сделать первую версию приложения с базовым функционалом и отдать его пользователям. Да, пока в приложении нельзя оплачивать заказы с помощью Apple Pay и оставлять чаевые курьеру. Зато оно выполняет главную функцию здесь и сейчас — продает ваш товар клиентам. Люди сейчас отдают вам деньги, а вы сейчас получаете доход и развиваете бизнес.
Продуктовый подход помогает ставить небольшие цели и получать эффект после каждого этапа, а не представлять работу над приложением как одну огромную сложную задачу с одним измеримым результатом.
При проектном подходе бюджет определен заранее. То есть неважно, какой результат показали разработчики в конце. Если они формально выполнили техническое задание, учли пожелания заказчика и уложились в сроки, они достигли цели. А значит, должны получить оплату по договору.
Когда команда использует продуктовый подход, заказчик четко понимает, за что платит. Обычно бюджет проекта поделен на части: разработчики сделали MVP и получили часть оплаты, а заказчик начал тестировать приложение и работать с ним, не дожидаясь завершения всей работы полностью.
При продуктовом подходе сложно четко определить стоимость всей работы в начале. В процессе часто появляются новые задачи, так как мы гибко реагируем на потребности пользователей, изменения рынка и пожелания заказчика. Но так как заказчик в этом случае платит не за процесс, а за результат, это все равно получается выгоднее.
Продуктовый подход — это про гибкость в принятии любых решений. Если рынок изменился и в приложение надо добавить новую функцию, это всегда можно быстро сделать.
При продуктовом подходе разработчики работают по спринтам — коротким интервалам времени, в течение которых они реализуют определенный объем задач. Один спринт заканчивается, начинается другой. При этом последовательность спринтов, их цели и содержание могут меняться — это не сломает рабочий процесс.
Допустим, вы делаете приложение для управления грузоперевозками, которым будут пользоваться водители грузовиков. Пока вы рисовали прототип, в России приняли закон о системе «Платон». Теперь все водители грузовиков тяжелее 12 тонн должны платить налог за пользование дорогами. И вы подумали: «Было бы здорово, чтобы водители могли оплачивать налог прямо в приложении. Так продукт будет еще полезнее». Вы рассказали об идее разработчикам, они добавили задачу в бэклог — список основных функций и характеристик продукта. Закончив один спринт, разработчики выбирают задачи для следующего спринта из бэклога: они могут поскорее добавить в приложение новую функцию.
При проектном подходе работа строится по изначально утвержденному техническому заданию. Вносить в него изменения по ходу нежелательно: это поломает работу и коммуникацию разных специалистов, которые трудятся над приложением. Если этап проектирования закончен — все, никаких больше новых функций до сдачи релиза. Хотите добавить в приложение возможность оплаты налога? Отлично. Давайте снова составлять техническое задание, делать прототип, рисовать дизайн, тестировать его и так далее, то есть проходить весь цикл разработки от и до. Никакой гибкости.
При проектном подходе тестирование — отдельный этап, к которому переходят после того, как приложение полностью готово. Из-за этого не всегда можно быстро проверить, как работает добавленная функция и не падает ли приложение после обновления iOS: надо ждать, когда все остальное будет готово.
Продуктовый подход, который строится на заботе о пользователях и стремлении решать их проблемы, предполагает быстрое добавление новых функций и выпуск обновлений. Выкатили релиз, собрали обратную связь, исправили баги и пошли дальше.
При проектном подходе пишут планы тестирования, а при продуктовом — изучают отзывы пользователей и правят баги. Тестирование новых фич, экранов и функций происходит постоянно. Благодаря этому у нас получается непрерывно улучшать продукт.
Менеджер проекта — связующее звено между заказчиком и разработчиками. Он отвечает за планирование, контролирует выполнение задач и сроки, следит за бюджетом, улаживает проблемы и отвечает за конечный результат. Несмотря на правильные цели, на практике работа проектного менеджера зачастую сводится к тому, чтобы угождать заказчику, выполнять условия договора и вписываться в бюджет.
Например, заказчик захотел убрать возможность постоплаты товара из приложения, чтобы быстрее получать деньги и увеличить оборотные средства. Сказал об этом менеджеру проекта, тот пошел к разработчикам, они все сделали. Но через пару месяцев заказчик пришел с новой проблемой: он открыл статистику и увидел, что из-за отключения возможности постоплаты теряет 15% заказов. Так что надо вернуть все как было. В итоге команда зря потратила время и не сделала продукт лучше для пользователя.
Когда над приложением работает продуктовый менеджер, он смотрит на все пожелания заказчика глазами клиента. Потому что главная цель заказчика и разработчиков — сделать хорошо клиенту, а от этого выиграет и бизнес. Продуктовый менеджер сначала проверит гипотезу заказчика. Прежде, чем идти к разработчикам, он изучит, как клиенты оплачивают покупки в приложении, и расскажет заказчику, к чему приведет его решение отключить постоплату.
Продуктовый менеджер поддерживает стабильную работу приложения в условиях постоянных изменений. Он одновременно слушает пользователя, заказчика и разработчика — и выбирает оптимальные решения для всех трех сторон.