Книга: Scrum. Революционный метод управления проектами - Джефф Сазерленд

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

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

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

Сазерленд приводит пример: разработка проекта Страж в ФБР. Это проект по модернизации и интеграции информационных систем бюро для повышения эффективности обработки данных и улучшения оперативных возможностей. Проект начался в середине 2000-х годов в ответ на критику в адрес ФБР после терактов 11 сентября 2001 года. Старые системы не справлялись с возросшими объемами данных и требованиями безопасности. Проект запустили в 2006 году. Первоначальные этапы проекта были сопряжены с многочисленными задержками и перерасходами бюджета, составляющие этого проекта устаревали прямо на глазах. В 2010 году было потрачено уже около 80% бюджета, а до запуска было еще как до Луны. Львиная часть времени и денег уходила на планирование и построение графиков и диаграмм (чистая обломовщина! более деятельная, конечно, но такая же безрезультатная).

руководство ФБР решило пересмотреть подход к реализации проекта и привлекло компанию Джеффа Сазерленда Sutherland Global Services для выполнения части работ. Sutherland была ответственна за тестирование и поддержку программного обеспечения, что помогло ускорить завершение проекта. Они использовали гибкую методику Scrum, отказались от планирования более чем на месяц вперед. Они разделили работу на спринты длиной в 4 недели. В начале каждого спринта они определяли план действий на следующие 4 недели. Целью каждого спринта было выдать маленький, но полностью готовый и протестированный продукт, который тут же показывали клиенту. На основе фидбэка от клиента они формировали задания для следующего спринта. Эти задания брались из общего списка всех заданий на проект, который формируется в начале всего проекта и который постоянно редактируется.

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

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

Конечно, Scrum это в первую очередь техника для работы в ай-ти, особенно для разработки приложений. Она идеально подходит под микросервисную архитектуру. Но Сазерленд утверждает, что Скрам можно применять и в иных областях: военной, в журналистике (с конкретными примерами). Один кореш Сазерленда даже применил Скрам в ремонте дома.

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

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

Несколько вещей в философии Сазерленда мне не понравились. Мне показалось довольно странным, что в книге, в которой очень много времени уделяется разнообразным аспектам работы во всех ее проявлениях и в которой даже есть глава «Счастье», про то, что все сотрудники должны быть счастливы, при этом ни разу не звучит слово «зарплата». От сотрудников требуется быть многопрофильными специалистами, и насколько я поняла, разделение труда в команде не совсем традиционное, но какого-то упоминания о достойной оплате труда я не нашла. Например, кореш, котоый применял Скрам при ремонте своего дома собрал команду из электрика, сантехника, кафельщика и других мастеров, кореш выступал в роли скрам-мастера. Каждое утро они собирались на сходку и 15 мин обозревали вчерашний день и обсуждали планы на день. Если складывалась ситуация, что электрик не успевал закончить свое задание и тормозил работу других мастеров, то другие должны были бросить все свои силы на то, чтобы сделать задание электрика. Мне интересно, как это решалось на деле (вряд ли кафельщик хотел делать работу электрика) и как в итоге это все оплачивалось. Это интересно вдвойне, потому что я все задаюсь вопросом, можно ли использовать скрам в строительстве и ремонте, потому что это две такие сложные области, где постоянно превышается бюджет и задерживаются сроки что на государственном уровне (строительство стадионов), что на частном (бесконечный ремонт в коридоре).

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

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

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

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

Сазерленд приводит пример: разработка проекта Страж в ФБР. Это проект по модернизации и интеграции информационных систем бюро для повышения эффективности обработки данных и улучшения оперативных возможностей. Проект начался в середине 2000-х годов в ответ на критику в адрес ФБР после терактов 11 сентября 2001 года. Старые системы не справлялись с возросшими объемами данных и требованиями безопасности. Проект запустили в 2006 году. Первоначальные этапы проекта были сопряжены с многочисленными задержками и перерасходами бюджета, составляющие этого проекта устаревали прямо на глазах. В 2010 году было потрачено уже около 80% бюджета, а до запуска было еще как до Луны. Львиная часть времени и денег уходила на планирование и построение графиков и диаграмм (чистая обломовщина! более деятельная, конечно, но такая же безрезультатная).

руководство ФБР решило пересмотреть подход к реализации проекта и привлекло компанию Джеффа Сазерленда Sutherland Global Services для выполнения части работ. Sutherland была ответственна за тестирование и поддержку программного обеспечения, что помогло ускорить завершение проекта. Они использовали гибкую методику Scrum, отказались от планирования более чем на месяц вперед. Они разделили работу на спринты длиной в 4 недели. В начале каждого спринта они определяли план действий на следующие 4 недели. Целью каждого спринта было выдать маленький, но полностью готовый и протестированный продукт, который тут же показывали клиенту. На основе фидбэка от клиента они формировали задания для следующего спринта. Эти задания брались из общего списка всех заданий на проект, который формируется в начале всего проекта и который постоянно редактируется.

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

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

