О чем книга? О более широком позиционировании Scrum как “методологии управления проектами, бизнесом” и даже “жизненным состоянием” (с.55), и “решением серьезных проблем человечества” (с.231) взамен существующего позиционирования как “методологии процесса разработки программного обеспечения” (с.50) и все это на фоне постоянной критики каскадной модели и диаграммы Ганта. О позиционировании самого автора как Гуру “Претворения Scrum в жизнь” (с.56). Об управлении противоположном “Макиавелли” (с.182) И вы не поверите - про бирюзовые организации, такие как Morning Star (с.257)

1. “Ради делового сообщества -
людей, не связанных напрямую с
миром высоких технологий” в
издательстве МИФ вышла книга
Джеффа Сазерленда "​SCRUM.
Революционный метод управления
проектами​", в которой Автор
“собирается раскрыть и разъяснить
преимущества Scrum как системы
управления в бизнесе”.
Хочу поделиться с вами, уважаемые
читатели, своими впечатлениями от
прочтения и изучения данной книги.
“О чем книга?”
“Стоит ли ее читать?”
“Что запомнилось?”
О чем книга?
О более широком
позиционировании Scrum как
“методологии управления
проектами, бизнесом” и даже
“жизненным состоянием” (с.55), и
“решением серьезных проблем
человечества” (с.231) взамен
существующего позиционирования
как “методологии процесса разработки программного обеспечения” (с.50) и все это на фоне
постоянной критики каскадной модели и диаграммы Ганта.
О позиционировании самого автора как Гуру “Претворения Scrum в жизнь” (с.56).
Об управлении противоположном “​Макиавелли​” (с.182)
И вы не поверите - про ​бирюзовые организации​, такие как Morning Star (с.257)
Стоит ли ее читать?
Если Вы любите “подглядывать” чужие бизнес-модели и улучшать свою, то стоит
читать.
1

2. Если Вы бывший военный и ищете где себя применить, то обратите внимание на
профессию “скрам-тренера” (с.156) и читайте эту книгу.
Если Вы хотите объяснить почему вредны глупые совещания, то стоит читать.
Если Вы собираетесь “Претворить Scrum в жизнь”, то стоит читать и дополнительно
ознакомьтесь с “​2016 State of Scrum Report​”.
Если Вы доверяете выводам World Economic Forum в том, что в ​ТОП-10 самых
важных способностей работников в 2020 году будут входить Complex problem saving и
Critical thinking, то стоит для “прокачки” Critical thinking.
Если Вы читали книгу Хенрика Книберга “​Scrum и XP: заметки с передовой” где
Предисловие от Джефа Сазерленда и Майка Кона, то читать не обязательно.
Что запомнилось?
Для целевой аудитории книга написана в легком и понятном стиле. После прочтения
книги у целевой аудитории появится желание и вдохновение внедрить “у себя” Scrum.
Отличная статистика Джеральда Вайнберга на с.111 о взаимосвязи между
количеством параллельных проектов, доступного для них времени и потерях времени при
переключении между проектами.
Часть “Будьте благоразумны” в 5-й главе на с. 128-29.
“Многозадачность отупляет” (с.130).
“Чем трудиться допоздна и еще по выходным, лучше работать в будни в постоянном
ритме” (с.131).
“все команды уникальны и неповторимы. У каждой свои темп и ритм работы.
Подгонять их под общий шаблон - верный путь в пропасть” (с.152)
“Без героизма” (с.131).
“Теперь нам надо оценить, сколько работы потребует каждая бумажка. Не как долго, а
сколько ​работы​.” (с.137) - это ведь Трудозатраты для формулы Д=Т/Е, о чем подробно
написано в Приложении 2.
“Помните, мы говорим об оценках, а о жестких плана” (с.150) - это означает, что
Scrum не берет на себя обязательства по точным срокам и если они (точные сроки) Вам или
Вашему руководству обязательно нужны, то помните об этом.
“...я назову вам дату сдачи проекта через полтора месяца, и она вам не понравится.
Но я дам вам список факторов, которые встают на пути ваших групп и реально мешают им
завершить проект в срок. Полный список препятствий. И задачей руководства компании
будет устранить эти препятствия как можно быстрее” (с.161) - это означает, что без
устранения препятствий Scrum не поможет.
“Сотрудникам кажутся нереальными изменения в корпоративной культуре” (с.161).
“Поистине иногда, чтобы подтолкнуть людей к переменам, им нужно приставить пистолет к
виску” (с. 162).
2

