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

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

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

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

Важность способности объяснять сложные технические аспекты простым языком обусловлена необходимостью эффективной коммуникации между IT и бизнесом. Опытные разработчики (миддл и сеньор) должны уметь излагать смысл своей деятельности, трудности, с которыми они сталкиваются, и обосновывать выбор решений, потому что: 1) это помогает бизнесу понимать ценность и стоимость технических решений; 2) предотвращает накопление технического долга из-за непонимания логической структуры системы; 3) современное программирование становится более верхнеуровневым и близким к человекопонятному языку, поэтому это должно быть проще. В тексте прямо указано, что это «the must», особенно учитывая, что части технического долга возникают из-за несостыковок в логической продуманности системы.

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

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

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

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

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