Конечно, Scrum это в первую очередь техника для работы в ай-ти, особенно для разработки приложений. Она идеально подходит под микросервисную архитектуру. Но Сазерленд утверждает, что Скрам можно применять и в иных областях: военной, в журналистике (с конкретными примерами). Один кореш Сазерленда даже применил Скрам в ремонте дома.

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

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

Несколько вещей в философии Сазерленда мне не понравились. Мне показалось довольно странным, что в книге, в которой очень много времени уделяется разнообразным аспектам работы во всех ее проявлениях и в которой даже есть глава «Счастье», про то, что все сотрудники должны быть счастливы, при этом ни разу не звучит слово «зарплата». От сотрудников требуется быть многопрофильными специалистами, и насколько я поняла, разделение труда в команде не совсем традиционное, но какого-то упоминания о достойной оплате труда я не нашла. Например, кореш, котоый применял Скрам при ремонте своего дома собрал команду из электрика, сантехника, кафельщика и других мастеров, кореш выступал в роли скрам-мастера. Каждое утро они собирались на сходку и 15 мин обозревали вчерашний день и обсуждали планы на день. Если складывалась ситуация, что электрик не успевал закончить свое задание и тормозил работу других мастеров, то другие должны были бросить все свои силы на то, чтобы сделать задание электрика. Мне интересно, как это решалось на деле (вряд ли кафельщик хотел делать работу электрика) и как в итоге это все оплачивалось. Это интересно вдвойне, потому что я все задаюсь вопросом, можно ли использовать скрам в строительстве и ремонте, потому что это две такие сложные области, где постоянно превышается бюджет и задерживаются сроки что на государственном уровне (строительство стадионов), что на частном (бесконечный ремонт в коридоре).

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

Книга может быть и неплохая, но поддержу предыдущие рецензии в том, что тут реально много лишних слов. Их слишком много! Удивлюсь, если здесь наберется 20% полезного материала для читателя.

Формулировки и целые абзацы похвале метода можно смело пропускать. Примерно так всё это звучало в моей голове: "Вы будете эффективными, если будете использовать методологию Scrum. Scrum именно для тех, кто хочет быть эффективным. Было выявлено, что те, кто работает по Scrum методике, более успешны. Хотите быть успешнее, значит нужно использовать Scrum. Повысьте свою производительность с помощью Scrum. Со Scrum вы будете впереди всех!" Сплошные лозунги и не более. Мне такое не нравится от слова совсем.

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

В итоге огромный заголовок "РЕВОЛЮЦИОННЫЙ МЕТОД" оказался лишь уловкой автора. Я ожидал большего и понимаю, что мне не стоило строить иллюзий по поводу этой книги.

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

Приведу несколько наиболее ярких примеров ошибок, которые приводят к неэффективному труду: 1. Чем больше людей в команде, тем меньший объем работы вы выполняете.

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

2. Чем больше вы дел одновременно делаете, тем меньший объем работы выполняете.

При пяти параллельных проектах целых 75 процентов вашей работы уходит в никуда – три четверти рабочего дня коту под хвост.

3. Если вы не доделали работу или сделали больше чем нужно или то, что никому не нужно, вы потратили время зря.

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

4. Чем на большее время вы откладываете исправление только что сделанной и найденной ошибки, тем больше вам понадобится времени на ее исправление.

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

5. Чем больше вы перерабатываете, тем меньше работы делаете.

Как только сотрудники компании перестали трудиться с утра до ночи, они увеличили выработку вдвое.

Кроме ошибок в книге, конечно же, рассматриваются различные способы повышения эффективности и ускорения процесса производства, например: 1. Рассматривается тема постоянного совершенствования процесса производства.

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

2. Обсуждаются вопросы приоритезации задач.

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

3. Рассматривается тема раскрытия потенциала сотрудников и организации команд.

Нужно дать людям свободу, уважение и право делать свое дело самостоятельно. Величием нельзя наделить, оно должно исходить изнутри.

4. Обсуждается как стать счастливыми работая в команде на своей работе.

Истинное счастье можно найти в пути, а не в его завершении.

И это далеко не всё! Помимо этого рассматриваются различные инструменты (например, канбан), методы оценки задач, способы обмена информацией между сотрудниками и многое другое.

Работайте эффективно, не занимайтесь медленным самоубийством.

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

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