Гибридная структура, гибкие команды

Автор: Дмитрий Россихин, директор RDN-Group
Источник: It-world.ru

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

Прежде чем я перейду к развернутому рассказу — еще одно признание: Scrum в чистом виде наша команда почти никогда не использует. Крупные компании, с которыми мы работаем, применяют его в миксах, так как корпоративные правила не дают возможности использовать гибкие подходы — Scrum, Agile, Kanban — без «упаковки» их в бюрократические процедуры, которые свойственны тому же Waterfall.

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

Это раньше мир был нетороплив, и бизнесу было важно бережливо расходовать каждый цент или рубль. Современные бизнес-подходы иные — необходимо как можно быстрее тестировать гипотезы и запускать MVP (минимально жизнеспособные продукты). А это неизбежно приводит к росту себестоимости команд, работающих по гибким методологиям, и «расточительству»: тратить 10–20% бюджета на тестинг уже стало нормой для компаний, нацеленных на ИТ-прорывы.

Специфика гибких методологий — Scrum, Agile, Kanban — как раз позволяет быстро запускать MVP и тестировать новые гипотезы. Но при этом они требуют полного вовлечения в работу команд исполнителя и заказчика.

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

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

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

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

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

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

Еще одна особенность Scrum-команд — в гибридности. Если мы говорим о быстром достижении результата, то должны использоваться сильные стороны заказчика и исполнителя. Например, если исполнитель силен в разработке, а дизайн не является его ключевой компетенцией, заказчик может привлечь своих дизайнеров, и они вместе будут работать в одной команде для достижения общих целей. Может быть и наоборот. Здесь нет единых рецептов. Корректнее говорить, что надо создать такую команду, которая наиболее быстро позволит разработать MVP, отладить и максимально оперативно запустить изменения.

Я уже объяснил, почему наша команда почти никогда не использует Scrum в чистом виде: вместе с заказчиками мы объединяем гибкие методологии с тяжеловесной классикой, которая лучше воспринимается структурами с жесткой корпоративной культурой.

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

Для крупных и очень крупных организаций, в которых необходимо все фиксировать, мы применяем нечто похожее на Scaled Agile Framework. Сверху это формальный проектный подход — с комитетами, длинными цепочками согласований, а внизу работает команда разработчиков по Scrum.

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