Какое место в жизненном цикле разработки продукта занимает улучшение процесса разработки?

Здесь, кажется, назревает несколько вопросов:

• Какая фаза или действие в жизненном цикле разработки продукта включает улучшение процесса?
• Необходимо ли улучшение процесса для достижения и поддержания целей продукта?
• Почему мы не видим KPI, связанных с улучшением процессов?

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

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

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

Вы задаете разные вопросы по одному и тому же утверждению, поэтому я предполагаю, что ваш основной вопрос сводится к

«Почему мой Владелец Продукта не расставляет приоритеты (или не делает их видимыми) усилия команды разработчиков, будь то технические или организационные?»

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

Почему кажется, что команды разработчиков продукта обычно упускают из виду явное включение процесса разработки в KPI продукта?

Кто определяет KPI? Если какое-либо командное измерение определяется изолированно, без какого-либо обсуждения с командой, мы возвращаемся (снова) к культуре высказываний, в которой нуждается команда. Agile-манифест напоминает нам, что работающее программное обеспечение является основным мерилом прогресса. KPI — это средство (и часто неправильно используемое) для достижения цели. Цель здесь – результат. Сосредоточьтесь на доставке работающего программного обеспечения и улучшении процессов , связанных с доставкой программного обеспечения. Это лучший способ продемонстрировать, что улучшения команды стоят вложений.

Я думаю, вы делаете правильное замечание: работа по улучшению должна быть частью KPI продукта .

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

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

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

Позвольте мне исследовать радикальную точку зрения, которая, как я признаю, может не помочь вам в вашей организационной среде. Во-первых, ваш превосходный вопрос указывает на еще одну причину, по которой многие agile-мыслители считают SDLC устаревшей моделью. Все проекты в некоторой степени зависят от предыдущей работы, и те, которые преуспевают, никогда по-настоящему не закрываются: есть просто новая основная версия. Кроме того, классические каскадные расписания и бюджеты неуместны в действительно гибкой организации. Таким образом, любые KPI, отражающие водопадное мышление, также не имеют значения.

Agile-команды должны быть самоорганизующимися, состоящими из мотивированных работников, которым доверяют, чтобы удовлетворить клиента. (В случае, который вы описываете, когда команда не взаимодействует напрямую с внешними клиентами, я бы рассматривал менеджера по продукту или подобную роль как «Клиента», а не как владельца продукта.) В моем подходе я рекомендую, чтобы команды придерживались возвращают не менее 10% своих возможностей в каждом спринте для работы над вещами, которые, как они знают, важны для удовлетворения Заказчика, даже если Заказчик этого не осознает: рефакторинг, исправление устаревших ошибок, улучшение процессов или инструментов и т. д. Они делают это создавая пользовательские истории для выполнения этой работы, чтобы она была прозрачной. При необходимости для некоторых из них можно создать ключевые показатели эффективности, например «количество устаревших ошибок» или «рабочее время на тикет исправления ошибки».

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