Деньги из ничего

Специалисты по антикризисному управлению практически единодушны в оценках кризисного периода: в это время надо делать то, что ранее планировалось для повышения эффективности, но по разным субъективным причинам откладывалось. Однако топ-менеджеры часто придерживаются другого, более простого, но тупикового подхода “отказываться от лишнего” — начинают урезать ИТ- и маркетинговые бюджеты, сокращают зарплаты и объемы работ и увольняют специалистов. Ошибочность этого подхода в том, что он не сделает организацию лучше. Сотрудники, с одной стороны, “расходная” статья по зарплате, но с другой — именно они формируют доход, и в результате подобной политики через год-два компания столкнется с кадровыми сложностями. Из-за снижения маркетинговой активности уменьшится приток клиентов, что еще более осложнит финансовый климат, а структуры, которые экономят на имиджевой рекламе, существенно в этом имидже потеряют — на фоне тех конкурентов, кто подобные расходы сохранит. В кризисных условиях предприятию лучше не сокращать бюджеты, а пытаться в рамках доступных средств предоставлять клиентам лучшие продукты и услуги высокого качества, быстро и за разумные цены. В этом помогут, например, гибкие (agile) управленческие методологии, которые превращают организацию из обычной в гиперпродуктивную, если пользоваться терминологией их авторов. Потенциал улучшения практически в любой деловой структуре, утверждают лидеры agile-индустрии, составляет тысячи процентов.

Увеличиваем производительность в десять раз

Одна из наиболее известных методологий, которая хорошо адаптируется как к программированию и ИТ-проектам, так и ко многим другим областям деятельности, причем не только инженерным, — это Scrum. Она была придумана Джеффом Сазерлендом, бывшим пилотом ВВС США, и презентована в 1995 г. на международной конференции по объектно-ориентированному программированию OOPSLA'95. В том же году Сазерленд помог своему коллеге Кенту Беку разработать не менее популярную методику экстремального программирования.

В Scrum автор заложил идеи, которые родились у него во время участия в проекте Массачусетского технологического института по созданию шагающего робота с множеством ног. Разработчики построили модель адаптивного управления, состоящую из набора простых правил. В ней не использовалась БД для хранения подробной информации об окружающем мире, а управление периферийными устройствами осуществлялось в реальном времени в форме откликов на динамически меняющуюся обстановку внешнего мира. Схожим образом и Scrum предлагает компактный набор принципов, которые помогают команде самоорганизовываться и достигать экстраординарных показателей производительности. Согласно немалому числу исследований, посвященных agile-походам, Scrum опережает по эффективности классическую модель “водопада” при создании ПО в среднем в 5—6 раз. В конкретных проектах объемом 50 тыс. строк Java-кода показатель производительности программиста в “водопаде” составлял две функциональные точки (индустриальный стандарт оценки трудоемкости, поддерживаемый некоммерческой организацией IFPUG) в месяц — примерно несколько сотен строк кода, а в Scrum — семнадцать точек. В отдельных задачах хорошие Scrum-команды вообще демонстрировали фантастическую скорость, ежемесячно реализовывая около ста функциональных точек на человека. При этом производительность Scrum-команды линейно растет при увеличении объема проекта, а в “водопаде” заметно снижается.

В зависимости от полноты и глубины реализации Scrum-подхода результирующий рост производительности попадает в одну из формальных групп:

• ScrumButt — рост 0—35%. Пример — корпорация Yahoo, добившаяся 35%-ного улучшения продуктивности;
• Pretty Good Scrum — до 200%. Показателя 160% достигла Google при реализации проекта Google AdWords. А в одной из датских фирм, сертифицированных по высшему, пятому уровню зрелости программных процессов CMM, производительность после внедрения Scrum увеличилась в два раза;
• Good Scrum — до 300%, реализован в ряде скандинавских фирм;
• Great/Excellent Scrum — 400% и более. Классический пример — компания PatientKeeper, которую Сазерленд взялся консультировать в 2004 г., когда ее оборот составлял 4 млн. долл. Спустя год он вырос до 7 млн., затем до 13 млн., а в 2007 г. достиг 50 млн. долл.

Среди других крупных компаний, применяющих Scrum, отметим Adobe, IBM, Microsoft, MySpace, Oracle, Palm и Sony Ericsson.

Nokia Test

