С появлением Agile-методологии появилось несколько разных ролей, которых раньше не существовало, например Scrum Master, Product Owner и т. д. Если организация следует Lipstick Agile, с увеличением ролей и людей команды постепенно делятся на внутренние группы. Двумя наиболее известными группами являются команда продукта, в которую входят роли, ориентированные на бизнес, такие как менеджер по продукту, владелец продукта и т. д., и команда разработки, которая включает в себя технические роли, такие как технический руководитель, разработчики и специалисты по обеспечению качества.

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

1. Несовпадение приоритетов

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

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

2. Отсутствие технической возможности.

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

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

3. Неэффективное распределение ресурсов

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

4. Проблемы коммуникации

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

5. Увеличение отставания, но снижение пропускной способности

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

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

6. Медленное принятие решений

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

7. Снижение морального духа сотрудников

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

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

8. Риск чрезмерных обещаний

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

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

9. Задолженность по качеству, технике и инновациям

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

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

10. Ложное ощущение молодости

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

Заключение

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