3. “Люди мыслят фактами и сценариями” (с.153).
Критерии готовности сценария INVEST (с.158).
7-я глава “Счастье”. Поглядите ​World Happiness Report 2017​, найдите свою страну и
подумайте:“Что именно делает людей счастливыми?” (с.175). “все зависит от корпоративной
культуры” (с. 176, 182).
Суть в том, чтобы признать неопределенность, полностью принять то, что любой
порядок и ценность верны только в конкретный момент (с.216).
“Клюнув” на название книги, при чтении я понял, что не являюсь на 100% целевой
аудиторией, поэтому сразу включилось критическое осмысление (Critical thinking), которое я
вынес в Приложение 1.
3

4. Приложение 1.
Видимо я не одинок в критическом мышлении, так например: 13.06.2017 ​Bill Duncan
(главный автор PMBoK 1996) назвал “2016 State of Scrum Report” в деловой соцсети Linkedin
- “​пропагандой​”
С самого начала меня удивило, почему не близкий к оригиналу перевод названия
книги - “революционный метод” да ещё “управления проектами” вместо “The Art of Doing
Twice the Work in Half the Time”, хотя использование выражения “Scrum революционный
подход” появляется на с.101. В мире профессионалов управления проектами
представителем которого является Вадим Богданов, чья книга указана как хорошо
дополняющую данную, SCRUM не является “методом управления проектами”.
По словам Кена Швебера (со-разработчик Scrum framework вместе с Джеффом
Сазерлендом, а так же основатель ​www.scrum.org​), Scrum – это не методология, это
фреймворк. Об этом же написано в статье “Agile project management with Scrum”,
опубликованной на сайте ​Project Management Institute​.
Метод разработки программного обеспечения - это не метод управления проектом, а
всего лишь его составная часть применимая для технологических отраслей. Об этом
написано в первых 3-х строках Введения: “... создали свой подход к разработке
программного обеспечения для технологических отраслей” (с. 9).
А уже на с.22 Автор пишет: “Конечным результатом применения методологии Scrum -
если угодно, целью всей разработки - являются команды, наглядно увеличивающие свою
производительность”.
Считаю вводящим в заблуждение сокращение в тексте формулировки “при
управлении проектами по разработке программного обеспечения” (с. 9) до просто “проект”.
Например, “революционный руководитель” прочитав следующее предложение на с.10
“Рассмотрю вопрос, почему организация проектов силами небольших команд является
более эффективным способом работы”, может ссылаясь на данное утверждение
потребовать реализовать инвестиционный проект строительства нефтехимического завода
силами 10 человек. Или далее “... мы применяли Scrum при проектировании абсолютно
всего...” - но ведь “проектирование” не равно “реализации”: проект завода - это не
управление заводом, как бизнесом, и получение прибыли от этого бизнеса.
Автор указывает, что Scrum был им придуман, чтобы преодолеть недостатки
каскадной модели управления проектами при разработке программного обеспечения (с. 9),
а именно:
1. пошаговая работа,
2. процесс медленный и непредсказуемый,
3. волокита на месяцы и годы,
4. диаграмма Ганта вводила в заблуждение руководство о контроле процесса,
5. выпадение из графика и рамок бюджета.
4

