Отзывы на книги автора «Джефф Сазерленд»

Планировать полезно. Слепо следовать плану — глупо.

Оговорюсь сразу. В моем идеальном розовом мире нет идеальной методологии управления проектами. Я считаю, что она просто не существует, потому что сколько проектов, столько и неизвестных - люди, задачи, внешние и внутренние обстоятельства - да мало ли что может повлиять на результативность работы команды? Поэтому задача хорошего управленца - быть в курсе существующих методологий, чтобы в нужный момент выдернуть из своего арсенала именно тот тревожный чемоданчик, который больше всего нужен в данный конкретный момент. И SCRUM лично для меня - всего лишь один из таких чемоданчиков. Хотя далеко намного более интересный, чем может показаться на первый взгляд.

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

1. 1 день = 1 совещание. Если вы не можете за 15 минут в день определиться с тем, на каком вы свете и что должны сделать для того, чтобы достичь успеха в одном конкретно взятом проекте - увольняйтесь. Или увольняйте руководителя, который тратит по 3 часа коллектива в день на переливание из пустого в порожнее и поиск виноватых в том, что проект не сдвинулся с места.

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

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

4. Работаем на результат. Распечатайте и повесьте где-то в пределах видимости вот эту картинку. Всякий раз, когда вам захочется собрать совещание, смотрите на нее и спрашивайте себя: "Что мы должны получить в результате совещания? И можем ли мы получить ЭТО каким-то иным путем?" Если вы не можете ответить на первый вопрос или отвечаете "Да" на второй - отменяйте совещание на фиг. Вы уже знаете, что надо делать.

5. Мама-Анархия (с). Забудьте о должностях, порвите визитки. В лучших командах есть только одна должность: Член команды. Исследования показывают, что чем более специализированы функции людей в организации, тем медленнее она будет. Если надо, сохраните названия должностей для внешнего использования. Но внутри команды они только все тормозят, и заметно.

6. ТОЛЬКО монозадочность. Мультизадачность - миф. Умение делать несколько дел одновременно - безбожно переоценено. У людей очень плохо с многозадачностью. Исследования однозначно говорят, что люди, которым кажется, что они с ней хорошо справляются, на деле справляются отвратительно. Всякий раз, как вы переключаетесь с одной задачи на другую, с подготовки отчета на email, ваша производительность резко падает. Делайте всякий раз что-то одно. Отводите для работы время без прерываний. Вы будете потрясены, как это повышает производительность.

7. 1 человек - 1 проект. Если вы хотите быстрых результатов - позвольте человеку сосредоточиться на одном проекте. Чем больше у вас коров, которых надо пасти, и которые так и норовят разбрестись в разные стороны, тем больше времени вы проводите в хаотичном движении, тем менее бесполезна ваша деятельность. Работа над несколькими проектами одновременно вызывает потери от 20 до 50% времени.

8. Приоритеты. Если у вас есть несколько проектов, и вы не можете выбрать, какой из них самый главный - это означает что среди них нет ни одного действительно приоритетного. Расставляйте проекты в порядке приоритетности для компании и реализовывайте их один за другим, по порядку. Ибо см. пункт 7.

9. Без героизма. Если ваш проект требует героизма (пары-тройки ночей в офисе или работы дома на кухне, например) - это не повод для гордости. Это повод задуматься о том, насколько хорошо организованы процессы в компании. Героизм - это в первую очередь признак глубоко дисфункциональной системы.

10. Считайте не часы, оценивайте по результатам. Сожгите табель учета рабочего времени. Измерение количества часов, которые сотрудник тратит на проект — бессмысленная метрика. Но почему-то именно на этой основе мы платим нашим сотрудникам, составляем контракты, оцениваем приложенные усилия. А смысл, спрашивается?

Если вас действительно заинтересовала тема SCRUM, то в качестве бонуса вам определенно пригодится вот такая замечательная инфографика от SmartRead (не могу не рекламировать этих ребят, потому что они - реально крутые. И денег за это не беру, заметьте :)).

В более высоком разрешении инфографика доступна здесь

И да пребудет с вами Agile.

Играли ли Вы когда-нибудь в регби? Есть такой контактный вид спорта с смешным и необычным мячом в виде эллипсоида. Я тоже еще не играл ранее. Но, вот, пришел у нас на работе новый большой начальник, после чего на всех уровнях управления стали внедрять эту новую для нас систему, так называемый SCRUM - что как раз и переводится с английского языка как начальная схватка в регби перед вводом мяча в игру:

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

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

