Текст книги "Саммари книги Джеффа Сазерленда «SCRUM. Революционный метод управления проектами»"

Елена Лещенко
Саммари книги Джеффа Сазерленда «SCRUM. Революционный метод управления проектами»

Система Scrum была разработана в 2005 году и применялась для оптимизации процесса разработки программного обеспечения. Со временем авторы поняли, что система универсальна и может применяться в любой отрасли. Независимо от того, какого масштаба проект и к какой сфере он относится, с помощью Scrum вы сможете кардинально изменить систему работы организации.

Одна из основных особенностей Scrum – гибкость. Система максимально быстро адаптируется к изменяющимся условиям внешней среды и внутренним процессам. Scrum делает возможным выпуск готового продукта в предельно короткие сроки и без перерасхода бюджета.

В основе Scrum лежат стремление к постоянному совершенствованию и совместная работа с заказчиком. Получая от заказчика обратную связь на протяжении всего процесса, разработчики постоянно дорабатывают продукт. И к моменту выхода на рынок он максимально соответствует потребностям покупателей.

Даже используя не всю модель, а только некоторые ее элементы, можно ускорить работу над очередным проектом, а внедрив систему полностью, значительно повысить доходность всего предприятия.

Глава 1. Привычное мироустройство дает трещину

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

Еще в начале ХХ века особую популярность получили диаграммы Ганна, которые очень детально и красочно (с использованием графиков, изображений и цветового оформления) описывали будущие планы работы над проектом: были назначены даты всех операций, событий и процессов. Однако, несмотря на то, что выглядели эти диаграммы внушительно, они не имели ничего общего с действительностью и всегда оказывались неверными. Такой способ ведения бизнеса подразумевает главенство процесса работы над результатом. Вследствие чего огромное количество времени уходит на детальное планирование, а затем на составление отчетности по выполнению планов. Руководители, вместо того чтобы своевременно выявлять недостатки и оперативно исправлять их, продолжают опираться на концепции контроля конечного результата, который, к сожалению, практически всегда оказывается нежизнеспособным. Проблема заключается в том, что специалисты работают обособленно друг от друга и не видят общей конечной цели.

Модель управления Scrum (от англ. «схватка» – схема командной игры в регби, подразумевающая слаженность всех членов команды в достижении общей цели) была разработана на базе цикла Деминга, который был успешно опробован компанией Toyota – одним из лидеров мирового автопрома. Цикл состоит из четырех этапов: планировать, действовать, проверять, корректировать. Эта же последовательность сохранена и в Scrum: весь процесс работы над проектом следует делить на короткие временные промежутки (спринты).

Предварительно планируется результат, который должен быть достигнут к концу спринта. Полученный результат тестируется и обсуждается всеми членами команды. Если он неудовлетворительный, то в первую очередь стоит обсудить качество работы команды, а также рассмотреть идеи улучшения результата следующего спринта. Так руководитель будет видеть ошибки по мере их появления и сможет оперативно на них реагировать. Это принципиальное отличие модели Scrum от классической модели управления, в результате которой ошибки копятся и выливаются в неработоспособный продукт.

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

Глава 2. Команды

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

Чтобы несколько отдельно взятых людей превратились в целостный организм, нужно соблюдать следующие правила:

♦ Общая цель. Только люди, объединенные общей целью, могут эффективно сотрудничать друг с другом, находить нестандартные решения задач и постоянно стремиться к совершенству. Если в коллективе каждый обеспокоен только своим личным благополучием, финансовой стабильностью или карьерными успехами, то результаты деятельности такой команды будут весьма посредственными.

♦ Автономность. Эффективная команда, работающая над конкретным проектом, должна быть полностью автономна от всей остальной организации. Такие коллективы самоуправляемы, они не подчиняются внешнему руководству. Они имеют право принимать решения и реализовывать их, самостоятельно выбирая способы и пути решения поставленных задач. Невозможно продуктивно работать, постоянно согласовывая свои действия с вышестоящим руководством.