5. С моей точки зрения, указанные Автором недостатки не имеют прямой
причинно-следственной связи с каскадной моделью управления проектами. Указывая на
недостатки Автор совсем не говорит использовались ли существующие в то время
наработки по ресурсному планированию и буферам, о чем на сайте Project Management
Institute много статей. Как пишет в своей книге ЛОУРЕНС ЛИЧ / LAWRENCE P. LEACH
“​Вовремя и в рамках бюджета: Управление проектами по методу критической цепи (Critical
Chain Project Management)” на стр.102 "На своих занятиях в PMI я устраиваю
неофициальное исследование. Я спрашиваю, сколько студентов в планах своих проектов
указывают загрузку по ресурсам (то есть обозначают, какие ресурсы назначены на
выполнение каких операций, как на рис. 3.2). Обычно это от половины до двух третей
слушателей. Затем я спрашиваю, кто из них проводит выравнивание ресурсов. Обычно
таковых около 5%. Получается, что примерно 95% проектов уже с самого начала обречены
на провал. Не забывайте, что я опрашивал элиту управления проектами, большинство из
них — сертифицированные профессионалы РМР." Поэтому “рисовать” диаграмму Ганта и
обосновывать ее ресурсно - это не одно и тоже.
На стр.26-27 Автор говорит о том, что внедрение Scrum требует выявления и
устранения препятствий производительности. Но ведь это же очевидно! Разве это новость в
управлении?
Сам же автор и отвечает на этот вопрос: “Правда, мало кто занимается ликвидацией
помех, поскольку данная процедура требует от человека абсолютной честности перед собой
и окружающими”.
Первая глава книги начинается с описания статуса проекта в ФБР в 2010 году,
который начался в 2002 году и в 2005 году трансформировался в другой проект. Автор
описывает недостатки управления этим проектом и напрямую связывает их с недостатками
каскадной модели управления и диаграммами Ганта.
Прошу читателей обратить внимание на следующую информацию, которой нет в
книге: в 2002 году американская компания Microsoft выпустила на рынок Microsoft Project
2002 и в августе 2002 года, уже вышла книга Tim Pyron "​Special Edition Using Microsoft Project
2002​". Это очень мощный “проектный калькулятор” позволяющий уже в то время
использовать ресурсное планирование с изменяющейся скоростью потребления (с.311,
343), а не только “рисовать” диаграммы Ганта. В книге “Scrum” нет ни одного слова об
использовании технических возможностей MS Project для ресурсного планирования проекта
в данный период времени 2002-2010. Интересной для сравнения была бы информации об
использовании MS Project для управления проектами в технологической компании Boeing, а
не ссылка на “модель поведения Политбюро ЦК КПСС в конце 1980-х годов” (с.18).
Уже в 2002 году MS Project позволял учитывать “скорость” работы через формулу:
Д=Т/Е
Длительность = Трудозатраты / Единицы доступности или Производительность в
единицу времени
5

6. По сути формула в книге Хенрика Книберга “Scrum и XP: заметки с передовой” - это
уточненый расчет Е в формуле Д=Т/Е. А Диаграмма Ганта заменена на Burndown Chart,
который показывает прогноз сроков завершения на основе оставшихся трудозатрат в Story
point-ах, которые автоматически считает и MS Project.
На с. 23-24 подробно рассказано о “более продвинутом варианте оценки
производительности через определение доступных ресурсов” по формуле:
(Доступные человеко-дни) x (Фокус-фактор) = (Прогнозируемая производительность)
В Приложении 2 дано подробное описание и сравнение этих формул.
Внесение изменений в проект - это стандартный процесс PMBOK “Интегрированный
контроль изменений” — процесс анализа всех запросов на изменения, их одобрения и
управления изменениями поставляемых результатов, активов процессов организации,
документов проекта и плана управления проектом, а также предоставления информации об
их состоянии. В ходе этого процесса происходит анализ всех запросов на изменение или
модификацию документов проекта, поставляемых результатов, базовых планов или плана
управления проектом, а также утверждение или отклонение изменений. Ключевая выгода
6

7. данного процесса состоит в том, что он позволяет учитывать документированные изменения
в проекте комплексным образом, одновременно уменьшая риски проекта, которые часто
возникают в связи с изменениями, внесенными без рассмотрения в общие цели или планы
проекта.
Если исполнители проекта не используют данный процесс, то можно ли сам процесс
называть неработоспособным? Если кто-то не использует столовые приборы, то это не
означает, что столовые приборы неработоспособны? Более того, когда налагаются
“штрафы за внесение изменений” (с.221). На с. 53 Автор пишет “некоторые настаивали на
том, чтобы в процессе работы над многолетним проектом ​ни при каких условиях ничто не
менялось​. Даже при поверхностном взгляде это кажется полным безрассудством.” Верно!
Но ведь причиной этого не является ни каскадная модель управления, ни диаграмма Ганта.
Может быть истинной причиной является парадигма мышления, о которой написал в своей
книге ЛОУРЕНС ЛИЧ / LAWRENCE P. LEACH “​Вовремя и в рамках бюджета: Управление
проектами по методу критической цепи​(Critical Chain Project Management)” на с.286-288?
Ответ на этот вопрос Автор дает на с.77: “По настоящему великие команды с их
принципом информационной открытости и владения общим объемом знаний несут в себе
угрозу структурам с укоренившейся скрытностью и привычкой умышленно заметать следы
своих дел. Руководители организаций, где свойственно все держать в тайне, не желают,
чтобы кто-нибудь: рядовые сотрудники, ведущие специалисты, даже близкие к вершине
иерархической лестницы управляющие, - знал, что происходит в настоящее время, что уже
осуществлено и в какие сроки. Любые сведения и знания не подлежат распространению,
поскольку скрытая информация - единственный залог сохранения власти”. О
несовместимости этих парадигм доктор К. Грейвз сообщил общественности до своей смерти
в 1986 г. в своей теории ​Спиральной Динамики​. В Приложении 3 дано подробное описание.
Полностью согласен с тем, что “Все дело в построении правильной системы с
правильными стимулами. Нужно дать людям уважение и право делать свое дело
самостоятельно” (с.89). Главное чтобы у Вас были полномочия на строительство
правильной системы.
Очень интересно читать на с. 94 о том, что компания WIKISPEED работает по Scrum,
но еще более интересным было бы почитать их годовой отчет (annual financial report 2016)
чтобы увидеть взаимосвязь между Scrum и Profit / EBITDA. Поиск в google по ключевому
слову “wikispeed car annual financial report 2016” первым показывает: Annual Financial Report
2016 PDF - Daimler, Annual Report 2016 - BMW Group, а вот отчета WIKISPEED мне так и не
удалось найти. А еще очень странно читать следующие строки:
1) “Если вам захочется его (авто) приобрести, то нужно лишь перечислить на их счет
через сайт wikispeed.com $25’000 - и через 3 месяца машина ваша” (с.94).
2) “Машина ездит. Каждую неделю. Каждый спринт” (с.94).
3) “В итоге у вас есть наполовину собранный автомобиль” (с.117).
7

