Школа Управленческого Мастерства (ШУМ) - 4. Тренинг по контролю выполнения работ. Посвящен типичным ошибкам управления при внедрении гибких (адаптивных, Agile) методологий. Разбираются активности и роли на примере методологии Scrum. Ведущий: Вадим Нарейко Страница: https://www.facebook.com/ManagementMasters

1. КАК КОНТРОЛИРОВАТЬ
РАБОТУ?
ШКОЛА УПРАВЛЕНЧЕСКОГО МАСТЕРСТВА
ВАДИМ НАРЕЙКО

2. Скорректировать умение контролировать, показав
стандартные ошибки на примере
методологии Scrum
Цель тренинга

3. ПОЧЕМУ СЕГОДНЯ ФОКУСИРУЕМСЯ НА
ОШИБКАХ?
• «Проанализировав результаты, исследователи обнаружили: в группе, которая училась на
ошибках, качество знаний было выше, чем в той, которая училась на правильных решениях.»
«Психология Убеждения. 50 доказанных способов быть убедительным» Р. Чалдини, Н.Гольдштейн,
С.Мартин

4. ПРАВИЛА
• Работают все
• Глупых вопросов не бывает
• Отключаем звук и вибрацию в телефонах
• Говорим от своего имени
• Не играем в «партизана»
• Общаемся с максимальным количеством участников

5. ИЗМЕНЕНИЯ
• Используем Task Board и Burndown Chart для планирования и
контроля за тренингом
• Запланировано много информации

6. ЕСТЬ ЛИ ВОПРОСЫ?

7. ПРОВЕРЯЕМ ГЛОБАЛЬНЫЕ ОЖИДАНИЯ
• Понять, как создавать команду
• Развить навыки общения в команде
• Познакомиться с новыми людьми
• Научиться мотивировать других
• Совершенствование внутреннего опыта
• Расшевелить структуру своей компании
• Оценить свои знания
• Поделиться знаниями
• Понять, какие навыки нужны
• Грамотное делегирование полномочий
• Научиться работать в команде
• Понять мотивации в работе команды
• Научиться общаться со специалистами
• Понять, как работают процессы
• Структурировать и получить знания
• Понять, как использовать опыт ИТ в других сферах
• Поменять специальность
• Понять, нравится ли управлять
• Хороший – Жесткий руководитель
• Научиться ошибаться и учиться на этом
• Применить знания на практике
• Встряхнуться и удовлетворить любопытство
• Грамотное проведение переговоров
• Научиться управлять людьми

8. НАШИ ОЖИДАНИЯ
• Научиться контролировать себя и других
• Использовать опыт из IT из другой сферы
• Что такое оптимальный контроль?
• Как найти баланс в контроле?
• Освоить новые методики и практики
• Узнать, что такое Scrum/Agile
• Как правильно контролировать?
• Научиться работать в команде
• Найти «подводные камни» в Scrum
• Побороть застенчивость
• Познакомиться с новыми людьми
• Прорекламировать свой проект
• Понять, что такое ШУМ
• Развеяться от офисных будней
• Обучаться управлению
• Возобновить знания
• Понять, как правильно проводить совещания
• Какие методы ведут к негативу от управления
• Узнать новые методы контроля
• Увеличить эффективность работы сотрудничества
• Проверить, правильно ли я знаю Agile
• Говорить с разработчиками на одном языке

9. НАШИ ОЖИДАНИЯ-2
• Узнать какие ошибки совершаются при
внедрении скрам
• Узнать какие ошибки совершаются в процессе
работы
• Проанализировать свои собственне ошибки
• Понять как сделать правильный процесс в своём
проекте
• Разобраться в планировании и оценке
• Понаблюдать за происходящим
• Разобраться как мотивировать людей получить
результат
• Пообщаться с интересными людьми
• Как организовать максимально комфортную
атмосферу в команде
• Изучить методику проведения тренинга как
такового
• Узнать для себя продолжать ли посещение
данного мероприятия
• Опыт управления людьми
• Практики построения отдела
• Применение адаптивных технологий
• Узнать, что такое управление
• Узнать о конкретных инструментах управления

10. РАЗБИВАЕМСЯ НА ГРУППЫ
• 7-9 человек
• Выбираем модератора (в идеале – участник,
который подготовился и распечатал план
обсуждения, взял компьютер или планшет
для опубликования результатов обсуждения)
• Обсудить проблемы, возникающие в
процессе контроля и выработать 5 пунктов,
отвечающих «Зачем нужно контролировать
выполнение работы?»

