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

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

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

В контексте управления уровнем ИТ-услуг процесс SLM (Service Level Management) соответствует циклу PDCA (Plan-Do-Check-Act). Этот процесс ответственен за реализацию цикла PDCA над оперативной деятельностью в рамках жизненного цикла услуг, направленного на постепенное устранение несоответствий между ожиданиями заказчика услуг и реальными показателями предоставляемых услуг. Таким образом, SLM обеспечивает постоянное улучшение качества ИТ-услуг через планомерное выявление и устранение недостатков.

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

Если консультанты при составлении RACI-матрицы не предусмотрели механизмы контроля для ответственных (A), необходимо: 1. До окончательного утверждения матрицы определить, какие конкретно инструменты контроля нужны для каждой позиции с символом A. 2. Требовать от консультантов или внутренней команды разработать и внедрить эти механизмы контроля. 3. В случае если консультанты отказываются это делать, настаивать на внесении в матрицу примечаний о необходимых механизмах контроля с указанием ответственных за их создание. 4. При отсутствии возможности привлечь консультантов - самостоятельно разработать простые, но эффективные механизмы отслеживания выполнения задач (регулярные отчеты, контрольные точки, проверочные встречи). Механизмы контроля являются неотъемлемой частью ответственности, и без них система распределения ролей теряет смысл, так как ответственный не сможет влиять на результат, за который несет ответственность.

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

Интерес к теме канбана среди участников конференции проявился уже в первой половине дня, когда несколько человек упомянули, что мастер-класс проводится без регистрации и вход свободный. К началу мероприятия более половины мест для активных участников было занято, а также собралась группа из 20-25 наблюдателей, что в сумме составило около 50-55 человек. Некоторые участники даже спрашивали, можно ли присоединиться к мастер-классу в роли наблюдателей. Живой интерес проявлялся также в активной работе групп, задаваемых вопросах и в том, как участники кивали в знак согласия с важными идеями, обсуждаемыми в ходе занятия.

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

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