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

Анна Алексеева, «Комп&ньон» №22-2010

agile-управлениеПереворачивает с ног на голову классические проектные ограничения и при этом работает; меньше формализации и больше непосредственного общения и доверия — все это о гибком подходе к ведению проектов. Пока наибольшее распространение agile-управление (так его называют) получило в сфере разработки программного обеспечения. Но кто знает, куда эта практика перекочует дальше. Ее гибкость и ориентация команды разработчиков на результат — мечта любого заказчика, ведь требования рынка сейчас меняются перманентно. С такой же регулярностью могут вноситься и изменения в проект, конечно, при условии, что управление построено по принципу agile. Его суть заключается в том, что команда, работающая над проектом, вполне способна к самоорганизации — она сама может выбрать лучший путь к достижению результата. В таком случае менеджер проекта превращается скорее в помощника, который убирает преграды на пути команды. Заказчик в свою очередь получает возможность постоянно корректировать свой запрос. Изменилась ситуация — изменились вводные от заказчика. В теории все просто. О том, как работает этот подход на практике и при каких условиях приносит максимальную пользу, «&» рассказал Станислав Спиваков, технический директор Крайтек Украина, компании, занимающейся разработкой компьютерных игр, в которой уже несколько лет гибко ведется работа над проектами.

Легкость в деталях

Agile — это название семейства облегченных подходов к работе над проектами. Сформировалось это семейство в конце 1990-х в ответ на излишнюю громоздкость и формализацию водопадного подхода к управлению. Agile не содержит руководства к действиям и конкретных практик, это скорее принципы и ценности, которыми руководствуются успешные команды. Наиболее распространенная из методологий получила название scrum. Термин взят из регби — в игре так называют момент, когда все члены команды собираются вместе. Собственно, по-настоящему командная работа и является ядром гибкого подхода к управлению проектами. Его приверженцы уверены в том, что строгое следование изначальному плану работы не обязательно обеспечит проекту успех. Наоборот, своевременное реагирование на изменение ситуации и следующий за этим выхода за изначально заданные рамки может привести к победе. По сути, проект разбивается на множество коротких этапов (итераций), занимающих две-четыре недели. Каждую такую итерацию можно назвать проектом в миниатюре: у нее есть свои приоритеты, свои задачи, свой хоть и небольшой, но план. Завершенная итерация обеспечивает прирост функциональности конечного продукта. Кроме того, после реализации каждого такого небольшого этапа в начальный план действий могут вноситься некоторые изменения. Необходимо это, к примеру, если изменились требования рынка или появилась новая информация о продуктах конкурентов.

Agile-подход может работать как внутри отдельно взятой команды, так и в крупной организации. Для начала разберемся с командой. Итак, группа профессионалов получает входящий набор задач от заказчика. Каждой задаче присваивается свой уровень важности. Уровень определяет заказчик, команда же, в свою очередь, предлагает сроки, в которые она может выполнить то или иное задание. Как только задание на ближайшую итерацию определено, команда самоорганизуется для его выполнения. То, как именно будет достигнут результат, целиком зависит от людей. Потому изначально принимается, что каждый член команды — профессионал в своем деле, притом мотивированный на работу над проектом. Иногда возможность самому придумать себе правила работы может оказаться ширмой для некомпетентных или недобросовестных сотрудников. Но свобода действий обязательно вскрывает проблему мотивации и компетентности. Если люди находятся на недостаточном уровне самосознания, чтобы работать по принципам agile, в команде они долго не продержатся. Что касается мотивации участников проекта, то рецептов слома льда много. К примеру, можно изначально собрать команду из лидеров мнений и «продать» им идею agile-подхода. Специалисты, профессионально переросшие статические структуры своих компаний, также мотивированы к работе по принципу гибкого управления проектом. Такие люди с легкостью и желанием идут на самоорганизацию — это позволяет им найти свою нишу, попробовать что-то новое.

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

Практики взаимодействия

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

Другим примером эффективной практики может служить daily build. Ее суть заключается в том, что каждый день, например, в отрасли разработки ПО, у команды есть диск с версией конечного продукта, который мы ежедневно дорабатываем в соответствии с графиком приоритетов. Преимущество этой практики в том, что проблему с продуктом мы можем увидеть сразу. Такую версию можно показать заказчикам или инвесторам, а в случае с веб-проектами — открыть доступ реальным пользователям. Кроме того, в любой момент, если, допустим, закончились средства на дальнейшую разработку, есть что-то, что можно, грубо говоря, положить в коробку и продавать.

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

Самоорганизация команды — это, конечно, хорошо, но ведь есть еще и заказчик. Scrum предполагает, что взаимодействие команды с product owner, то есть человеком, представляющим клиента, должно осуществляться постоянно. У команды всегда должна быть возможность уточнить задачу. Это важно, так как в процессе работы часто всплывают мелкие неточности, а иногда и радикальные изменения требований. Чем раньше станет известно об изменениях, тем лучше, но на то, чтобы остановить итерацию, перепланировать микроцикл, нужно согласие представителя клиента.