Книга мастерски приукрашена. Автор, казалось, взял буквально весь мир в свидетели, где каждый его представитель доказывает выгодность применения тех или иных элементов Scrum. Тут вам и суперагенты ФБР, и японские мастера сюхари, и друзья, планирующие свадебное торжество, и губернатор городка одного американского штата, и работники специального фонда в африканской Уганде, и вооруженные силы США, успешно воевавшие в Афганистане (а теперь и в Сирии), и рядовая голландская общеобразовательная школа, и американские баскетболисты, проигрывающие "какой-то там Литве" (которые, вообще говоря, были уже чемпионами Европы, и в последние четыре чемпионата мира и Европы всегда участвовали в полуфинальных матчах). Абсолютно все успешно используют или использовали элементы методологии.

В итоге получился смачный рассказ о том, как Сазерленд "до такой жизни докатился", придумав Scrum. Мы можем узнать, где он почерпал идеи, получил опыт, чтобы выработать из известных приемов менеджмента свои элементы, которые и стали составными механизмами предлагаемой методики. Подходит ли она для организации управления проектом? В основном да, но не всегда. Подходит ли она к организации рабочих мест на любом предприятии? Однозначно не всегда. Например, в моей компании, где каждый работник на 40% занят в своей линии, а на 60% - в нескольких проектах, повсеместное применение Scrum нереально, для отдельных проектов, где нужны быстро реагировать на изменения - да, это интересно.

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

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

Ну, а пока посмакуйте несколько откровенных выводов Сазерленда:

Команда должна иметь такой набор специалистов, которые обладают всеми навыками, необходимыми для завершения проекта, какая бы ни была поставлена задача – разработать программное обеспечение для сервиса фирмы Salesforce.com или захватить террористов в Ираке.

Великие команды стремятся к цели, которая намного больше, чем устремления отдельной личности: выиграть Кубок НБА или стать лучшей ротой, чтобы удостоиться чести маршировать на похоронах генерала Макартура.

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

Планировать полезно. Слепо следовать плану — глупо.

Оговорюсь сразу. В моем идеальном розовом мире нет идеальной методологии управления проектами. Я считаю, что она просто не существует, потому что сколько проектов, столько и неизвестных - люди, задачи, внешние и внутренние обстоятельства - да мало ли что может повлиять на результативность работы команды? Поэтому задача хорошего управленца - быть в курсе существующих методологий, чтобы в нужный момент выдернуть из своего арсенала именно тот тревожный чемоданчик, который больше всего нужен в данный конкретный момент. И SCRUM лично для меня - всего лишь один из таких чемоданчиков. Хотя далеко намного более интересный, чем может показаться на первый взгляд.

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

1. 1 день = 1 совещание. Если вы не можете за 15 минут в день определиться с тем, на каком вы свете и что должны сделать для того, чтобы достичь успеха в одном конкретно взятом проекте - увольняйтесь. Или увольняйте руководителя, который тратит по 3 часа коллектива в день на переливание из пустого в порожнее и поиск виноватых в том, что проект не сдвинулся с места.

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

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

4. Работаем на результат. Распечатайте и повесьте где-то в пределах видимости вот эту картинку. Всякий раз, когда вам захочется собрать совещание, смотрите на нее и спрашивайте себя: "Что мы должны получить в результате совещания? И можем ли мы получить ЭТО каким-то иным путем?" Если вы не можете ответить на первый вопрос или отвечаете "Да" на второй - отменяйте совещание на фиг. Вы уже знаете, что надо делать.

5. Мама-Анархия (с). Забудьте о должностях, порвите визитки. В лучших командах есть только одна должность: Член команды. Исследования показывают, что чем более специализированы функции людей в организации, тем медленнее она будет. Если надо, сохраните названия должностей для внешнего использования. Но внутри команды они только все тормозят, и заметно.

6. ТОЛЬКО монозадочность. Мультизадачность - миф. Умение делать несколько дел одновременно - безбожно переоценено. У людей очень плохо с многозадачностью. Исследования однозначно говорят, что люди, которым кажется, что они с ней хорошо справляются, на деле справляются отвратительно. Всякий раз, как вы переключаетесь с одной задачи на другую, с подготовки отчета на email, ваша производительность резко падает. Делайте всякий раз что-то одно. Отводите для работы время без прерываний. Вы будете потрясены, как это повышает производительность.

7. 1 человек - 1 проект. Если вы хотите быстрых результатов - позвольте человеку сосредоточиться на одном проекте. Чем больше у вас коров, которых надо пасти, и которые так и норовят разбрестись в разные стороны, тем больше времени вы проводите в хаотичном движении, тем менее бесполезна ваша деятельность. Работа над несколькими проектами одновременно вызывает потери от 20 до 50% времени.

