Что общего у директора по продукту (CPO) и робота C-3PO?

Не только названия. Вспомните черты этого легендарного дроида из «Звёздных войнов».

C-3PO изначально создавался как дипломат и голос разума среди людей — а это как раз те качества, которые нужны любому продакту. Но, увы, робота-руководителя нам никто не соберёт.

В гибких организациях за стратегическое видение продукта отвечает именно CPO (Chief Product Officer). Он поддерживает культуру постоянных улучшений, обеспечивает прозрачность и согласованность действий всех команд.

Но самое главное — он объединяет между собой разработчиков, дизайнеров, маркетологов, руководителей компании и бизнес-заказчиков, чтобы все смотрели в одном направлении. Также, как C-3PO объединяет разные культуры, используя шесть миллионов форм общения.

Справился бы C-3PO с управлением продуктом?

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

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

Друзья, уже в ближайший понедельник мы проведём бесплатный вебинар Основные ошибки в применении фреймворков масштабирования SAFe, LeSS и Flight Levels.

📅 10 марта в 19:00 (GMT+3)

Ведущий Артём Гринякин — тренер в области Agile и современных методик управления.

На вебинаре разберём

• Типичные ошибки при внедрении SAFe, LeSS и FlightLevels — как их избежать и сэкономить деньги при трансформации.
• Стратегии трансформации с минимальными рисками — практические советы от экспертов, прошедших через подобные изменения.
• Методы вовлечения сотрудников и руководства.
• Практические кейсы и примеры из реальной жизни.

📎 Чтобы принять участие, регистрируйтесь по ссылке.

Крайне интересный факт, если это правда. Похоже, самый длинный контракт на разработку ПО в истории.

Конечно, его необходимо отменить, но интересно то, что его точно не следует заменять на модель оплаты по результатам (пожалуйста!).

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

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

Всегда есть место для изменений в требованиях, но оплата по результатам — это по сути контракт с фиксированной ценой и фиксированным объёмом работ.

Вот почему Agile подход здесь необходим и должен использоваться в любом случае.


Исходный текст со скриншота:
“Существует закономерность во всех государственных учреждениях, где контракты на "модернизацию" ИТ не оплачивают результаты/производительность; вместо этого они платят за время.
Следовательно, у подрядчиков есть стимул "никогда не заканчивать", что приводит к невероятным растратам.

Например, модернизация Налоговой службы США (IRS) началась в 1990 году с планируемым завершением в 1996 году. Сегодня работа не завершена, и подрядчики говорят, что до завершения ещё 5 лет. 29 лет отставания от графика и примерно 15 млрд долларов перерасхода бюджета.
Проигрывают все, кроме государственных подрядчиков. Это должно измениться.

На этой неделе IRS заморозила контракты на модернизацию на сумму около 1,5 млрд долларов, ни один из которых не влияет на подачу налоговых деклараций. Все эти контракты будут либо отменены, либо условия контрактов будут изменены на оплату по результатам.”

Как вам такое? 🙂