Операционные затраты (OPEX) составляют 67-68% от общего объема затрат на ИТ в среднем по компаниям. В банках этот показатель выше — 76-79% (по данным за 2015 год), тогда как международная банковская статистика (Computer Economics) приводит цифру около 73%. Российские компании обычно демонстрируют более низкий уровень операционных затрат — 55-60%, но кризисные условия способствуют их росту за счет сокращения инвестиционных программ.

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

Бэклог команды в иерархии Atlassian состоит из понятных команде конечных элементов, которые могут быть обработаны за один или несколько условных "тактов" (не более некоторого N). Такими элементами являются пользовательские истории и задачи/подзадачи. Эпики, инициативы и темы не входят в бэклог команды, так как они либо слишком велики для непосредственной обработки (эпики), либо служат управленческими группировками (темы), либо относятся к инвестиционному планированию (инициативы).

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

Нисходящая ветка V-модели представляет процесс декомпозиции бизнес-требований на технические спецификации — от определения бизнес-процессов в желаемых условиях ('to-be') к проектированию конкретных компонентов инфраструктуры. Восходящая ветка модели демонстрирует обратный процесс интеграции и проверки, где происходит тестирование технических компонентов и постепенное подтверждение соответствия системы исходным бизнес-требованиям. Каждый уровень нисходящей ветки имеет соответствующий уровень проверки на восходящей ветке, что обеспечивает полное покрытие требований проверками на всех уровнях

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

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

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

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

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