8. Приоритеты. Если у вас есть несколько проектов, и вы не можете выбрать, какой из них самый главный - это означает что среди них нет ни одного действительно приоритетного. Расставляйте проекты в порядке приоритетности для компании и реализовывайте их один за другим, по порядку. Ибо см. пункт 7.

9. Без героизма. Если ваш проект требует героизма (пары-тройки ночей в офисе или работы дома на кухне, например) - это не повод для гордости. Это повод задуматься о том, насколько хорошо организованы процессы в компании. Героизм - это в первую очередь признак глубоко дисфункциональной системы.

10. Считайте не часы, оценивайте по результатам. Сожгите табель учета рабочего времени. Измерение количества часов, которые сотрудник тратит на проект — бессмысленная метрика. Но почему-то именно на этой основе мы платим нашим сотрудникам, составляем контракты, оцениваем приложенные усилия. А смысл, спрашивается?

Если вас действительно заинтересовала тема SCRUM, то в качестве бонуса вам определенно пригодится вот такая замечательная инфографика от SmartRead (не могу не рекламировать этих ребят, потому что они - реально крутые. И денег за это не беру, заметьте :)).

В более высоком разрешении инфографика доступна здесь

И да пребудет с вами Agile.

Играли ли Вы когда-нибудь в регби? Есть такой контактный вид спорта с смешным и необычным мячом в виде эллипсоида. Я тоже еще не играл ранее. Но, вот, пришел у нас на работе новый большой начальник, после чего на всех уровнях управления стали внедрять эту новую для нас систему, так называемый SCRUM - что как раз и переводится с английского языка как начальная схватка в регби перед вводом мяча в игру:

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

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

Книга мастерски приукрашена. Автор, казалось, взял буквально весь мир в свидетели, где каждый его представитель доказывает выгодность применения тех или иных элементов Scrum. Тут вам и суперагенты ФБР, и японские мастера сюхари, и друзья, планирующие свадебное торжество, и губернатор городка одного американского штата, и работники специального фонда в африканской Уганде, и вооруженные силы США, успешно воевавшие в Афганистане (а теперь и в Сирии), и рядовая голландская общеобразовательная школа, и американские баскетболисты, проигрывающие "какой-то там Литве" (которые, вообще говоря, были уже чемпионами Европы, и в последние четыре чемпионата мира и Европы всегда участвовали в полуфинальных матчах). Абсолютно все успешно используют или использовали элементы методологии.

В итоге получился смачный рассказ о том, как Сазерленд "до такой жизни докатился", придумав Scrum. Мы можем узнать, где он почерпал идеи, получил опыт, чтобы выработать из известных приемов менеджмента свои элементы, которые и стали составными механизмами предлагаемой методики. Подходит ли она для организации управления проектом? В основном да, но не всегда. Подходит ли она к организации рабочих мест на любом предприятии? Однозначно не всегда. Например, в моей компании, где каждый работник на 40% занят в своей линии, а на 60% - в нескольких проектах, повсеместное применение Scrum нереально, для отдельных проектов, где нужны быстро реагировать на изменения - да, это интересно.

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

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

Ну, а пока посмакуйте несколько откровенных выводов Сазерленда:

Команда должна иметь такой набор специалистов, которые обладают всеми навыками, необходимыми для завершения проекта, какая бы ни была поставлена задача – разработать программное обеспечение для сервиса фирмы Salesforce.com или захватить террористов в Ираке.

Великие команды стремятся к цели, которая намного больше, чем устремления отдельной личности: выиграть Кубок НБА или стать лучшей ротой, чтобы удостоиться чести маршировать на похоронах генерала Макартура.

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

Очень рад что такая книга появилась на русском языке. Уверен, что она станет (если уже не стала) бестселлером. А это значит, что еще больше людей будет не только говорить про гибкие методологии и Scrum, но еще и понимать, о чем они вообще говорят.

Местами в книге много воды. Особенно в первых главах, через которые продираешься с мыслью "да когда ж ты что-нибудь по делу то писать начнешь?!". Но сама методология и ее идеология отлично разложены по полочкам. И это однозначный плюс книги. Удалось уяснить для себя несколько нюансов, которые раньше понимал не до конца.

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

Но поскольку книга рассчитана на тех, кто еще не знаком со скрамом, то эти детали можно и опустить. Они есть в другой литературе.

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

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

Вся книга посвящена тому ПОЧЕМУ Scrum работает (читатель об этом конечно забудет через недельку), и только последние самые главные страницы рассказывают как раз КАК Scrum работает.