♦ Многофункциональность. Плодотворная работа команды возможна только тогда, когда она объединяет в себе всех специалистов, необходимых для выполнения задачи от начала и до конца. Метод работы, при котором проект кочует из одного отдела в другой, является не рентабельным. Только единое информационное пространство между всеми участниками процесса дает плодородную почву для генерирования и воплощения нестандартных идей, ведь, имея возможность наблюдать за действиями коллег и перенимать их опыт, каждый сотрудник значительно расширяет свои собственные возможности.

♦ Малочисленность. Ученые в ряде экспериментов доказали, что малочисленным командам требуется гораздо меньше времени на выполнение задач (по сравнению с многочисленными группами). Оптимальными считаются коллективы численностью до девяти человек, большее число участников неизменно ведет к снижению эффективности. Это напрямую связано с физиологическими особенностями человеческого мозга, оперативная память которого в состоянии одновременно удерживать только четыре элемента информации. Чем больше коллектив, тем труднее каждому его члену адекватно взаимодействовать с остальными.

Организовав работу команды по модели Scrum, вы сами должны ей соответствовать. Вы должны стать так называемым скрам-мастером – это лидер, который не руководит действиями всех членов команды, а только координирует их, направляя и решая, возникающие проблемы. Такой руководитель не возлагает ответственность за неудачи на отдельных людей, он ищет изъяны в системе, в которой эти неудачи стали возможны. Человеческая природа такова, что абсолютно все мы подвержены влиянию извне, поэтому все наши действия продиктованы системой, в которой мы функционируем. Задача грамотного скрам-мастера – вовремя преобразовывать систему на благо эффективности команды, которая в ней работает.

Глава 3. Время

Время – не возобновляемый ресурс. Если не сформировать у команды чувство рабочего ритма, то результаты будут (если будут) достигаться гораздо дольше. Модель Scrum предполагает создание культуры продуктивной работы, а не просиживания рабочего времени.

Стоит предпринять несколько простых шагов, и вы увидите, что ваша команда способна на большее:

Разбивайте большие задачи на более мелкие и отводите на их решение определенные промежутки времени – спринты. Они должны быть короткими, не более четырех недель. Все спринты должны быть одной продолжительности, т. е. нельзя установить один спринт в две недели, а следующий – в четыре. Команда должна работать в жестком ритме.

Демонстрируйте результаты каждого спринта. Эти результаты должны быть абсолютно жизнеспособными, т. е. продукт должен выполнять свой функционал. Например, если вы занимаетесь разработкой ПО, то результатом каждого спринта должен быть рабочий программный компонент, который включает в себя функционал предыдущих компонентов и служит базой для разработки последующих.

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

Создайте атмосферу информационной насыщенности. Пусть каждый знает, чем занимаются коллеги, какие трудности у них возникают и каких результатов они добиваются.

Проводите ежедневные быстрые собрания. Их длительность не должна превышать пятнадцати минут, а круг обсуждаемых вопросов должен быть строго определен. Что было сделано вчера? Что будет сделано сегодня? Какие препятствия возникли на пути?

Организовав работу таким образом, вы создадите атмосферу общей вовлеченности в процесс, ведь теперь никто не сможет отсидеться, каждый несет ответственность за выполнение плана спринта. И если кто-то столкнулся с трудностями, остальные могут предложить варианты выхода из кризиса или свою посильную помощь.

Глава 4. Потери – это преступление

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

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

♦ Не бросайте работу недоделанной. Ваша задача в конце каждого спринта выдавать готовый к работе продукт. Если он не функционирует, то ваша результативность равна нулю, ресурсы и время были затрачены, а результата нет. Не позволяйте копиться таким недоделкам.

♦ Контролируйте остатки. Слишком большое количество готовой продукции, как ни странно, означает потерю денег. На производство были затрачены ресурсы, а готовый продукт пылится на складе. Деньги просто заморожены.

