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

— Согласно теории нашего консультанта Джеффри Мура, сейчас WorkFusion находится в «стадии торнадо» — той фазе развития, когда количество клиентов за короткий промежуток времени может вырасти в разы, — рассказывает Вера Поклонская, менеджер компании по работе с людьми. — Мы больше не можем выполнять сложные задачи мануально, и простым увеличением количества персонала вопрос не решить. Чтобы стать крупнейшей компанией на рынке — «гориллой», нам нужно быстро меняться. Поэтому мы запустили «Операцию “Горилла”» — проект, который призван изменить образ мышления каждого нашего сотрудника.

Итоги этого изменения — трансформация команд, внедрение экспериментальных практик и переосмысление корпоративных ценностей компании.

Мосты вместо цементных заводов

Один из ключевых пунктов повестки «Операции “Горилла”» — agile-трансформация команды.

— Любой человек в ИТ знает, что такое agile, и, конечно, многие утверждают, что «делают agile», — говорит Вера Поклонская. — Но на деле всегда обнаруживается немало подводных камней. Часто компании не вникают в тонкости внедрения, и в итоге полностью отказываются от agile-методологии, попутно обвиняя её во всех проблемах. В какой-то форме agile всегда был и у нас, но мы решили его «перезапустить»: синхронизировать понятия, разобраться в деталях.

— В августе 2017-го на глобальном событии BreakAway президент компании обозначил задачу для всех команд, а прежде всего для инженерной: «Мы должны перестать строить цементные заводы и должны начать строить мосты», — рассказывает Юрий Шиляев, руководитель онлайн-академии WorkFusion. — У моста есть конечная и легко проверяемая бизнес-ценность: по нему можно проехать. А инженерная команда WorkFusion на этапе развития продукта занималась отгрузкой новых «фичей» в релиз — «строила завод». Компания фокусировалась на быстрой разработке функциональности, а не на бизнес-результате, для которого эта функциональность нужна.

Перед запуском agile-трансформации WorkFusion провёл переговоры с несколькими консалтинговыми компаниями и пригласил опытного украинского тренера Евгения Лабунского.

— Мы сразу поставили Евгению задачу: не просто провести тренинг по скраму, а запустить процесс изменений, kick-off проекта трансформации, — объясняет Юрий Шиляев. — В итоге двухдневный тренинг превратился в недельный интенсив для всех сотрудников минского офиса WorkFusion. Сам agile-евангелист впоследствии назвал недельный воркшоп в Минске «самой яркой профессиональной эмоцией года».

Новая структура и новый офис

Трансформация компании началась с упрощения структуры и переформирования отделов.

— У нас уже был хороший пример работы над небольшим бесплатным продуктом — RPA Express, — рассказывает Максим Ковтун, лидер RPA трайба. — Команда этого продукта была относительно независима, что позволяло ей быстро принимать решения и двигаться в разработке. Мы решили распространить опыт этой команды на другие: выделить три крупных продуктовых подразделения (RPA, AI, Platform) во главе с владельцами продуктов. Эта программа получила название 3PO (3 Product Owners).

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

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

Переезд в новый офис и отличный тренинг стали эмоциональным подъемом для команды — но дальше начались сложности.

Первые сложности: тренеры «расписаны» на месяцы вперёд

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

Внутренним консультантом в процессе agile-трансформации стал Юрий Шиляев, но для проведения интенсивов компания решила приглашать внешнего тренера.

— Приглашать в качестве коуча человека извне — хорошая практика: он нейтрален по отношению к организационной структуре компании, может видеть процессы со стороны, — объясняет Юрий. — Осенью мы снова обратились к Евгению Лабунскому, но он был плотно занят, и мы попробовали найти ему замену в Минске. Оказалось, что это почти все тренеры «расписаны» на месяцы вперёд: «Да, я согласен, вот мои условия, но доступен я буду только в феврале». Через пять месяцев!

Вывод: вы должны учитывать загрузку тренеров, если запланируете привлекать их в Agile-трансформацию.

Кого стоит включить в состав «команды трансформации»

Параллельно с поиском консультантов компания начала внутренние изменения по «дорожной карте», составленной на kick-off-тренинге.

Юрий Шиляев: Теория изменений в организации говорит, что опорой в трансформации должны быть агенты изменений — люди, которые помогают менять компанию вокруг себя. Агентами изменений могут быть и топ-менеджеры, и рядовые разработчики. Первая наша гипотеза была в том, что агенты изменений — это скрам-мастера.

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

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

Вывод: мы не можем опираться только на скрам-мастеров в процессе изменений. Команда трансформации должна включать в себя все уровни управления в компании.

Интеграция — самая сложная задача

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

Юрий Шиляев: Нашей ключевой проблемой оказалась интеграция. Во всех смыслах: и интеграция команд друг с другом (планы и зависимости), и интеграция продукта (CI/CD).

Ещё два месяца мы выходили на единый график планирования всех продуктовых команд (sprints cadence). Делали это последовательно, команда за командой.

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

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

Можно ли вырастить хорошего продуктового менеджера внутри команды

