Планирование

Время освоения: ~40 минут Цель: Научиться управлять проектами с позиции тимлида — планировать, оценивать, управлять рисками, работать со стейкхолдерами и извлекать уроки из опыта

Управление проектами для тимлида — это не waterfall с диаграммами Ганта и не просто "запустить спринт". Большинство реальных проектов живут в промежуточной зоне: есть дедлайн от бизнеса, есть неопределённость требований, есть команда с ограниченным capacity, есть стейкхолдеры с разными ожиданиями.

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

Главный сдвиг мышления: от "мы сделаем всё, что просят" к "мы сделаем правильные вещи в нужное время и сообщим о компромиссах заранее". Это требует навыка работы с неопределённостью, умения говорить неудобное и системного мышления о рисках.

WBS — это иерархическая декомпозиция работ от цели проекта до конкретных задач. Главный принцип: каждый элемент WBS — это deliverable (результат), а не процесс.

Плохо: "Разработка бэкенда" (процесс) Хорошо: "API авторизации с JWT, покрытое тестами" (результат)

Правило 100%: WBS должна охватывать 100% работы проекта — ничего не должно быть "подразумевается само собой".

Как строить WBS:

Milestone — ключевое событие в проекте (не работа, а контрольная точка): "Завершён дизайн API", "Прошло UAT-тестирование", "Готово к production".

Critical Path — последовательность задач, задержка в которых задерживает весь проект. Задачи вне критического пути имеют "float" — запас времени.

Практическое применение: При давлении на сроки смотрите на критический путь. Добавление ресурсов к задачам вне критического пути не ускорит проект.

Избыточное планирование (планирование на 2 месяца вперёд с детализацией до часов) — потеря времени в условиях неопределённости. Недостаточное (нет плана вообще) — хаос и сюрпризы.

Правило горизонта: Детализируйте на 2 спринта вперёд. Остальное — крупными блоками. По мере приближения — детализируйте.

Planning Poker: Команда одновременно показывает карточки с оценкой. Обсуждение расхождений выявляет разные предположения. Подходит для story points на Sprint Planning.

Three-Point Estimation (PERT):

Полезна для ключевых задач проекта, где важна точность.

T-shirt sizing: Быстрая грубая оценка (XS/S/M/L/XL) для первичного понимания масштаба. Не для коммитмента — для принятия решений о scope.

Проблема padding: Если каждый разработчик добавляет 50% буфер к своей оценке, а менеджер добавляет ещё 30% — проект никогда не доставляется быстро, и команда теряет навык реальной оценки.

Лучший подход: Собирайте честные оценки (без padding) и добавляйте явный буфер на уровне проекта (20–30%). Делайте это прозрачно для команды.

Закон Брукса: Добавление людей к опоздавшему проекту делает его ещё более опоздавшим. Причины: время на онбординг, рост коммуникационных каналов (N² сложность), фрагментация задач.

Не давайте точечную оценку ("будет готово 15 марта"). Давайте диапазон с вероятностью:

Это честнее и учит стейкхолдеров думать о вероятностях, а не об одной дате как обещании.

Управление рисками — не одноразовое упражнение в начале проекта. Это непрерывный процесс.

Четыре шага:

Стратегии реакции на риск:

Risk Register — живой документ со списком рисков:

Обновляйте Risk Register на еженедельной встрече команды. 5 минут в начале — достаточно.

RACI определяет роли в принятии решений и выполнении работы:

Создайте RACI в начале проекта для ключевых deliverable'ов. Это предотвращает "это не моя ответственность" и конфликты о принятии решений.

Хороший статус-репорт отвечает на три вопроса за 2 минуты чтения:

Формат светофора: RAG-статус (Red/Amber/Green) по трём измерениям: scope, time, budget. Не скрывайте Amber и Red — чем раньше стейкхолдер знает о проблеме, тем больше вариантов решения.

Тимлиды часто эскалируют поздно — боятся "выглядеть слабыми" или признавать проблему. Правило: эскалируй, когда стало ясно, что проблема не решится без внешней помощи — не когда дедлайн завтра.

Структура эскалации: "У нас риск X. Вероятность — Y%. Последствия — Z. Мы пробовали A и B. Нам нужно решение C или решение о scope."

Цель постмортема — понять системные причины проблемы, а не найти виноватого. Если постмортем заканчивается "Вася сделал ошибку" — это провал процесса.

Принцип: Люди принимали решения, обладая той информацией, которая была у них на тот момент. Вопрос не "кто виноват?", а "почему система позволила этой ошибке произойти?"

Структура blameless postmortem:

Постмортем — реакция на инцидент. Lessons Learned — регулярная практика извлечения опыта.

После каждого крупного проекта (30–60 минут):

Храните Lessons Learned в доступном месте (Confluence, Notion). Они бесценны для новых проектов — и почти никто их не читает. Ваша задача как тимлида — внедрять их в следующие проекты, а не только записывать.

Возьмите текущий или ближайший проект:

Выберите проект, который завершился с проблемами:

Правило: если кто-то называет имя человека как причину — мягко переформулируйте: "Какой процесс или инструмент позволил этой ситуации возникнуть?"