О самом методе даже говорить не хочется. В целом я вообще не вижу разницы между этой книгой и прочими трудами, посвящёнными менеджменту в IT, например. Чем SCRUM-мастер отличается от менеджера по проектам? По сути, скрам - это получается режим мобилизации сил небольшой команды для закрытия проекта, своего рода спринт по чёткому списку задач, который в период этой работы не пополняется.

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

И в очередной раз для себя убеждаюсь - хочешь почерпнуть что-то действительно полезное, не потратив уйму времени, читай специализированные СТАТЬИ, а не эти талмуды.

Довольно странное чувство: все восхищаются книгой, и только ты думаешь, «как можно восхищаться абсолютной пустышкой, которая была создана по следующей технологии: взять несколько старых бестселлеров из мира бизнес-литературы, добавить здравого смысла, описать свой стиль работы и/или примеры из своей собственной практики (но не детально) и обозначить это всё какой-нибудь замысловатой аббревиатурой». Всё, ваш «бестселлер» готов. Вообще, мне хочется спросить людей: что есть в этой книге, чего нет в стандартной книге MBA по менеджменту или в нескольких бизнес-книгах по типу Друкер, Гольдратт, Деминг и пр.? Мой ответ: ничего, ничего нового в этой книге нет. И я думаю, и не могло быть.
Мне трудно объяснить суть метода, т.к. метода, как я уже сказал, нет. Есть множество историй, которые должны проиллюстрировать теорию данного метода, но так как теории, в широком или классическом виде, нет, то и истории получаются довольно комичные. Они выглядят примерно так. Берётся некая история, например, некий проект, который долго описывается, рассказывается о проблемах, с которыми столкнулись люди и пр. А потом вставляется фраза типа «мы поменяли корпоративную культуру» и, вуаля, проблема волшебным образом решается. Фантастика! Такого решения проблемы нет ни в одном уважающем себя учебнике по маркетингу или менеджменту в частности или в любой нормальной книге по бизнесу – в целом. Всегда даётся детальное описание не только сути метода, его теоретическая часть, но даётся также максимально возможное описание деталей, т.е. чтобы картина имела цельный, законченный вид (достаточно глянуть на такие книги как «Маверик», «Моменты истины. В сервисе нет мелочей» и пр.).
Да, автор ссылается на такие книги как «Доставляя счастье», «Дао Toyota», «Производственная система Тойоты. Уходя от массового производства» и даже на книги по психологии, но он не учитывает того факта, что нельзя все вышеперечисленные книги и теории, что они представляют, просто взять и слепо вместить в одну. Тот же Zappos («Доставляя счастье»), показывает, как работает одна цельная теория ведения бизнеса (я уж молчу, что книга «Доставляя счастье» является оригиналом, т.е. это не книга-сборник других авторов и их идей). Это, во-первых, а во-вторых, по моему мнению, все примеры, что приводит автор, совершенно оторваны друг от друга. Так, в книге есть глава посвящённая «счастью», которая основывается на позитивной психологии. Но вот дальше автор никак не развивает идею. Т.е. он говорит, что мол, позитивным быть выгодно и на этом всё как бы обрывается. Хочется спросить: какой смысл был в этой главе? Я уж молчу про главу, где автор описывает самый знаменитый эксперимент из социальной психологии, который был проведён Стэнли Милгрэмом, описание которого содержится в каждом учебнике не только социальной психологии, но и психологии как таковой. Т.е. автор просто из разных областей берёт самые знаменитые темы и всё (я крайне рекомендую прочитать книгу по социальной психологии, нежели читать вот такие огрызки). И опять же, зачем? Зачем, если никакой связи с предыдущими главами нет. Или взять тему обратной связи. Мол, кто-то в команде должен получать обратную связь от клиентов. Вообще, это не просто азы маркетинга и менеджмента, но базис, самое основное (точнее одно из основных), что человек изучает, когда знакомится с этими направлениями. Я даже скажу больше: для этого не нужно читать книги по бизнесу, т.к. это самоочевидно. И так вся книга. Даётся либо короткий пересказ из старого бестселлера либо какая-нибудь очевидная вещь, которую можно прочитать в любой соответствующей книге.

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

Вся книга посвящена тому ПОЧЕМУ Scrum работает (читатель об этом конечно забудет через недельку), и только последние самые главные страницы рассказывают как раз КАК Scrum работает.

О самом методе даже говорить не хочется. В целом я вообще не вижу разницы между этой книгой и прочими трудами, посвящёнными менеджменту в IT, например. Чем SCRUM-мастер отличается от менеджера по проектам? По сути, скрам - это получается режим мобилизации сил небольшой команды для закрытия проекта, своего рода спринт по чёткому списку задач, который в период этой работы не пополняется.

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