11. ПРОВОДИМ СОВЕЩАНИЕ ПО ПЛАНУ НА 1.5
ЧАСА

12. ПОЧЕМУ НА ПРИМЕРЕ SCRUM?
• «Простая» методика для внедрения
• «Модная» тенденция управления
• Много литературы и мало «правильного» опыта

13. AGILE-МАНИФЕСТ РАЗРАБОТКИ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
(HTTP://AGILEMANIFESTO.ORG/ISO/RU/)
Мы постоянно открываем для себя более совершенные методы разработки программного
обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря
проделанной работе мы смогли осознать, что:
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева

14. 12 ПРИНЦИПОВ AGILE-МАНИФЕСТА
HTTP://AGILEMANIFESTO.ORG/ISO/RU/PRINCIPLE
S.HTML
1. Наивысшим приоритетом для нас является удовлетворение
потребностей заказчика, благодаря регулярной и ранней
поставке ценного программного обеспечения.
2. Изменение требований приветствуется, даже на поздних
стадиях разработки. Agile-процессы позволяют использовать
изменения для обеспечения заказчику конкурентного
преимущества.
3. Работающий продукт следует выпускать как можно чаще, с
периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители
бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные
профессионалы. Чтобы работа была сделана, создайте
условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и
эффективным способом обмена информацией как с самой
командой, так и внутри команды.
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь
возможность поддерживать постоянный ритм бесконечно.
Agile помогает наладить такой устойчивый процесс
разработки.
9. Постоянное внимание к техническому совершенству и
качеству проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы — крайне
необходима.
11. Самые лучшие требования, архитектурные и технические
решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные
способы улучшения эффективности и соответственно
корректировать стиль своей работы.

15. РИСУЕМ SCRUM

16. РОЛИ В SCRUM
КТО ТУТ КТО?

17. КАКИЕ ЕСТЬ СТАНДАРТНЫЕ РОЛИ?

18. PRODUCT OWNER
КТО ОТВЕЧАЕТ ЗА ПРОДУКТ?

19. ЗА ЧТО ОТВЕЧАЕТ ВЛАДЕЛЕЦ ПРОДУКТА?
(PRODUCT OWNER)
HTTP://WWW.ROMANPICHLER.COM/
1. Отвечает за product vision
2. Понимает бизнес-модель продукта, включая
предлагаемые ценности и желаемые бизнес-
преимущества
3. Составляет и отвечает за план выпуска
(roadmap) продукта
4. Тесно сотрудничает с командой и Scrum-
мастером
5. Ведет бэклог продукта
6. Определяет приоритеты и цели каждой
итерации
7. Выбирает подходящие методы для
тестирования и демонстрации версий
(increments) заинтересованным лицам
8. Анализирует идеи, данные и обратную связь
и изменяет бэклог продукта
9. Контролирует бюджет и ход проекта
10. Координирует активности по запуску
продукта на рынок

20. PRODUCT OWNER В КАРТИНКЕ
HTTP://WWW.ROMANPICHLER.COM/BLOG/ROLES/
ONE-PAGE-PRODUCT-OWNER/

21. СТАНДАРТНЫЕ «ПРОБЛЕМЫ» PRODUCT
OWNER
• Не хватает полномочий
• Слишком занят
• Частичная занятость
• Удаленный
• «Прокси»
• Комитет
«Agile Product Management with Scrum. Creating Products that Customers Love» - Roman Pichler

22. 10 ТИПИЧНЫХ ОШИБОК ВЛАДЕЛЬЦА
ПРОДУКТА
BACHAN ANAND
HTTP://AGILE.CONSCIRES.COM/2012/10/08/TOP-10-FAILURE-MODES-OF-A-PRODUCT-OWNER/

23. 1. БОЛЬШЕ ФОКУСИРУЕТСЯ НА ЛЮДЯХ,
ЧЕМ НА ПРОДУКТЕ

24. 2. НЕ МОЖЕТ УПРАВЛЯТЬ ОЖИДАНИЯМИ
ЗАИНТЕРЕСОВАННЫХ ЛИЦ

25. 3. НЕ РАССКАЗЫВАЕТ «PRODUCT VISION»
КОМАНДЕ

26. 4. НЕ ПОКАЗЫВАЕТ РЕАЛЬНЫЙ СТАТУС
ЗАИНТЕРЕСОВАННЫМ ЛИЦАМ

27. 5. УДАЛЕН ОТ КОМАНДЫ И РАБОЧЕГО
ПРОЦЕССА

28. 6. НЕ СОБЛЮДАЕТ БАЛАНС
ВОВЛЕЧЕННОСТИ В ПРОЕКТ

29. 7. НЕ ДОСТУПЕН НА ДЛИТЕЛЬНЫЙ ПЕРИОД

30. 8. НЕ ПОНИМАЕТ СВОЮ РОЛЬ,
ПРОЦЕССОВ И НУЖД КЛИЕНТОВ

31. 9. НЕ ИМЕЕТ ПОЛНОМОЧИЙ

32. 10. ОШИБАЕТСЯ ПРИ ПРИОРИТЕЗАЦИИ
ИЛИ УТОЧНЕНИИ НУЖД КЛИЕНТОВ

33. ДЗ 4.1
• Отсортировать проблемы в порядке важности (самое важное – наверху)
• Написать, с которой из проблем сталкивались в последнее время и как ее решили
Срок – 72 часа

34. SCRUM MASTER
КТО ОТВЕЧАЕТ ЗА ПРОЦЕСС?

35. SCRUM MASTER
1. Помогает вести процесс (мониторит и контролирует)
2. Следит за мотивацией команды
3. «Продает» процесс команде и заинтересованным лицам (Наставник и Коуч)
4. Обеспечивает прозрачную коммуникацию
5. Следит за качеством процессов и инициирует изменения
6. Решает проблемы и разрешает конфликты (Защищает команду от внешних трудностей и
воздействий)

36. 10 ТИПИЧНЫХ ОШИБОК СКРАМ
МАСТЕРА

37. 1. SCRUM MASTER ОТВЕТСТВЕНЕН ЗА
ПОСТАВКУ

38. 2. SCRUM MASTER - МЕНЕДЖЕР

39. 3. SCRUM MASTER ПРИНИМАЕТ РЕШЕНИЕ
ЗА КОМАНДУ

40. 4. SCRUM MASTER РАЗДАЕТ ЗАДАЧИ

41. 5. SCRUM MASTER НЕ ДАЕТ ОБЩАТЬСЯ С
PRODUCT OWNER

42. 6. SCRUM MASTER НЕ ПОНИМАЕТ
ПРОЦЕССОВ

43. 7. СОВМЕЩЕНИЕ РОЛИ С PRODUCT
OWNER

44. 8. CУПЕРГЕРОЙ – ВСЕ ДОЛЖНО ДЕЛАТЬСЯ
С SCRUM MASTER

45. 9. ЗАНЯТЫЙ SCRUM MASTER

46. 10. SCRUM MASTER НЕ ИМЕЕТ
АВТОРИТЕТА

47. ДЗ 4.2
• Отсортировать проблемы в порядке важности (самое важное – наверху)
• Написать, с которой из проблем сталкивались в последнее время и как ее решили
Срок – 96 часов

48. SCRUM TEAM
ЗА ЧТО ОТВЕЧАЕТ КОМАНДА?

49. ОТВЕТСТВЕННОСТЬ SCRUM TEAM
1. Ответственна за процесс
2. Владеет планом итерации
3. Принимает обязательства достичь цели
итерации
4. Ежедневно синхронизирует работу и
активности
5. Самоорганизуется для улучшения процесса и
решения задач
6. Оценивает задачи (пользовательские
истории)
7. Информирует Scrum Master о возможных и
возникших трудностях
8. Общается с Product Owner для уточнения
задач
9. Демонстрирует результат заинтересованным
лицам

50. УМЕЕМ ЛИ МЫ ПЛАНИРОВАТЬ?

51. ЖЕСТКОЕ ПЛАНИРОВАНИЕ
• Предполагает, что люди работают, как компьютеры
• Предполагает, что все известно в самом начале
• Команда известна в самом начале и ее эффективность также спланирована
• Не позволяет вносить оперативные изменения
• Не учитывает наличия промежуточной рыночной ценности

52. КОГДА МОЖЕТ РАБОТАТЬ ЖЕСТКОЕ
ПЛАНИРОВАНИЕ?

53. СКОЛЬКО ПРОЕКТОВ – УСПЕШНЫ?

54. УМЕЕМ ЛИ МЫ ПЛАНИРОВАТЬ?

55. ЗАЧЕМ ПЛАНИРОВАТЬ И ОЦЕНИВАТЬ?
• Уменьшить риски
• Повысить уверенность
• Улучшить базу для принятия решений
• Установить доверие
• Обменяться информацией

56. ДЕМОНСТРАЦИЯ – СКОЛЬКО БУДЕТ
СТОИТЬ ДОМ?
• Я, как глава семейства, хочу построить дом

57. ТРЕНИНГ ПО ОЦЕНКЕ
• Команда просматривает список и быстро определяет, какая из задач самая маленькая
• После этого данной задаче назначается вес 1
• Потом все задачи оцениваются по порядку, исходя из того, сколько самых маленьких задач в
очередной задаче
• Оценка идет быстро – все выбирают карточки с оценкой, одновременно вскрывают карты
• Те участники, которые оценили минимально или максимально, говорят остальным, почему они
так оценили
• После этого оценка повторяется, пока не сойдется на одной оценке
• Команда может договориться, как поступать, если оценка долго не сходится

58. ПОКЕР ПЛАНИРОВАНИЯ
• Бык
• Дракон
• Змея
• Кот
• Крыса
• Лошадь
• Обезьяна
• Овца
• Петух
• Свинья
• Собака
• Тигр

59. 6 ТИПИЧНЫХ ОШИБОК AGILE-
ПЛАНИРОВАНИЯ
КОГДА ОЦЕНКИ НЕ РАБОТАЮТ?

60. 1. НЕ ОБЩАЮТСЯ С PRODUCT OWNER

61. 2. НАЗНАЧАЮТСЯ ЗАДАЧИ НА
КОНКРЕТНЫХ ЛЮДЕЙ

62. 3. PRODUCT OWNER НЕ ДОСТУПЕН

63. 4. ТРАТЯТ МНОГО ВРЕМЕНИ НА
ИЗЛИШНЮЮ ТОЧНОСТЬ

64. 5. ОЦЕНИВАЕТ ЛИДЕР

65. 6. ИСПОЛЬЗУЕТСЯ ВРЕМЯ ВМЕСТЕ
УСЛОВНЫХ ОЦЕНОК

66. ДЗ 4.3
• Отсортировать проблемы в порядке важности (самое важное – наверху)
• Написать, с которой из проблем сталкивались в последнее время и как ее решили
Срок – 120 часов

67. DAILY STANDUP
ЗАЧЕМ ВСТРЕЧАТЬСЯ ЕЖЕДНЕВНО?

68. DAILY STANDUP
• 15 минут синхронизации
• То же время
• То же место
• Организовано командой и для команды
3 вопроса:
1. Что делал вчера?
2. Чем займусь сегодня?
3. Какие есть помехи для выполнения работы?

69. КАКИЕ ЕСТЬ НЕГАТИВНЫЕ ОТЗЫВЫ О
DAILY STANDUP?

70. 10 ТИПИЧНЫХ ПРОБЛЕМ DAILY
STANDUP
ПОЧЕМУ ТАК СКУЧНО ЭТИ 15 МИНУТ?

71. 1. ПРОВОДИТСЯ СИДЯ

72. 2. ПРОВОДИТСЯ ДОЛЬШЕ 15 МИНУТ

73. 3. УЧАСТНИКИ ОПАЗДЫВАЮТ

74. 4. ПОСТОРОННИЕ ПОМЕХИ

75. 5. РЕШАЮТСЯ ПРОБЛЕМЫ

76. 6. ТОЛЬКО ДЛЯ SCRUM MASTER

77. 7. SCRUM MASTER РАЗДАЕТ РАБОТУ

78. 8. МНОГО ЗАДАЧ ОДНОВРЕМЕННО

79. 9. НЕ ОБНОВЛЯЕТСЯ СТАТУС (БЭКЛОГ И
ДИАГРАММА СГОРАНИЯ)

80. 10. ПОСТОРОННИЕ ЛЮДИ И
ОТСУТСТВУЮЩИЕ УЧАСТНИКИ

81. ДЗ 4.4
• Отсортировать проблемы в порядке важности (самое важное – наверху)
• Написать, с которой из проблем сталкивались в последнее время и как ее решили
Срок – 144 часа

82. ДЕМОНСТРАЦИЯ
ЗАЧЕМ ПОКАЗЫВАТЬ РЕЗУЛЬТАТ?

83. ДЕМОНСТРАЦИЯ (СМОТР РЕЗУЛЬТАТОВ)
• Команда показывается готовый результат заинтересованным лицам
• Демонстрируется только 100% готовое
• Каждый показывает только то, что сделал сам
• Владелец продукта или принимает функционал или возвращает назад в план (бэклог)
• Команда получает обратную связь от заинтересованных лиц

84. 7 ПРОБЛЕМ ДЕМОНСТРАЦИИ
КОГДА РЕЗУЛЬТАТ НЕ ДОСТИГАЕТСЯ?

85. 1. ДЕМОНСТРАЦИЮ ПРОВОДИТ
ВЫДЕЛЕННЫЙ ЧЕЛОВЕК

86. 2. ПОКАЗЫВАЕТСЯ НЕ ДО КОНЦА
ВЫПОЛНЕННАЯ РАБОТА

87. 3. НЕТ ВЛАДЕЛЬЦА ПРОДУКТА И
ЗАИНТЕРЕСОВАННЫХ ЛИЦ

88. 4. ОТЧЕТНОЕ СОБРАНИЕ ПО
ПОТРАЧЕННОМУ ВРЕМЕНИ

89. 5. НЕ ПОДГОТОВЛЕНО ЗАРАНЕЕ

90. 6. МНОГО ТЕХНИЧЕСКИХ ДЕТАЛЕЙ

91. 7. ОТСУТСТВУЕТ ОБРАТНАЯ СВЯЗЬ

92. ДЗ 4.5
• Отсортировать проблемы в порядке важности (самое важное – наверху)
• Написать, с которой из проблем сталкивались в последнее время и как ее решили
Срок – 168 часа

93. РЕТРОСПЕКТИВА
КАК УЛУЧШИТЬ РАБОТУ?

94. ФАБРИКА ШАРОВ
• Разбиваемся на 2 команды
• Передать как можно больше шаров
• Каждый член команды должен коснуться шара
• Шары должны летать (нельзя передавать из рук в руки)
• Никаких шаров соседу (слева или справа)
• Итерации по 2 минуты
• Обсуждаете процесс, пока занимается вторая команда

95. РЕТРОСПЕКТИВА
Коллективное рассказываение историй в конце итераций или проекта для пересмотра событий с целью
научиться на полученном опыте
1. Открытие (5%)
2. Сбор данных (30-50%)
3. Проникновение в суть (20-30%)
4. Решаем что делать (15-20%)
5. Закрытие (10%)
Agile Retrospectives: Making Good Teams Great
Esther Derby, Diana Larsen

96. ”
“Вне зависимости от того, что мы сегодня выясним
мы понимаем и верим, что все действовали по мере
своих сил и возможностей,
принимая во внимание доступную на тот момент
информацию, умения, навыки и наличие ресурсов в
данной ситуации.
«Project Retrospectives: A Handbook for Team Reviews» - Norman L. Kerth
Основная директива

97. 10 ТИПИЧНЫХ ПРОБЛЕМ
РЕТРОСПЕКТИВЫ
ПОЧЕМУ МЫ НЕ УЛУЧШАЕМ МИР ВОКРУГ?

98. 1. РЕТРОСПЕКТИВА НЕ ПРОВОДИТСЯ

99. 2. НЕРЕГУЛЯРНАЯ РЕТРОСПЕКТИВА

100. 3. НЕ ПРИНИМАЕТСЯ ОСНОВНАЯ
ДИРЕКТИВА

101. 4. ЖАЛОБЫ И НЕДОВОЛЬСТВО

102. 5. ПОПЫТКИ РЕШИТЬ И ОБСУДИТЬ СРАЗУ
ВСЕ

103. 6. ФОКУСИРОВКА НА ВНЕШНИХ СОБЫТИЯХ

104. 7. КОМАНДА НЕ БЕРЕТ ОБЯЗАТЕЛЬСТВА
ПО УЛУЧШЕНИЮ

105. 8. РЕТРОСПЕКТИВУ ВЕДЕТ ОДИН ЧЕЛОВЕК

106. 9. КОМАНДА УЧАСТВУЕТ НЕ ПОЛНОСТЬЮ

107. 10. НЕ КОНТРОЛИРУЕТСЯ РЕЗУЛЬТАТ

108. ДЗ 4.6
• Отсортировать проблемы в порядке важности (самое важное – наверху)
• Написать, с которой из проблем сталкивались в последнее время и как ее решили
Срок – 196 часов

109. Нет проблем – есть лишь решения!

110. ЕСТЬ ЛИ ВОПРОСЫ?

111. ПРОВЕРЯЕМ ОЖИДАНИЯ

112. ЛИТЕРАТУРА
• «Психология Убеждения. 50 доказанных
способов быть убедительным» - Р. Чалдини,
Н.Гольдштейн, С.Мартин
• «Agile Retrospectives Making Good Teams
Great» - Esther Derby, Diana Larsen
• «Agile Product Management with Scrum.
Creating Products that Customers Love» -
Roman Pichler
• «Project Retrospectives: A Handbook for Team
Reviews» - Norman L. Kerth