С помощью CLD можно косвенно оценить факторы, которые сложно измерить напрямую, анализируя их причинно-следственные связи с другими элементами системы. Например, прямое измерение Cost per change / release может быть сложным, так как требует точного учета всех ресурсов. Однако CLD показывает, что эффективность использования ресурсов связана с уровнем стандартизации и автоматизации изменений, а также с успешностью первоначальной реализации (First-Time Implementation Rate). Измеряя эти косвенные показатели, можно оценить эффективность использования ресурсов, даже не измеряя напрямую стоимость изменений.

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

Работая на стороне заказчика в клиентской компании, автор имел рабочую загрузку в пределах 70-80%. В этом режиме времени обычно хватало не только на выполнение всех поставленных задач, но и на изучение новых технологий, управленческих методик и других интересных направлений. Хотя иногда случались авралы и завалы, в среднем за период рабочего времени баланс был приемлемым. В консалтинге же уровень загрузки значительно вырос — до 120-130%, а в пиковые периоды достигал 160%. Это привело к острой нехватке времени и поставило вопрос 'как это всё вообще можно успеть', требуя поиска специальных подходов к управлению временем и повышению личной эффективности.

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

В истории менеджмента известно множество ключевых фигур и их концепций: Адам Смит ввел идею специализации труда; Генри Форд внедрил конвейерное производство; Уолтер Шухарт и Эдвард Деминг разработали основы управления качеством на основе измерения и совершенствования процессов; Норберт Винер создал кибернетику, которая повлияла на управление системами; Дэвид Нортон и Роберт Каплан предложили концепцию сбалансированной системы показателей; ITIL стал стандартом в управлении ИТ-услугами. Эти концепции и их авторы хорошо документированы и признаны в профессиональном сообществе.

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

В Google у одного менеджера может быть до 30 прямых подчинённых, что значительно больше общепринятой нормы «максимум семеро на одного босса». Такая практика стала возможной благодаря тому, что руководители компании избегают микроменеджмента и делегируют ответственность. Google выяснил, что при наличии хорошего руководителя, который обладает ключевыми качествами, указанными в Project Oxygen, такое количество подчинённых позволяет сохранять высокую эффективность работы команды и минимизировать управленческую бюрократию.

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

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

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