8. Вопросы:
1. Зачем машине ездить каждую неделю? Далее на с.96 рассказывая о разработке
космических ракет, уже не говорится об их запуске каждую неделю - почему? Если
главное свойство машины - ездить, то главное свойство ракеты - летать.
2. У Tesla, например, - роботизированный конвейер и поиск google сразу выдает ​tesla
annual financial report 2016​. Насколько уместно это противопоставление Scrum
конвейерной сборке автомобилей?
8

9. Приложение № 2
Таблица 1.
№ Термин MS Project Термин Scrum
1 Длительность (суммарной
задачи)
Sprint
(например, 3 недели=15 рабочих дней)
2 Задача User story
3 Трудозатраты / Объем работ Story point
(Приблизительно соответствует числу “идеальных человеко
-дней”) = 8 часов
12 story point= 12*8 = 96 часов
или
“Для трёх человек, закрытых в комнате, на это потребуется 4
дня” =12 story point:
3 человека*8 часов/день * 4 дня = 24*4 = 96 часов
4 Единицы доступности Доступные человеко-дни
Допустим, мы планируем трёх недельный спринт (15 рабочих
дней). Команда состоит из 4-ёх человек. Лиза берёт два
отгула. Дэйв сможет уделить проекту только 50% времени
плюс берёт один отгул.
Сложим всё вместе - 50 человеко-дней
5 Единицы доступности Фокус-фактор
это коэффициент того, насколько команда сфокусирована на
своих основных задачах.
Допустим, в ходе последнего спринта командой из трёх
человек в составе Тома, Лизы и Сэма реализовано 18 story
point’ов. Продолжительность спринта была 3 недели, что
составляет 45 человеко-дней.
18 story point’ов / 45 человеко-дней = 40%
6 Трудозатраты / Объем работ Прогнозируемая производительность
50 человеко-дней * 40% = 20 story point’ов (160 часов)
Простое моделирование в MS Project данной задачи показано ниже на рисунке 1, где
красным отмечены отгулы Лизы и Дейва. Если Лизе и Дейву ​нужно отрабатывать объем
работ, то команда не успевает выполнить работы в этом спринте.
9

10. Рисунок 1.
Если же Лизе и Дейву ​НЕ нужно отрабатывать объем работ и его можно
распределить на других членов команды, то результат показан на рисунке 2, где красным по
прежнему отмечены отгулы Лизы и Дейва.
Рисунок 2.
Как видите и MS Project и диаграмма Ганта могут успешно применяться при
ресурсном методе планирования сроков с учетом доступности (и фокус-фактора)
ресурсов/команды проекта. Я предоставлю данный файл MS Project для самостоятельной
работы всем, кто запросит.
10

11. Приложение № 3
“Ключ” к пониманию Спиральной Динамики.
Рисунок 3.
Фиолетово-Красный (личная власть и безопасность) противопоставляются Желтому
(самоорганизации и самоуправлению команд).
Качества лидера в Спиральной Динамике.
Рисунок 4.
11

12. Фиолетово-Красный лидер (директивный вождь, умеющий держать удар)
противопоставляются Желтому лидеру (создает данные из разных областей для целостного
видения).
Мои выступления о роли парадигмы мышления в управлении проектами:
2013, Москва, ВШЭ, конференция - “​Project Management - кому помеха, а кому помощь?​”
2016, Москва, ВДНХ, ЭКОФОРУМ - "​Роль и место спиральной динамики при внедрении
проектного управления​"
12