Начать. Это бесплатно
или регистрация c помощью Вашего email-адреса
SM School создатель Mind Map: SM School

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. Улучшайтесь и эволюционируйте