♦ Прилагайте максимум усилий, чтобы результат получался правильным с первого раза, а при обнаружении ошибки немедленно ее исправляйте. Исследования показали, что на устранение неполадок на стадии тестирования конечного продукта требуется в 24 раза больше времени, по сравнению с исправлением ошибки сразу после ее обнаружения.

♦ Не перерабатывайте. Система, при которой эффективность работника оценивалась по количеству отработанных им часов, уже давно себя изжила. При использовании модели Scrum не имеет значения, сколько было потрачено времени на решение задачи, если она решена грамотно. Помните, чем дольше рабочий день, тем меньше эффективность работы. Если вы хотите, чтобы ваша команда работала более продуктивно, предоставьте людям возможность отдыхать, иметь хобби и спокойно проводить отпуск вдали от рабочих процессов.

♦ Ставьте только достижимые цели. Слишком претенциозные цели, не имеющие шанса на достижение, могут вызвать лишь недовольство собой и даже депрессию.

♦ Не допускайте излишних усилий. Если для выполнения плана спринта вам требуется герой, который ценой неимоверных усилий все же сможет довести продукт до требуемого состояния, то это верный признак того, что в планировании была допущена ошибка.

♦ Грамотно организованный процесс протекает свободно и не требует геройства.

♦ Не позволяйте никому портить эмоциональную атмосферу. Практически в каждом коллективе встречаются личности, которые негативно влияют на коллег и создают обстановку нервозности. Ни в коем случае нельзя допускать, чтобы такие лица продолжали свое пагубное воздействие.

♦ Двигайтесь в потоке. Не отклоняйтесь от первостепенных задач, дисциплинированно следуйте к цели.

Долгие годы потери, сопровождавшие производственные процессы, считались неизбежными. Метод Scrum позволяет работать с минимальными убытками финансовых и трудовых ресурсов.

Глава 5. Планируйте реальность

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

Чтобы планирование было грамотным, придерживайтесь простого правила: не пытайтесь прогнозировать весь процесс заранее, вносите в план коррективы на протяжении всей работы над проектом. Ваша задача – объективно ставить цели на каждый спринт, чтобы по его окончании получить что-то работоспособное, то, что можно продемонстрировать заказчику.

Так вы сможете учесть все недостатки работы команды, все пожелания заказчика, все изменения в окружающей действительности и оперативно доработать общий план, поставив на следующий спринт более актуальную задачу. Иначе на выходе вы рискуете получить продукт, который морально устарел или перестал отвечать требованиям заказчика.

Начиная работу над новым проектом, составьте список задач, которые нужно решить в процессе работы (иначе говоря, разбейте большую цель на маленькие). Далее распределите их по значимости. Затем нужно оценить количество усилий и времени, требуемых для реализации каждой из них. В процессе оценки должны участвовать все члены команды, работающие над проектом. Это не должна быть отдельная группа экспертов. Только тот, кто знает весь процесс изнутри, может адекватно оценить требуемые время и энергию.

Чтобы избежать влияния на оценки таких особенностей восприятия, как стадное чувство и эффект ореола, применяйте метод «покера планирования». Его суть заключается в следующем: все участники получают карты с числами Фибоначчи (это последовательность, в которой каждое следующее число равно сумме двух предыдущих 1, 3, 5, 8, 13 и т. д.). Каждый этап проекта должен быть оценен по этой шкале. Участники «покера» оценивают усилия, которые необходимо приложить для выполнения рассматриваемой задачи, путем выкладывания карт с соответствующей, по их мнению, оценкой рубашкой вверх. Карты открываются одновременно. Если расхождения небольшие, то вычисляется среднее арифметическое всех значений. Если же разброс большой, то те, кто оценил задачу минимально и максимально, объясняют свою позицию. Затем карты выкладываются еще раз. Обычно расхождения со второго раза значительно меньше, а значит можно вычислить среднее значение.

