Scrum Master (курс) : Лекция 14

Цель

Понять какие цели следует ставить Servant Leader

Тезисы

Почему цель, а не задача

В классических проектах руководитель ставить задачи. Но "классические" проекты - это проекты производственные или строительные - a) где условия постоянны

б) ошибка в принятии решения тиражируется на множество произведенных товаров/услуг

в) но с другой стороны отлаженное производство не требует быстрых решений.

Софтверные проекты ОТЛИЧАЮТСЯ от классических

а) требования меняются широко

б) требования меняются внезапно

в) решение надо принимать быстро.

Т.е. риски принятия решения распределены по разному.

В решении есть два этапа

a) дивергенции (расходящегося мышления) - чтобы сформировать максимальный пул возможных решений

б) конвергенции (сходящегося мышления) - чтобы выбрать одно.

Одному легче выбирать одно, группе легче формировать пул.

Если посмотреть условия в которых принимается решение выше - в классическом проекте риски в основном лежат в принятии решения, конвергенция не так важна, сами по себе ситуации не настолько вариативны.

В софтвер проекте наоборот - важна скорость и важен просмотр всех вариантов - с этим всегда справляется лучше именно команда, больше суммарный опыт, ниже эффект туннельного зрения, меньше шансов что решение будет зависеть от одного человека.

Именно поэтому мы передаем цель и делегируем принятие решение команде. Это не просто "красивые фразы" и "абстрактные теории", а экономическая необходимость.

Как сфомулировать цель, подход RUP

По RUP (Rational Unified Process) для формулирования цели нам надо:

1) Знать для КОГО мы работаем/в чьих интересах. Это должен быть конкретный человек или конкретная группа людей.

2) Обязательно знать почему человеку/группе людей сейчас плохо от того, что мы еще не сделали.

Две причины:

- то что им сейчас плохо - мотивирует их на участие, а нам как раз нужен engagement stakeholders

- для команды мотивация превращается из реактивной (защитная реакция, чтобы не пострадать за не выполнение задачи) в активную (позиция "мы спасем этих несчастных").

3) Четкий сценарий как именно результатами нашей работы воспользуются и как именно поймет почему стало хорошо.

Т.е. "увеличить производительность сайта online торговли" плохая цель

Хорошая цель:

Для кого: Для владельца сайта on-line торговли

Почему плохо: Операции на сайте выполняются дольше 1 минуты, меньше половины пользователей успешно завершают заказ после того как положили товар в корзину

Как станет хорошо:

а) Операции на сайте выполняются не более чем за 5 секунд при 1000 одновременно работающих пользователей

б) Не менее 80% пользователей оформляют заказа после того как положили товар в корзину.

Как сформулировать цель, подход SMART

Подход SMART очень прост, популярен и широко распространен в разных областях. Расшифровывается как

Simple Measurable Attainable Relevant Time-Bound

Если мы уже воспользовались методом RUP выше - то у нас цель будет Relevant (знаем для кого и почему) и Measurable (знаем как узнать что получилось).

Оставшиеся помогают упростить управление достижением цели.

1) Проверяем что мы в принципе можем достигнуть (attain) эту цель в текущей ситации и имеющимися ресурсами. Если не можем - в Agile это как раз называется spike - экспермиент направленный на поиск решения или на опровержение гипотезы что команда способна достичь цели.

2) Устанавливаем время. Несколько причин:

a) преодоление закона Паркинсона ("Работа занимает всё отведенное на неё время").

б) преодоление принципа студента ("Делай всё в самый последний момент").

Это важно еще и в том числе для поддержки принципа "fail early" - чем выше риски и сложнее работа ТЕМ МЕНЬШЕ должны быть таймбоксы.

3) Простота.

Помимо очевидных преимуществ - типа простую цель легче отслеживать, контролировать и оценивать - есть еще одно, очень важное для Agile.

Успешное достижение цели хорошо мотивирует команду, укрепляет их веру в собственные силы. Если поставить сложную цель - до команда может потерять уверенность в собственных силах или commitment. Можество небольших достижений помогут удержать не только заказчика, но и саму команду вовлеченной и мотивированной.

Задание

• Начать ставить цели команде
• Оценить что получается хорошо
• Оценить что не получается
• Подготовить план по внедрению