Основные рекомендации для повышения эффективности деловой переписки по email включают: писать краткие письма, умещающиеся в одну экранную форму, с изложением сути проблемы в 2-3 абзацах; формулировать мысли максимально ясно и просто, избегая специфических терминов и витиеватых конструкций; избегать эмоционально окрашенного текста, который может повысить конфликтность; использовать структуру приветствие-благодарность-основание-суть-запрос-подпись; указывать в теме письма ключевые слова и ожидаемое действие; не злоупотреблять статусом «Срочно», чтобы сохранить его значимость; и при необходимости повторно отправлять письма с пометкой «ПОВТОРНО», если ответ не пришел в ожидаемые сроки.

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

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

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

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

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

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

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

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

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