Составив список задач, распределив их по приоритетности и оценив затраты на выполнение каждой из них, вы все равно рискуете не получить желаемого результата в установленные сроки. Проблема может заключатся в самих формулировках задач. Не имея четкого представления о том, что же должно получиться в итоге, команда вряд ли сможет эффективно работать над продуктом. Чтобы не столкнуться с такими сложностями, прежде чем определить приоритетность каждой задачи, проработайте «портрет» пользователя своего продукта, его предпочтения, страхи и мотивы. Узнайте его историю. Согласитесь, фразы «Мне нужен телефон», «Мне нужен телефон, чтобы всегда быть на связи» и «Мне нужен телефон, чтобы всегда иметь доступ к информации» рассказывают совершенно разные истории, соответственно, и приоритетность задач при разработке нового телефона будет разной. Только поняв мотивы потребителя, вы сможете объективно оценить значимость каждой маленькой цели.

Составляя списки заданий на основании историй, которые вы придумали, уделяйте внимание контролю готовности самой истории и выполнения поставленной задачи. Для этого воспользуйтесь критериями INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable):

Завершенность, выполнимость, независимость (Independent) – написанная вами история должна быть законченной, реализуемой и автономной от обстоятельств;

Открытость (Negotiable) – все члены группы могут принимать участие в процессе обсуждения истории и предлагать свои коррективы;

Ценность (Valuable) – история должна отражать реальную ценность продукта;

Оценочность (Estimable) – история должна быть удобна для оценки объема проделанной работы;

Лаконичность (Small) – история должна быть конкретной и краткой;

Тестируемость (Testable) – история должна соответствовать заранее разработанным критериям для проверки ее практичности.

Чтобы спланировать срок окончания всего проекта, вы должны проделать определенную последовательность действий:

♦ разбить проект на задачи (истории);

♦ распределить задачи по приоритетности; оценить объемы каждой задачи; спланировать первый спринт (недельный); по окончании спринта оценить динамику производительности команды; подсчитать оставшиеся задачи;

♦ оценить их объем; учитывая динамику, вычислить необходимое на их выполнение время.

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

Глава 6. Счастье

Человеку свойственно стремление к ощущению счастья. Оно становится возможным тогда, когда жизнь насыщена и активна. Только созидая, можно чувствовать себя счастливым. Каким же образом уровень счастья может повлиять на качество работы и ее продуктивность?

Исследователи давно выяснили, что счастливые люди гораздо успешнее на работе, в личной жизни и общественной сфере. Такие сотрудники лучше и активнее работают, повышая производительность, а значит и прибыль вашего предприятия. Чтобы держать под контролем счастье своей команды, относитесь к нему как к вычисляемому параметру – индексу счастья.

Индекс счастья (и каждого отдельного сотрудника, и коллектива в целом) – очень важный параметр при анализе и прогнозировании будущих показателей производительности предприятия. Отслеживая изменения этого индекса, можно предсказать движения значений производительности.

Как получить количественные значения индекса счастья? Просто задавайте всем членам команды четыре вопроса в конце каждого спринта:

Какова ваша роль в компании? (по шкале от 1 до 5);

Каково общее состояние компании? (по той же шкале); Обоснуйте свою позицию;

Что сможет сделать вас счастливее в следующем спринте?

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

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

Прозрачность. Все процессы, действия, финансовые вопросы должны быть в открытом доступе. Каждый сотрудник компании должен иметь доступ к информации о том, что происходит в компании, каковы показатели производительности и доходности. Не должно быть тайн и интриг, все должны быть частью одной команды, идущей к общей цели.

Крепкие связи. Взаимосвязи всех членов команды должны быть максимально тесными не зависимо от статусов и должностей.

Возможность расти. Давая сотрудникам возможность учиться и развиваться в профессии, руководители значительно повышают уровень счастья в коллективе.

Внедрив такую корпоративную культуру, вы создадите в компании атмосферу единства и созидания. Однако в какой-то момент вы можете увидеть обратную сторону медали счастья. Некоторые коллективы настолько проникаются своим совершенством, что перестают развиваться, попадая в так называемый «пузырь счастья». Эти люди забывают, что их основная цель – постоянное развитие и совершенствование. Такой момент важно не упустить и вовремя повлиять на сознание команды в целом или отдельных ее членов. Преимущество модели Scrum заключается в том, что все процессы прозрачны, а значит увидеть проблему можно на начальном этапе, когда ее легче всего предотвратить.

