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

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

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

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

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

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

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

Деловая игра 'The Challenge of Egypt' является обучающим инструментом, направленным на развитие навыков проектного управления. Она проводится для учащихся в возрасте от 11 до 15 лет, отобранных в рамках летней научно-образовательной программы 'Лифт в будущее'. Участники игры осваивают роль менеджера проекта и смежные позиции, связанные с управлением ресурсами, распределением задач и взаимодействием внутри команды. Игра моделирует процесс строительства пирамиды и сфинкса, требуя от игроков организации строительных операций, логистики и управления людскими ресурсами.

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

Анализ текущего состояния потока создания ценности в ИТ-команде можно провести с помощью картирования потока (Value Stream Mapping, VSM). Это включает создание визуальной карты всех этапов обработки задач, объединение их с информационными потоками и связанными метриками. Анализ должен ответить на вопросы: кто является источником запросов и как они приоритизируются; достаточно ли информации для фокусировки на ценности; как организована передача задач между этапами; где есть завихрения и возвратные движения элементов; все ли этапы и очереди визуализированы; как организована приёмка и подтверждение поставленной ценности.