И в очередной раз для себя убеждаюсь - хочешь почерпнуть что-то действительно полезное, не потратив уйму времени, читай специализированные СТАТЬИ, а не эти талмуды.

Довольно странное чувство: все восхищаются книгой, и только ты думаешь, «как можно восхищаться абсолютной пустышкой, которая была создана по следующей технологии: взять несколько старых бестселлеров из мира бизнес-литературы, добавить здравого смысла, описать свой стиль работы и/или примеры из своей собственной практики (но не детально) и обозначить это всё какой-нибудь замысловатой аббревиатурой». Всё, ваш «бестселлер» готов. Вообще, мне хочется спросить людей: что есть в этой книге, чего нет в стандартной книге MBA по менеджменту или в нескольких бизнес-книгах по типу Друкер, Гольдратт, Деминг и пр.? Мой ответ: ничего, ничего нового в этой книге нет. И я думаю, и не могло быть.
Мне трудно объяснить суть метода, т.к. метода, как я уже сказал, нет. Есть множество историй, которые должны проиллюстрировать теорию данного метода, но так как теории, в широком или классическом виде, нет, то и истории получаются довольно комичные. Они выглядят примерно так. Берётся некая история, например, некий проект, который долго описывается, рассказывается о проблемах, с которыми столкнулись люди и пр. А потом вставляется фраза типа «мы поменяли корпоративную культуру» и, вуаля, проблема волшебным образом решается. Фантастика! Такого решения проблемы нет ни в одном уважающем себя учебнике по маркетингу или менеджменту в частности или в любой нормальной книге по бизнесу – в целом. Всегда даётся детальное описание не только сути метода, его теоретическая часть, но даётся также максимально возможное описание деталей, т.е. чтобы картина имела цельный, законченный вид (достаточно глянуть на такие книги как «Маверик», «Моменты истины. В сервисе нет мелочей» и пр.).
Да, автор ссылается на такие книги как «Доставляя счастье», «Дао Toyota», «Производственная система Тойоты. Уходя от массового производства» и даже на книги по психологии, но он не учитывает того факта, что нельзя все вышеперечисленные книги и теории, что они представляют, просто взять и слепо вместить в одну. Тот же Zappos («Доставляя счастье»), показывает, как работает одна цельная теория ведения бизнеса (я уж молчу, что книга «Доставляя счастье» является оригиналом, т.е. это не книга-сборник других авторов и их идей). Это, во-первых, а во-вторых, по моему мнению, все примеры, что приводит автор, совершенно оторваны друг от друга. Так, в книге есть глава посвящённая «счастью», которая основывается на позитивной психологии. Но вот дальше автор никак не развивает идею. Т.е. он говорит, что мол, позитивным быть выгодно и на этом всё как бы обрывается. Хочется спросить: какой смысл был в этой главе? Я уж молчу про главу, где автор описывает самый знаменитый эксперимент из социальной психологии, который был проведён Стэнли Милгрэмом, описание которого содержится в каждом учебнике не только социальной психологии, но и психологии как таковой. Т.е. автор просто из разных областей берёт самые знаменитые темы и всё (я крайне рекомендую прочитать книгу по социальной психологии, нежели читать вот такие огрызки). И опять же, зачем? Зачем, если никакой связи с предыдущими главами нет. Или взять тему обратной связи. Мол, кто-то в команде должен получать обратную связь от клиентов. Вообще, это не просто азы маркетинга и менеджмента, но базис, самое основное (точнее одно из основных), что человек изучает, когда знакомится с этими направлениями. Я даже скажу больше: для этого не нужно читать книги по бизнесу, т.к. это самоочевидно. И так вся книга. Даётся либо короткий пересказ из старого бестселлера либо какая-нибудь очевидная вещь, которую можно прочитать в любой соответствующей книге.

На русском языке издается очень мало книг о гибких методологиях разработки программного обеспечения. Поэтому выход любой "новинки", пусть и с огромным отставанием от оригинала — это грандиозное событие. Обойти стороной свежую книгу авторов скрама в такой ситуации оказалось просто невозможно. А зря. Оказалось, я совершенно не целевая аудитория книги, т.к. написана она для руководителей компаний, а не руководителей проектов.

"Софт за 30 дней" состоит из трех частей.

Первая часть, написанная Сазерлендом (самая большая) — просто рекламный буклет для руководителей компаний с общими рекомендациями по внедрению скрама. Куча воды, успешных кейсов внедрений и минимум конкретики.

Вторая часть, написанная обоими авторами — Scrum-гайд. Базовое описание методологии/фреймворка с его основными понятиями и артефактами.

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

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

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