1. Спринт ревью
1.1. Демо (команда + пользователи)
1.1.1. Демонстрация инкремента
1.1.2. Получение фидбека
1.2. Подведение итогов (команда + стейкхолдеры)
1.2.1. Обзор метрик
1.2.2. Обзор прод инцидентов
1.2.3. Анализ результатов продуктовых экспериментов
1.2.4. Ревью Roadmap продукта
2. Создание команды
2.1. 4 столпа
2.1.1. Цель
2.1.2. Ценности
2.1.3. Компетенции
2.1.4. Полномочия
2.2. Роли в команде (модель Белбина)
2.3. Жизненный цикл команды (модель Такмана)
2.3.1. Forming
2.3.2. Storming
2.3.3. Norming
2.3.4. Performing
3. Управленческий цикл
3.1. Модель Кеневин
3.1.1. Simple/Obvious
3.1.2. Complicated
3.1.3. Complex
3.1.4. Chaotic
3.2. Типы подходов
3.2.1. Продукт
3.2.2. Проект
3.2.3. Операционная деятельность
3.3. Петли обратной связи
3.3.1. Что хотите контролировать
3.3.2. Что покажет, что (не)произошло?
3.3.3. Как получите информацию?
3.3.4. Ваши действия
3.3.5. Как поддерживать механизм ОС долго
3.4. Модели
3.4.1. HADI
3.4.2. PDCA
4. Визуализация продукта и проекта
4.1. Доска задач (Scrum, Kanban)
4.2. Sprint burndown
4.3. Dashboards
4.4. Диаграмма Гантта
4.5. User story mapping
4.6. Customer journey map
5. Продажа идей
5.1. Когда говорить об идеях?
5.1.1. Изучаем контекст
5.1.1.1. Стадия (модель Такмана)
5.1.1.2. Среда (модель Кеневин)
5.1.1.3. Батарейка команды
5.1.2. В зависимости от контекста настраиваем:
5.1.2.1. Интенсивность продаж
5.1.2.2. Детализированность идей при продаже
5.1.2.3. Количество продаж
5.2. Об одном ли говорим?
5.2.1. Проверяем общее понимание
5.2.1.1. Цели
5.2.1.2. Общие термины
5.3. С кем и о чем говорить?
5.3.1. Кому выгодны изменения?
5.3.1.1. Чью боль исправляем
5.3.1.2. Кто ЦА
5.3.2. Кто принимает решение?
5.3.2.1. Выделение ЛПР и как изменение поможет им
5.3.2.2. Выделение ЛВР и как изменение поможет им
5.3.3. Ищем Стейкхолдеров, связанных с проектом
5.3.3.1. Учитываем затрагивает ли их изменение
5.3.3.2. При необходимости согласовываем / уведомляем
5.4. Как говорить?
5.4.1. DISC
5.4.2. PAEI
5.5. Внедрение идей
5.5.1. Формирование рабочих групп
5.5.2. Внедрение и поддержка
5.5.3. Получение обратной связи
5.6. Откуда брать идеи
5.6.1. Кейсы коллег
5.6.2. Обратные связи
5.6.3. Различные виды мозгового шторма
5.6.3.1. МОДЕЛЬ SCAMPER
5.6.3.2. ОБРАТНЫЙ МОЗГОВОЙ ШТУРМ
5.6.3.3. МЕТОД ФОКАЛЬНЫХ ОБЪЕКТОВ
6. Ретроспектива
6.1. Принципы
6.1.1. Без переходов на личности
6.1.2. Отделяйте факты от предположений и опасений
6.1.3. Опыт и мнение каждого участника важны
6.1.4. Конструктивное несогласие - это нормально
6.1.5. Blameless environment
6.1.6. Исключите авторитарность
6.2. Состав
6.2.1. Ice-break
6.2.2. Сбор данных
6.2.3. Генерация идей
6.2.4. Выбор решений
6.2.5. Закрытие
6.3. Форматы
6.3.1. Like/Wish/Wonder
6.3.2. Well done/Good fail/Bad fail
6.3.3. Кораблик
6.3.4. Stop/Start/More/Less/Keep
7. People management
7.1. Конструктивная конфронтация
7.1.1. Адресность
7.1.2. Своевременность
7.1.3. Данные и факты
7.1.4. Фокус на проблеме
7.2. Типология людей
7.2.1. DISC
7.2.2. PAEI (Адизес)
7.3. Встречи 1:1
7.3.1. Ice-break
7.3.2. Что ты хочешь обсудить?
7.3.3. Прошлые договоренности
7.3.4. Текущие вопросы
7.3.5. Договоренности на будущее
7.4. Принципы коммуникации "5П"
7.4.1. Полезность
7.4.2. Понятность
7.4.3. Презсказуемость
7.4.4. Прозрачность
7.4.5. Последовательность
8. Управление изменениями
8.1. Алгоритм
8.1.1. Текущее состояние
8.1.2. Желаемое сост ояние
8.1.3. План достижения
8.2. Снижение сопротивления
8.2.1. Информировать о том, зачем
8.2.2. Обсуждать план внедрения
8.2.3. Собирать обратную связь
8.2.4. Быть готовым изменить или откатить
8.3. Инкрементация
8.3.1. Горизонтальная
8.3.2. Вертикальная
8.4. PDCA цикл
8.4.1. Plan
8.4.2. Do
8.4.3. Check
8.4.4. Act
8.5. Чем выше неопределенность
8.5.1. Правила проще
8.5.2. Результаты чаще
8.5.3. Обратная связь чаще
8.5.4. Структура гибче
9. Декомпозиция и планирование
9.1. Acceptance criteria
9.1.1. Пишутся с точки зрения пользователя
9.1.2. Краткие, однозначно понимаемы
9.1.3. Уникальны для каждой конкретной задачи
9.2. Definition of done
9.2.1. Может включать в себя как технические аспекты, так и этапы выполнения работ
9.2.2. В идеале - пишутся в виде чеклиста
9.2.3. Формулируются в таком виде, что всегда можно ответить “да” или “нет” на вопрос выполнено ли
9.2.4. Распространяются на все задачи/класс задач
9.3. Инкрементальная декомпозиция
9.3.1. Быстрая доставка бизнес-ценности
9.3.2. Хорошо снижает неопределенность
9.3.3. Простота тестирования
9.3.4. Снижается риск регрессионных проблем
9.3.5. Код ревью делается для меньшего количества строк за раз
9.3.6. Разбиение задач сложнее, чем для компонентной
9.3.7. Требовательна к уровню команды
9.3.8. Требует частых релизов
9.3.9. Ниже точность планирования
9.4. Компонентная декомпозиция
9.4.1. Проще, чем инкрементальная
9.4.2. При грамотной проработке показывает хорошие результаты даже с джунами
9.4.3. Каждый занимается своим делом, люди не мешают друг другу
9.4.4. Чаще всего проблемы возникают при интеграции задач
9.4.5. Требует ОЧЕНЬ детальной проработки точек интеграции
9.4.6. Требует много менеджмента чтобы пазл сложился
9.4.7. Плохо снижает неопределенность
9.5. Чеклист декомпозиции
9.5.1. Понятно, что нужно сделать чтобы задача была выполнена
9.5.2. Есть понимание как контролировать прогресс задачи
9.5.3. Полученные задачи пригодны для передачи исполнителям
9.5.4. Есть понимание, как интегрировать подзадачи между собой
10. Метрики
10.1. Ключевые вопросы
10.1.1. Что вы хотите узнать?
10.1.2. Что будете делать?
10.1.3. С какими метриками связано?
10.1.4. Зачем это нужно команде?
10.1.5. Данные-то качественные?
10.2. Типы метрик
10.2.1. Продуктовые
10.2.1.1. AARRR
10.2.1.2. LTV
10.2.1.3. Retention
10.2.1.4. Churn rate
10.2.2. Проектные
10.2.2.1. EVA
10.2.2.2. Burndown
10.2.2.3. Buffer
10.2.3. Качества
10.2.3.1. Bugs per ticket rate
10.2.3.2. Delivery on time rate
10.2.3.3. Escaped defects
10.2.3.4. Issue types
10.2.4. Производительности команды
10.2.4.1. Throughput
10.2.4.2. Velocity
10.2.4.3. Lead time
10.2.5. Инфраструктурные
10.2.5.1. Latency
10.2.5.2. Disk free space
10.2.5.3. Certificate lifespan
10.2.5.4. Free RAM
10.3. Метрики CFD
10.3.1. Время
10.3.1.1. Lead time
10.3.1.2. Cycle time
10.3.1.3. Wasted time
10.3.2. Объем
10.3.2.1. WorkInProgress
10.3.2.2. RemainingToBeDone
10.3.3. Относительные
10.3.3.1. Effectiveness
11. SCRUM
11.1. Роли
11.1.1. Владелец продукта
11.1.2. Scrum-мастер
11.1.3. Команда
11.2. События
11.2.1. Спринт
11.2.2. Планирование спринта
11.2.2.1. Цель спринта
11.2.2.2. Оценка задач
11.2.3. Ежедневный Scrum
11.2.4. Обзор спринта
11.2.5. Ретроспектива спринта
11.3. Артефакты
11.3.1. Бэклог продукта
11.3.2. Бэклог спринта
11.3.3. Инкремент
12. Kanban
12.1. Роли
12.1.1. Менеджер Запросов для Сервиса
12.1.2. Менеджер Поставки для Сервиса
12.1.3. Команда
12.2. Практики
12.2.1. Визуализируйте
12.2.1.1. Доска Kanban
12.2.2. Ограничивайте незавершённую работу
12.2.3. Управляйте потоком работы
12.2.3.1. Классы работы
12.2.4. Используйте явные правила
12.2.5. Используйте петли обратной связи
12.2.6. Улучшайтесь и эволюционируйте