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

Ускорение поставки возможно без увеличения числа разработчиков или рабочего времени благодаря тому, что в производственной системе много задач создают простои и замедляют общий процесс. Для отдельной задачи из всего времени, которое она находится в системе, в среднем 90% составляет время ожидания (для многих команд эта цифра достигает 95-97%). Сокращая количество работы в системе и фокусируясь на завершении текущих задач вместо начала новых, можно снизить время ожидания для отдельной задачи (например, с 95% до 70%), что приведет к повышению эффективности потока с типичных 3-10% до нормальных для гибких команд 30%. Это позволяет достичь кратного ускорения без увеличения ресурсов.

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

В статье описываются различные примеры, чтобы проиллюстрировать важность понимания цели работы. Основной пример — классическая притча о трех каменщиках, где первый видит свою работу в подгонке камней, второй — в зарабатывании денег для семьи, а третий — в строительстве храма. Другой вариант притчи рассказывает об уборщике на космодроме, который на самом деле участвует в запуске космических кораблей. Также упоминается пример компании Asana, которая формулирует свою миссию как помощь «человечеству процветать», и примеры миссий крупных компаний, таких как Google, Facebook и Amazon. Особым экспериментом стала работа Дэна Ариели, демонстрирующая, как восприятие смысла работы влияет на трудовую мотивацию участников.

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

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

Важно учитывать как warranty, так и utility при оценке качества ИТ-услуг, потому что они охватывают разные, но взаимодополняющие аспекты восприятия качества. Utility отвечает за соответствие услуги бизнес-потребностям и функциональным требованиям заказчика, а warranty гарантирует стабильность, доступность и безопасность предоставления услуги. Наличие только одного аспекта недостаточно: даже самая функциональная услуга (высокая utility) будет непригодна, если она ненадежна (низкая warranty), и наоборот – надежная, но ненужная услуга (высокая warranty, низкая utility) не будет удовлетворять потребности заказчика.

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

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

Индикаторы оценки в стандарте ISO/IEC 15504 — это наблюдаемые свидетельства, подтверждающие выполнение определенных управленческих практик в процессе. Они служат основой для объективной оценки уровня зрелости процесса и могут быть представлены как документированными рабочими продуктами (планами, отчетами, протоколами), так и словесными подтверждениями от менеджеров и участников процесса. В COBIT 5 PAM эти индикаторы применяются для проверки наличия и стабильности выполнения ключевых управленческих действий: определения целей процесса, распределения ответственности, обеспечения ресурсов, измерения результатов и планирования улучшений. Чем больше подтвержденных индикаторов найдено, тем выше уровень зрелости процесса считается достигнутым.