Счастье – двигатель любого проекта. Люди, чувствующие себя счастливыми сегодня и стремящиеся к счастью в будущем, неизменно ведут к процветанию компанию, в которой работают.

Глава 7. Приоритеты

Многие компании, имеющие перспективную идею, достаточное финансирование и профессиональную команду, почему-то не достигают высот и становятся убыточными. Такое положение дел связано с неумением расставлять приоритеты. Давно известно, что 80 % ценности продукта заложены в 20 % его функциональности. Следовательно, если правильно определить приоритетный функционал, можно создавать более полезный продукт при меньших временных затратах.

Прежде чем распределять задачи по степени важности, необходимо очертить общий круг задач. Это должен быть полный список всех функций и характеристик будущего продукта. Он может содержать в себе несколько пунктов, а может – сотни задач. Такой список называется «бэклог». Помните, что некоторые пункты бэклога никогда не будут реализованы, однако документ, содержащий весь потенциальный функционал, должен быть под рукой.

Далее следует переходить непосредственно к расстановке приоритетов. Для этого выберите из списка пункты, которые:

Наиболее важны для будущего потребителя; Принесут наибольший доход;

Максимально влияют на процесс работы; Проще всего реализовать.

Начинать стоит с тех функций, которые при выходе продукта на рынок принесут максимальную прибыль. Реализовав эту часть проекта и продемонстрировав ее в готовом виде заказчику, приступайте к наращиванию ценности продукта, добавляя к нему новые функции и характеристики из бэклога.

Сформулировать концепцию проекта, выяснить и выразить пожелания заказчика и приоритетные функции будущего продукта сможет специальный человек, называемый в системе Scrum владельцем продукта. Этот человек ответственен за написание историй и ведение бэклога. Его основной функцией является постоянный контакт с потенциальным потребителем (заказчиком или конкретным покупателем), он должен знать и чувствовать настроения клиента. С технической точки зрения его деятельность заключается в донесении до команды пожеланий клиента и тех оценок, что он дает готовым частям продукта.

Владелец продукта должен соответствовать нескольким основным требованиям. Он должен:

♦ Обладать информацией о состоянии рынка и уметь прогнозировать его поведение;

♦ Быть компетентным в оценке возможностей команды;

♦ Разбираться в сути продукта;

♦ Принимать решения самостоятельно (без вмешательства вышестоящего руководства);

♦ Быть на связи с командой постоянно, чтобы иметь возможность оперативно разъяснять вопросы приоритетности и при необходимости вносить коррективы в бэклог; Нести ответственность за ценность продукта.

Работа владельца продукта строится по следующему принципу: наблюдать (видеть актуальную ситуацию), ориентироваться (иметь несколько вариантов развития событий), решать и действовать. Такие циклы должны повторяться постоянно до достижения конечной цели.

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

После выявления функционала, в котором заключена максимальная ценность продукта, и реализации этой части проекта представьте продукт потенциальным потребителям. Да, он выглядит «сырым», но так вы сможет получить обратную связь, выявить не учтённые потребности покупателей и исправить все недостатки до официального запуска, уделив максимум внимания действительно ценным функциям.

Правильная расстановка приоритетов позволяет минимизировать риски. Существует три вида рисков, которых можно избежать с помощью модели Scrum:

♦ Рыночный риск. Этот риск связан с потребностью покупателя в вашем продукте. Нужен ли людям этот продукт? Снизить этот риск помогает пошаговая сдача продукта и активная обратная связь. Повышая ценность продукта на каждом спринте, вы практически исключаете риск того, что в конечном итоге он окажется бесполезным для потребителя.

♦ Технический риск. Риск того, что технически невозможно воплотить в жизнь задуманный продукт. Минимизировать его можно путем создания рабочих прототипов, которые тестируются командой для выявления наиболее работоспособных.

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

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