Насколько важна при внедрении методик Scrum личность консультанта? Не секрет, что во многих консалтинговых проектах решающее значение приобретает не декларируемая модная методика, а мастерство конкретных специалистов, достигающих высоких целей подчас вопреки формальным рекомендациям за счет богатого опыта. С одной стороны, в успехе PatientKeeper, без сомнения, существенную роль сыграли способности самого Сазерленда, придумавшего столь удачную технологию. С другой стороны, энтузиазм не менее важен — еще более внушительный проект был реализован в последние годы Базом Воддом, первоначально рядовым в общем-то менеджером Nokia, трудившимся над проектами этой корпорации в Китае. В 2005 г. он переехал в Хельсинки и стал массово внедрять Scrum. Результаты его деятельности таковы: если в 2003—2004 гг. объем продаж Nokia стабильно держался на уровне 29 млрд. евро, то к концу 2005-го он вырос до 34 млрд., в следующем году достиг 41 млрд., а в 2007-м составил 51 млрд. евро, а Nokia стала самым дорогим телекоммуникационным брендом. Для этой компании сегодня характерна наивысшая в мире удельная доля сертифицированных Scrum-специалистов.

Авторству Водда принадлежит популярный сегодня у Scrum-тренеров так называемый Nokia Test, который определяет минимальный набор требований на соответствие этой гибкой методике. Данный тест был в 2008 г. доработан лично Сазерлендом. Он определяет, действительно ли организация использует Scrum и задает абсолютный минимум ключевых правил. Вкратце его основные требования таковы:

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

Требования простые, но реализовать их сложно

Несмотря на внешнюю простоту минимального списка правил, мало кто способен реально его придерживаться. Почему же так происходит? Ведь данный набор организационных шаблонов выгодно отличается от других agile-подходов. Так, Scrum задает всего три проектные роли — в сравнении с десятками ролей в других методиках. Сазерленд, выступая на Торонтской конференции по гибким методологиям Agile 2008 с презентацией “Money for nothing”, отметил, что полное соответствие даже базовым принципам Scrum способно за год увеличить доходность компании на 200—400%, превратив ее в гиперпродуктивную.

Внешняя простота данной методологии не означает простоты ее реализации и использования. Для большинства организаций, пытающихся внедрять те или иные agile-подходы, согласно оценкам исследования IDC за 2008 г., средняя величина улучшения составляет лишь 16%. Гибкие технологии часто пытаются внедрять излишне формально, по указке сверху, в виде быстро забывающихся тренингов или книжного перечня правил, которые сами по себе дают эффект, однако не приносят гиперпродуктивности. Конечно, переход на короткие проектные итерации, улучшение коммуникаций, регулярная отчетность приносят определенный результат: возникающие проблемы и ошибки быстро устраняются, улучшается качество контроля и прогноза, расходуемые ресурсы удается точнее отслеживать и т. д. Но когда эти моменты реализуются бессистемно, разрозненно, принципиально важные вещи часто упускаются.

В agile-подходы встроены механизмы постоянного самоулучшения, поэтому их необходимо не просто “внедрять”, но и адаптировать саму организацию под новые управленческие принципы, что требует усилий, выработки новых привычек, а главное, правильного понимания гибких концепций. Так, частое перепланирование — не какой-то особый прием, а скорее выгода, получаемая от перехода к гибким технологиям. Однако причину и следствие здесь нередко путают. Неверной может быть сама бизнес-модель в компании, когда не поможет никакая самая лучшая методика. А если Scrum пытаются внедрить из любопытства, “по книжке”, начинается “творческое” игнорирование выверенных практикой требований (дескать, мы сами знаем, как лучше, и никакие эксперты нам не указ). В результате лишь половина организаций, декларировавших использование Scrum, проходит даже базовый тест.

Нередко основная миссия предоставления клиенту бизнес-ценностей подменяется стремлением соответствовать параметрам плана. Подчас отсутствует постоянный контакт с заказчиком, сотрудники могут трудиться не в одном рабочем пространстве, итерации продолжаются более четырех недель, а требования в их рамках не удается полностью реализовывать. Сами разработчики, которых отвлекают на второстепенные вещи, не всегда применяют эффективные инженерные подходы — хотя они явно в Scrum и не указываются, но подразумеваются нацеленностью на постоянное самосовершенствование. Сопротивляются гибким подходам и менеджеры, которым сложно переключаться с роли “надсмотрщика” на роль “тренера”. Недаром название Scrum пришло из спорта, а сама методика под руководителем проекта понимает в первую очередь психолога и организатора — он не распределяет задания, а выявляет и ликвидирует препятствия в работе и добивается высокой мотивации коллектива.

Истинный потенциал Scrum пока неведом

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

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