Юрий Шиляев: До Agile-трансформации в компании существовало вполне предсказуемое разделение труда: офис в Нью-Йорке взаимодействовал с клиентами и партнёрами, формировал видение развития продукта, а минский офис реализовывал задуманное. В августе 2017-го мы поменяли путь развития: в Минске были назначены три Product Owners (PO).

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

Марти Каган, партнер Silicon Valley Product Group, писал: «Лучшие продуктовые менеджеры уже работают в вашей компании». Поэтому мы пошли на риск — решили взрастить PO из вчерашних Delivery Managers (DM).

Спустя 4 месяца стало понятно, что совмещение двух ролей одним человеком — плохая идея. Роли PO и DM решено было разделить: люди были банально перегружены. Но успех всё же был: один из бывших DM в итоге стал владельцем продукта AI. Остальные сфокусировались на инженерных и организационных задачах.  

Мы начали выстраивать продуктовую функцию. Бизнес-аналитики сфокусировались на продуктовых задачах и целях, в компании появились UX-специалисты и начал формироваться процесс дизайна, роль PO стала отдельной, сфокусированной на проработке фичей.

В режиме «торнадо», в котором сейчас работает компания, важно, чтобы продуктовая команда была unflapped — если перевести попроще, умела «не дёргаться». Когда вокруг тебя десятки партнёров, клиентов, менеджеров, тикетов с улучшениями, очень сложно сохранять спокойствие и двигаться строго по выбранному пути. Мы всё ещё этому учимся.

Вывод: продуктовую команду надо выращивать внутри. Но сразу планировать: Product Owner – это full-time job.

Как War Rooms стали мощным мотиватором для руководителей разработки

Юрий Шиляев: Казалось бы, с чем совсем не должно быть проблем, так это с ownership: дали свободу действий —  берись и делай. Согласно выработанной схеме, команды получили бэклог с такой структурой:

— 20% времени каждый сотрудник может делать что угодно, полезное компании;

— 30% времени уходит на «оплату» технического долга;

— остальные 50% — на разработку продукта, новые фичи.

Но на деле разработка продукта занимала 120% времени. Разработчики — люди вообще крайне оптимистичные, а на эмоциональном подъёме от первых успехов — тем более.

В первоначальных оценках спринтов мы многое не учитывали:

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

— Сборка и интеграция. Раньше, когда продукт собирался не так часто, длительность этого процесса вообще слабо оценивалась.

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

— Зависимости между командами. «Мы скажем — они сделают» работает. Но не в те моменты, когда другая команда целиком сидит в war room или ничего не успевает, потому что их единственный DevOps ушел к клиенту на инсталляцию.

Меж тем, War Rooms стали мощным мотиватором для руководителей разработки: многие улучшения были направлены на то, чтобы «вар-румов» стало меньше. В целом, Ownership начал проявляться только тогда, когда проблемы стали задевать конкретные команды и конкретных людей. Как писал Ицхак Адизес, «если вы можете жить с проблемой, значит, для вас это не проблема».

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

Легко ли превратить три Road Map в одну 

Юрий Шиляев: Разделение на три продуктовые команды и выделение трёх руководителей упростило управление и ускорило принятие локальных решений, но породило другую проблему: у каждого из трёх подразделений (RPA, AI и Plarform) появилась своя «дорожная карта». Логично, что у продукта должен быть единый Road Map, поэтому мы перешли к этапу согласования.

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

Мы начали учиться фасилитации, проводили внутренние мастер-классы.

Сейчас мы живём по сформированным планам, но прекрасно понимаем, что с ростом компании внутренняя коммуникация только усложняется. В формировании последней общей «дорожной карты» продукта приняло участие около 40 человек. Возможно, это самое взвешенное продуктовое решение, принятое в компании. Для многих — тяжёлое, потому что многие важные задачи так и не попали в планы.

Вывод: попытки срезать углы не работают. Продукт один, и мы всё равно всегда возвращаемся к его обсуждению.

Как это работает семь месяцев спустя

Юрий Шиляев: За семь месяцев мы серьёзно изменились, хоть в каждую отдельную неделю нам и казалось, что изменений совсем мало. Это как с погодой: каждый отдельный день похож на вчерашний, но за месяцы погода меняется очень сильно.

Три больших продуктовых трайба из 11 команд работают в едином ритме. За основу для большого скрама мы взяли фреймворк LeSS. У нас ещё есть проблемы с регрессионным тестированием, задачи по автоматизации сборок — эти технические проблемы не решаются так быстро в платформе, которая разрабатывалась несколько лет.

С нами снова плотно работает Евгений Лабунский. Каждые 3-4 недели он приезжает к нам из Киева: проводит планирование, обучает скрам-мастеров и менеджеров, проводит мероприятия.

У нас появилась и оформилась продуктовая функция. Владельцы продуктов, продуктовые аналитики, дизайнеры совместно с бизнесом и командами формируют единый Road Map на 6-12 месяцев вперёд. Этот процесс не всегда проходит гладко, итоговые решения не всегда прозрачны для всех заинтересованных сторон. Но у нас в компании есть одно важное правило: если решение есть, ты можешь быть с ним не согласен, но ты должен ему следовать — быть с ним aligned. Лучше сделать и совершить ошибку, чем говорить и не сделать ничего.

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