Продуктовая команда

Основу команды составляют менеджер продукта и ведущий инженер.

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

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

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

За готовность продукта к эксплуатации отвечает тестировщик.

Если в проекте требуется математическое моделирование и интеллектуальный анализ данных, команда дополняется новой ролью - аналитик данных (data scientist).

Формирование команд

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

Автономность команды

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

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

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

Должностные обязанности менеджера продукта

Менеджер продукта 1 (стажер)

Вы выполняете больше административную функцию. Работа под руководством наставника.

Менеджер продукта 1 (начинающий)

Самостоятельно работаете с командой и заинтересованными лицами, решаете проблемы в рамках своей компетенции. Для перехода на данный уровень требуется создать «минимально жизнеспособный продукт (MVP)» совместно с наставником или руководителем бизнес-подразделения.

Обязанности

  1. Документация

    1. Ведение дорожной карты продукта

    2. Ведение базы знаний продукта

    3. Составление протоколов собраний с командой и заинтересованными лицами, телефонных разговоров

  2. Коммуникация

    1. Встречи с командой

    2. Коммуникация со связанными командами

    3. Коммуникация с заинтересованными лицами: своевременное сообщение проблем, планов, рисков. Заинтересованные лица должны знать, что происходит.

Менеджер продукта 2 (ведущий)

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

Обязанности

  1. Руководство разработкой

    1. Приоритизация работ.Выбор наиболее эффективных по соотношению затрат/эффекта инициатив. Предложение собственных инициатив.

  2. Принятие решений

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

Менеджер продукта 3 (старший)

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

Обязанности

  1. Принятие решений

    1. Формулируете метрики продукта

    2. Формулируете видение продукта и дорожную карту для его достижения. Владеете «сегментом» дорожной карты продукта.

Менеджер продукта 3 (эксперт)

Обязанности:

  1. Руководство профильной командой

Оценка результатов работы менеджера продукта

Оценку результатов работы менеджера продукта можно разбить на 43направления:

  1. Финансовое направление: Оценка влияния инициатив (реализованного функционала продукта и/или орг. иницитив без участия команды инженеров) на метрики продукта. Оценивается способность менеджера продукта переводить аналитику продукта (анализ данных) в эффективные инициативы по улучшению метрик.

  2. Клиентское направление: отношение потребителей к продукту: довольны клиенты реализованным продуктом, привлечение и сохранение пользователей продукта (больше для внешних продуктов).

  3. Управление и коммуникация: способность эффективно управлять командой разработки, сотрудничать с заинтересованными сторонами. Способность улучшать командную работу, налаживать эффективную коммуникацию.

Принятие решений

Работа менеджера продукта — принятие решений. Основная суть продуктовых решений заключается в анализе затрат/эффекта. Ни одна, даже самая незначительная доработка продукта не является бесплатной. То, что можно сделать за 5 минут выливается в часы и дни тестирования, сопровождения, обучения пользователей. Кроме того, всегда присутствуют альтернативные издержки, ведь любая вещь в продукте делается за счет не делания другого. При решении проблем следует рассматривать и предпочитать решения, не затрагивающие команду разработчиков. Если что-то можно решить административно, это следует сделать. Ваша команда уже занята разработкой функционала.

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

У вас нет такой цели — не совершать ошибки. Но если вы все же добились этого и в одном прекрасном проекте не совершили ни одной ошибки. Хорошо это или плохо? Да, вы не потратили время на исправление ошибок. Но сколько лишнего времени вы потратили на такой перфекционизм? Возможно что стоимость исправления большинства ошибок была бы не больше одного дня, а сколько времени потратили вы, чтобы их избежать?

Анализ данных

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

Анализ данных - критическая вещь в проектировании продукта. Бизнес все больше становится математикой, управляется математической статистикой и данными. Для управления этим нужны особые люди, понимающие как устроены данные, как устроены математические модели бизнеса; способные принимать решения, основанные на данных.

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

Коммуникация

Менеджер продукта должен иметь развитые навыки коммуникации. Команда инженеров, заинтересованные лица и CEO компании желают видеть совершенно разную перспективу.

Менеджер продукта - это голос бизнеса. Если вы не понимаете бизнес-цели проекта, вы никогда их не достигните.

Менеджер продукта - это голос пользователя. Если вы не понимаете своих пользователей, вы никогда не создадите хорошие продукты.

Менеджер продукта никогда не будет иметь достаточной квалификации для принятия всех решений. Задача менеджера продукта — предоставление необходимой для принятия решений информации инженерам и аналитикам.

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

