Scrum. Революционный метод управления проектами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оговорюсь сразу. В моем идеальном розовом мире нет идеальной методологии управления проектами. Я считаю, что она просто не существует, потому что сколько проектов, столько и неизвестных - люди, задачи, внешние и внутренние обстоятельства - да мало ли что может повлиять на результативность работы команды? Поэтому задача хорошего управленца - быть в курсе существующих методологий, чтобы в нужный момент выдернуть из своего арсенала именно тот тревожный чемоданчик, который больше всего нужен в данный конкретный момент. И 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! В книге просто и понятно изложены основные принципы подхода.

Ключевые тезисы книги

1. Проблемы традиционных методов управления Каскадные методы (Waterfall) часто приводят к перерасходу бюджета, срыву сроков и неудовлетворённости клиентов.

Жёсткое планирование не учитывает изменяющиеся требования и новые данные.

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

Гибкость – возможность адаптироваться к изменениям на основе обратной связи.

Самоорганизация команды – отсутствие жёсткой иерархии, ответственность распределяется внутри группы.

3. Роли в Scrum Владелец продукта (Product Owner) – определяет приоритеты задач (бэклог продукта).

Scrum-мастер – устраняет препятствия, следит за соблюдением процесса.

Команда разработки – кросс-функциональная группа, выполняющая работу.

4. Основные артефакты и события Бэклог продукта – список задач, упорядоченных по приоритету.

Спринт – короткий цикл работы (обычно 1-4 недели).

Ежедневные стендапы – короткие встречи для синхронизации.

Ретроспектива – анализ процесса для улучшения в следующем спринте.

5. Измерение эффективности Скорость (Velocity) – сколько задач команда выполняет за спринт.

Фокус на качестве – минимизация дефектов через постоянное тестирование.

6. Преимущества Scrum Быстрая доставка ценности – клиенты получают рабочие версии продукта раньше.

Снижение рисков – проблемы выявляются на ранних этапах.

Мотивация команды – автономность и прозрачность повышают вовлечённость.

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

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