Люди. Процесс. Продукт.

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

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

Продукт = Процесс (Люди)

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

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

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

❌ Быстрые результаты, но плохие результаты без тестирования и проверки. ❌ Плохой
дизайн продукта без зацикливания пользователей
. QA и критерии приемлемости ❌ Низкий уровень внедрения функций без помощи пользователям в эксплуатации и устранении разногласий (и это лишь некоторые из них)

Как и продукт, процессы можно оптимизировать и повторять. Люди, которые управляют процессом, становятся менеджерами по продукту. Они НЕ менеджеры проектов, а менеджеры по продуктам процессов. В своей статье о ProductOps (ссылка в комментарии) Джон Катлер пишет: «Это требует управления продуктом и стратегии. Это также включает в себя системное мышление, проектирование услуг, операционные отбивные, обучение дизайну и опыт проведения экспериментов по изменению».

Я рекомендую применить свое мышление PM к проектированию процессов. Начните с другого MVP, минимально жизнеспособного процесса , и повторяйте его. Как бы вы ни проектировали его, никогда не забывайте, что ключевым компонентом процесса является постоянное согласование с вашими пользователями, заинтересованными сторонами межфункциональной команды, бизнес-целями и видением компании.

Продолжение следует