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

• Название: Scrum. Революционный метод управления проектами
• Автор: Джефф Сазерленд
• Жанр: Управление, подбор персонала
• Год: 2015
• ISBN: 978-5-00057-722-6

Книга основателя методики Scrum, которая поможет вам реализовывать проекты в несколько раз быстрее и эффективнее. Возможно, историки будущего будут разделять прогресс человечества четкой линией: «до Scrum» и «после» — настолько эта методика революционна. Её используют в большинстве технологичных компаний мира, но теперь она доступна всем, кто имеет дело со сложными проектами в любой отрасли. Джефф изобрел свою методику, пытаясь справиться с недостатками классического управления проектами: людям редко удается работать слаженно, эффективно и быстро, большинство планов не выполняются (ни по времени, ни по ресурсам), подразделения и команды часто выполняют противоречащие друг другу задачи или дублируют их. За 20 лет существования Scrum помогла не только большинству разработчиков программного обеспечения, но и ФБР, автопроизводителям, фармацевтам и простым людям, планирующим свои дела. Эта книга полностью перевернет ваш подход к управлению проектами и поможет достичь результатов, которые раньше казались невозможными. Неважно, хотите ли вы изменить систему образования, изобретать новые технологии, бороться с голодом, просто открыть стартап или управлять своей командой в разы эффективнее — Scrum поможет вам успевать больше, затрачивая меньше времени и ресурсов. Для кого эта книга Для всех менеджеров проектов, руководителей, ИТ-специалистов.

---

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

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

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

Мы, адепты Scrum, недоумеваем. Почему работа требует столько времени и сил? Почему так трудно рассчитать, сколько времени и сил уйдет на реализацию задуманного? Шартрский собор строился пятьдесят семь лет. Готов поспорить, что перед началом строительства каменщики, глядя в глаза епископу, утверждали: «Двадцать лет — самое долгое. Может, и за пятнадцать справимся».

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

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

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

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

Результаты бывают настолько впечатляющими, что, по мнению лидеров на рынке исследований и аналитических услуг, таких как Gartner, Forrester Research и Standish Group, испытанный подход себя изживает. Компании, которые продолжают упорно пользоваться старыми, но отнюдь не добрыми концепциями контроля и управления, опирающимися только на прогнозирование, обречены на поражение в битве с конкурентами, перешедшими на методику Scrum. Разница слишком велика. Например, в бостонской фирме с венчурным капиталом OpenView Venture Partners — одной из компаний, где я являюсь консультантом, — утверждают, что методология Scrum обеспечивает слишком серьезным конкурентным преимуществом, чтобы пренебрегать ею. А предпринимателей, имеющих дело с рисковым капиталом, никак не назовешь белыми и пушистыми — эти толстосумы видят всех насквозь. И они без затей заявляют: «Эффект бесспорен. Все компании стоят перед выбором: изменись — или умри».

ФБР УСТРАНЯЕТ ПРЕПЯТСТВИЯ

Когда ФБР взяло на себя проблему доведения до ума проекта «Страж», то первой проблемой, с которой пришлось столкнуться Бюро, была документация. Дело в том, что раньше любое, даже самое незначительное изменение в программе приводило к новому обсуждению условий договора с Lockheed Martin. В итоге Джефф Джонсон и Чед Фулгэм долгие месяцы разбирались со всеми контрактами. Им пришлось сократить количество исполнителей с нескольких сотен до пятидесяти человек. Основная группа тоже стала намного меньше.

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

«Там было тысяча сто запросов. Груда в несколько десятков сантиметров», — вспоминает Джонсон. Сама мысль о таком количестве бумаги вызывает во мне чувство сострадания ко всем, кто потратил, должно быть, многие недели своей жизни на подготовку документов, не содержащих никакого смысла. Ни ФБР, ни Lockheed Martin в этом не одиноки — подобную картину я наблюдал практически в каждой компании, с которой имел дело. Эти высоченные бумажные штабели, воплощающие тщету человеческих усилий, отлично демонстрируют, как сильно Scrum может изменить жизнь людей. Никто не должен тратить свое существование на бессмысленную работу. Такая практика вредна не только для дела — она опустошает душу.

Итак, распечатав кипу документов, Джонсон и Фулгэм прошлись по ним, стараясь выяснить, какие задачи сложнее других и особенно важны для дела. Определить приоритет каждого запроса было необходимо, поскольку часто утверждается, будто существенно все. При таком подходе не мешало бы задать себе вопрос, который поставила перед собой команда проекта «Страж»: что сможет повысить эффективность работы и ее ценность? Найдя, что именно, этим и следует заняться в первую очередь. В сфере разработки программного обеспечения есть правило, подкрепленное десятилетиями исследований: восемьдесят процентов успеха и ценности любой программы заложены в двадцати процентах ее функциональных возможностей. Вспомните, когда в последний раз вам понадобилась в Microsoft Word функция Visual Basic? Возможно, вы даже не знаете, что есть такой редактор, как Visual Basic, не говоря о том, чтобы им пользоваться. Тем не менее эта функция есть, и кто-то потратил время на ее разработку. Уверяю вас, она не слишком сильно увеличивает ценность текстового редактора Word.

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

Группа «Стража» пыталась выяснить главное: «Ладно, мы ведем этот гигантский проект, который нам жизненно необходим и на который мы угробили уже миллионы долларов. Когда мы его закончим?» Продумав все нюансы, разработчики пообещали сдать проект осенью 2011 года. В отчете генерального инспектора, представленном осенью 2010 года, каждая страница была пропитана недоверием: