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

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

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

Задачи процесса управления доступностью пересекаются со следующими процессами: создание плана доступности может быть частью стратегического плана инфраструктуры (SIP) или пересекаться с управлением мощностями; диагностика и решение инцидентов и проблем относится к их специализированным процессам; оценка влияния изменений на доступность является задачей управления изменениями; отслеживание уровня доступности и анализ отклонений входят в зону ответственности SLM. Это вызывает вопрос о уникальности задач управления доступностью как отдельного процесса.

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

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

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

К вопросам, задаваемым пользователю для оценки влияния инцидента, предъявляются следующие основные требования: 1) Пользователь должен быть в состоянии дать на них ответ, используя имеющуюся у него информацию. 2) Трактовка ответов должна быть максимально однозначной, чтобы разные сотрудники поддержки приходили к одинаковой оценке влияния. 3) Количество вопросов должно быть ограничено (обычно 2-4), чтобы процесс оценки оставался быстрым и не создавал нагрузку на пользователя. 4) Вопросы должны покрывать ключевые аспекты, определяющие уровень влияния (масштаб проблемы и степень недоступности). 5) Формулировки вопросов должны быть понятны неподготовленному пользователю без технических знаний.

Практика 'Поддержка изменений' (Change enablement) в ITIL4 - это подход к управлению изменениями, ориентированный на быструю и безопасную доставку изменений в эксплуатацию при минимизации рисков. Она фокусируется на обеспечении того, чтобы изменения внедрялись эффективно и безопасно, при этом сохраняя необходимый уровень контроля. В рамках этой практики определен набор процессов, каждый из которых требует управления, а за практику в целом отвечает менеджер изменений как специфическая роль. Цель практики - поддержка бизнеса в адаптации к изменениям среды при сохранении стабильности сервисов.

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