Для организации работы с заказчиком в scrum применяют следующий подход. Внутри организации-исполнителя выбирается менеджер и назначается представителем клиента. Он осуществляет всю коммуникацию с заказчиком, он же является представителем клиента в команде. Эта роль становится одной из ключевых. Кстати, в гибком подходе к управлению в начале работы над проектом часто никто точно не знает, что в итоге должно получиться. Через результат, через продукт команда стремится понять рынок и заказчика, а заказчик — самого себя. Правда, клиент редко соглашается с тем, что у него не хватает понимания себя и своих запросов. Это тяжелый момент, но так становится понятнее, что команда не может пообещать большего, чем сделать все, что в ее силах, чтобы заказчик получил желаемое.

Agile-уместность

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

Первая — к подобной практике прибегают в аутсорсинговых фирмах, работающих, как правило, на западных заказчиков. Такой подход к работе над проектом обозначается в контракте, который, к слову, отличается от стандартного. В agile-контракте документируют, что на протяжении определенного срока исполнитель обязуется принести максимум пользы заказчику, описывается минимальный набор требований к продукту. Agile позволяет исполнителям делать то, что надо заказчику, при этом регулярно демонстрируя ему результаты. Клиент после каждой демонстрации может изменить приоритеты или требования. На практике это выглядит следующим образом. Заказчик выдвигает требования А, Б и В. Исполнитель отвечает, что, допустим, пункт А займет у него две недели, Б — неделю и В — еще неделю. Соответственно за следующие две недели команда может выполнить или только пункт А, или Б и В. Какую задачу выполнять первой — решает заказчик.

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

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

Традиционно agile хорошо работает в командах численностью семь-восемь человек. Процесс работы довольно прозрачен, и людям несложно договориться друг с другом. Вопрос масштабирования гибкого подхода к управлению проектами сейчас стоит очень остро. Из собственного опыта работы в большой команде могу описать несколько подходов. Иногда компания организуется таким образом, что внутри нее формируется несколько мини-команд. Каждая из них выступает как отдельный участник более крупной команды со своими планами и ежедневными встречами. Получается такая вот «команда команд» (scrum of scrums). Это мы, кстати, применяли в нашей компании.

Другой подход заключается в том, что каждая команда внутри крупной организации работает над мини-проектами. Сейчас, правда, большинство компаний, которые сталкиваются с проблемой масштабирования agile, склоняются к гибридным методам. Но сложности все равно остаются, ведь организацию нужно сделать максимально прозрачной. Это сложная задача, и она не формализована — нет рецептов, которые привели бы к успеху. Мне кажется, что в сфере разработки ПО agile-подход к управлению проектами уже состоялся. Но очевидно, что область его применения значительно шире — во всех сферах, где часто меняются тактические задачи и требуется креативное взаимодействие представителей разных профессий.

Ценности, отраженные в аgile-манифесте разработчика ПО

  • Личности и их взаимодействие важнее, чем процессы и инструменты.
  • Работоспособное ПО важнее, чем обширная документация.
  • Сотрудничество с заказчиком важнее, чем переговоры по контрактам.
  • Умение реагировать на изменения важнее, чем следование плану.
  • Удовлетворение клиента за счет ранней и бесперебойной поставки ценного ПО.
  • Приветствуются изменения требований даже на конечных этапах разработки. Это может повысить конкурентоспособность продукта.
  • Частая поставка рабочего ПО (каждый месяц, неделю или еще чаще).
  • Тесное ежедневное общение заказчика с разработчиками на протяжении всего проекта.
  • Проект строится вокруг команды мотивированных личностей, которые обеспечены нужными условиями работы, поддержкой и доверием.
  • Наиболее эффективный метод передачи информации — личная беседа.
  • Работающее ПО — лучший измеритель прогресса.
  • Спонсоры, разработчики и пользователи должны иметь возможность неопределенно долго поддерживать постоянный темп работы.
  • Постоянное внимание совершенствованию технического мастерства и дизайна.
  • Простота — искусство, не делать лишней работы — необходимость.
  • Команда регулярно размышляет над тем, как работать более эффективно, и адаптирует свое поведение к изменяющимся обстоятельствам.

Зависимые переменные

Евгений Делов, директор АНКОР в Украине:

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

Не вмешательство, но вовлечение

Николай Михайлов, генеральный директор портала rabota.ua:

Самоорганизация возможна всегда, но для этого необходимы три условия:

  1. Среди членов команды должны быть люди, разные по своим командным ролям, например: критик, координатор, генератор идей, исполнитель и проч. Каждая роль занимает свою зону в команде. Чем больше незанятых зон, тем ниже уровень самоорганизации.
  2. Наличие компетенций и профессиональных знаний у всех членов команды.
  3. Из предыдущего условия вытекает взаимное доверие — важно, чтобы люди в команде хотели и могли слушать и понимать друг друга.

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

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

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

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

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