Обучение и мотивация

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

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

Должен ли менеджер продукта уметь программировать?

Нет, но понимать программный интерфейс приложений и структуру данных нужно.

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

Должен ли менеджер продукта понимать психологию?

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

Инженер

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

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

Инженер — не прост «кодер», выучивший язык программирования. Создавая код, инженер интерпретирует правила и понимание внешнего мира. Инженер не может эффективно написать то, что он не понимает.

Инженер — это не «робот», выполняющий планы, созданные другими. Инженер - это специалист-универсал. Он является одновременно архитектором, аналитиком, тестировщиком, примеряя все эти роли в ходе разработки продукта.

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

Должностные обязанности инженера

Инженер 1 (стажер)

Работа под руководством наставника.

Инженер 1 (начинающий)

При окончании испытательного срока присваивается навык «начинающий».

Обязанности:

  1. Самостоятельное решение задач

  2. Написание модульных тестов

Инженер 2 (ведущий)

Развиваясь, вы достигаете уровня «средний». На этом уровне вы успешно и эффективно выполняете работу, зная и применяя основные методологии и подходы.

Обязанности:

  1. Применение лучших практик (DDD+TDD)

  2. Уборка в проектах. Устраняете технический долг, своевременно проводите рефакторинг.

  3. Актуализация документации

  4. Наставничество над предыдущим уровнем

Инженер 2 (ведущий+)

Обязанности:

  1. Рецензирование программного кода.

  2. Проектирование приложений (DDD)

  3. Делегирование задач

Инженер 3 (старший)

Обязанности:

  1. Формирование лучших практик. Уточнение и пополнение профильных методических документов для улучшения работы подразделения.

  2. Понимание бизнес-проблем. Вы должны понимать, какие проблемы решает поставленная задача — рост рентабельности, снижение рисков, рост продаж?

  3. Планирование работ. Вы можете спланировать перечень шагов для решения задачи, при возможности делегировать или разделить их со своим помощником.

  4. Наставничество над предыдущим уровнем

Инженер 3 (эксперт)

Обязанности:

  1. Глубокое знание отдельной специфической области. Вы являетесь экспертом в области фронт или бэк разработки, сфере машинного обучения или аналитики. Проводите мастер-классы и ведет профильный раздел документации.

  2. Руководство профильной командой

Инженер 3 (тимлид)

Обязанности:

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

  2. Проактивная деятельность направленная на улучшение метрик продукта. Владея продуктом, вы понимаете, что может привести к улучшению метрик и выдвигаете собственные предложения команде.

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

Архитектор

  1. Проектирование платформы

Оценка результатов работы инженера

  1. Качественный код, созданный в соответствии со стандартами и рекомендациями кодирования, отражающий предметную область.

  2. Протестированный код. Не хрупкий и не ломающийся при каждой доработке продукта.

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

Аналитик данных

“Software is eating the world, but AI is going to eat software”, Jensen Huang (CEO, Nvidia)

Задача аналитика - построение математических моделей, статистически отражающих ведение бизнеса и поведение клиентов.

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

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

QA-Инженер

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

Должностные обязанности QA-Инженера

Основное направление развития QA-Инженера — смещение работ к проектированию продукта.

QA-Инженер 1 (стажер)

Работа под руководством наставника.

QA-Инженер 1 (начинающий)

Обязанности:

  1. Ручное регрессионное тестирование

QA-Инженер 2 (ведущий)

Обязанности:

  1. Формулирование критериев приемки

  2. Формулирование сценариев тестирования

QA-Инженер 2 (ведущий+)

Обязанности:

  1. Написание автоматизированных критериев приемки

QA-Инженер 3 (старший)

На данном уровне QA-Инженер разрабатывает независимые проверочные реализации алгоритмов на языке программирования.

Обязанности:

  1. Автоматизированные тесты на языке программирование

  2. Тестирование API

QA-Инженер 3 (эксперт)

Обязанности:

  1. Руководство профильной командой

Оценка результатов работы QA-Инженера

  1. Статистка ошибок — количество тикетов/ошибок после выкладки функционала. Количество регрессионных ошибок (внесенных в старый функционал при разработке нового функционала)

  2. Полнота тестовых сценариев — реализация проверки максимально возможных вариантов исполнения программы с минимальным затратами

  3. Обучение/наставничество — простота подключения новых тестировщиков, возможность тестирования по готовым сценариям.

Заинтересованные лица

Заинтересованные лица (stakeholders) — бизнес и пользователи — участвуют в наполнении бизнес-слоя базы знаний проекта с целью максимального учета их интересов.