Ведёт конкретное дело от начала до результата: проект, сделку, закупку, набор группы. Его предмет — сроки, объём и качество того, что он ведёт.

В нашей программе это видно буквально: менеджер проекта заводит проект и пишет срезы — короткое резюме состояния со светофором. Срез это не отчёт для начальства, а способ вовремя сказать «здесь встало». Менеджер вправе сам решать, как именно делать работу, и обязан сообщать, когда она перестаёт укладываться в срок.

Людей в подчинении у менеджера может не быть вовсе. Это не понижение: он управляет делом, а не штатом.

У него в подчинении сотрудники, и его предмет — кто что делает, чем занят и на что способен: распределение работы, дежурства, допуски, обучение, замена на время отпуска.

Руководитель отвечает не за отдельный проект, а за то, чтобы работа вообще было кому делать и чтобы правила соблюдались одинаково. Когда двум менеджерам нужен один и тот же человек, спор решает руководитель, а не тот, кто громче просит.

Частая ошибка: сильного специалиста делают руководителем и продолжают спрашивать с него как со специалиста. Тогда он тянет свою прежнюю работу, а люди остаются без внимания — и проседает именно то, ради чего его назначили.

Решает, что компания делает и чего не делает: какие направления развиваем, куда идут деньги, какие обязательства берём на себя перед заказчиком. Отвечает за результат целиком, а не за отдельную работу.

В программе роль директора видна в визах на срезах: «ознакомлен» или «замечание» с текстом. Замечание закрывается следующим срезом менеджера. Смысл визы не в контроле ради контроля — это способ вмешаться до того, как проект встанет.

Директор не забирает работу у менеджера. Если директор начинает вести проект сам, значит менеджера в этом проекте фактически нет, и это нужно называть своим именем, а не считать нормой.

Менеджер ведёт и пишет срез → директор читает и ставит визу → замечание закрывается следующим срезом. Руководитель в эту цепочку не встроен: он обеспечивает, чтобы у менеджера были люди и время.

Отсюда простое правило спора: «успеем ли к сроку» — вопрос к менеджеру, «кем сделаем» — к руководителю, «делаем ли вообще» — к директору. Если вопрос задан не тому слою, ответ будет вежливым и бесполезным.

1. Поток ценности проекта (ITIL: value stream). Каждый проект проходит одни и те же шаги, и у каждого шага есть хозяин: Задача дня (кто угодно) → Проект (заводит менеджер: название, цель, площадки, срок) → Срез раз в неделю (менеджер: резюме + светофор) → Виза (директора: «ознакомлен» или «замечание») → Ответ на замечание в следующем срезе (менеджер) → Завершён или Архив (директор решает). Шаг нельзя перепрыгнуть: проект без цели не заводится, срез без резюме не пишется.

2. Роли — по предмету решения (ITIL: RACI). По каждому проекту: отвечает менеджер (R), утверждает директор (A), обеспечивает людьми руководитель (C), в курсе все причастные площадки через группу «Менеджер проектов» в чате (I). Один человек может быть в двух ролях, но не в трёх по одному проекту: менеджер не визирует свои срезы.

3. Сроки и лестница эскалации (ITIL: service level, escalation). Срез — раз в 7 дней. 8–14 дней без среза — проект помечается «пора делать срез», это забота менеджера. Больше 14 дней — «просрочка», проект поднимается директору, а руководитель проверяет, не перегружен ли человек. Срок проекта прошёл — в первом же срезе менеджер называет новую дату и причину; молча сдвигать срок нельзя. Замечание директора без ответа в следующем срезе — повод для разговора втроём.

4. Передача проекта (ITIL: change enablement — управляемое изменение, а не тихая правка поля). Только кнопкой «Передать» с причиной. Принимающий подтверждает или отказывается с причиной; до принятия отвечает прежний менеджер. Передаётся вместе с последним срезом, чтобы принимающий видел, что берёт. Все шаги уходят в чат. Директор может принять решение за принимающего, если тот недоступен.

5. Одно место правды (ITIL: knowledge management). Люди и должности — только в AI-Auth, проекты и срезы — только здесь, переписка — в едином чате. Ни один список не ведётся вторым экземпляром «для удобства»: он разойдётся с первым в первую же неделю.

6. Практики ITIL 4 → где они у нас живут. Инциденты и мониторинг — «Инфраструктура» (пульт, лестница «свет или канал»). Изменения — проекты и срезы здесь. Обращения и связь — единый чат и совещания в «Коммуникации». Знания и обучение — «Учебный центр» и «Правила». Отношения с заказчиками и поставщиками — «Продажи» и контрагенты в AI-Auth. Непрерывное улучшение — «Задачи дня» → «В проект»: любая мелочь, повторившаяся дважды, становится проектом.

7. Семь принципов ITIL 4 — как мы их читаем. Фокус на ценности: у проекта есть цель «что считается успехом», без неё не заводим. Начинай с того, что есть: сначала смотрим срезы и данные программ, потом придумываем новое. Двигайся итерациями: срез раз в неделю, а не отчёт раз в квартал. Работай прозрачно: каждый срез и каждая передача — в общий чат. Думай целостно: помощник AI видит все отделы, а не один. Просто и практично: одна кнопка «Передать», одна кнопка «Виза». Оптимизируй и автоматизируй: напоминания о срезах, подсветка просрочек и предупреждения о загрузке делает программа, а не человек с блокнотом.