Не так давно мы Газпромбанке пришли к очевидному выводу: можно создать сколько угодно отличных продуктовых команд с прекрасными разработчиками, но когда над тобой нависает такая махина, как банк, со всей его безопасностью, регуляторикой и прочими «выкрутасами», с которыми придется иметь дело, глаза начинают стекленеть, руки опускаться, а TTM отрастать.
Всем привет, меня зовут Кирилл Гилевич, и я хочу поделиться историей о том, как в очередной попытке отстать от разработчиков мы создали Центр методологии IT-производства, которым я и руковожу. Хочу поделиться тем, как мы оптимизируем взаимодействие между командами, какие процессы для этого придумали и зачем вообще нужны методологи.
Что делают и чего не делают методологи
IT-разработку можно представить как механизм из множества шестерней, которые должны вращаться самостоятельно и делать это синхронно с другими такими же. При этом в силу ряда особенностей некоторые из этих «шестерней» могут двигаться в противоположных направлениях и вообще быть квадратными, но каким-то образом они должны помогать друг другу вращаться. Наша роль — обеспечить это вращение. Механизм должен работать слаженно и без поломок.
Тут сделаю важную ремарку: мы не изобретаем велосипед. Сами по себе процессы IT-разработки уже давно придуманы и давно обкатаны: начиная от классической каскадной модели до Agile и прочих. Вот только «из коробки» ни одна из этих моделей не «приземляется» на большую организацию. Банк — это прежде всего финансовая структура, где есть множество факторов, которые влияют на все процессы: требования регуляторов, всевозможные аудиты, требования безопасности, специфический финансовый учет, вопросы, связанные с авторским правом, и так далее.
В общем, есть куча вещей, напрямую не связанных с разработкой, но которые оказывают на нее влияние. Плюс к этому любой крупный (и старый) банк — это организация с многолетним бюрократическим опытом, которая обладает множеством устоявшихся взаимодействий, которые невозможно отменить по щелчку пальцев.
Но. Для разработчика, который пишет код, создает программный продукт, все эти нюансы непонятны и неинтересны. Они ему мешают. А компании нужно быть продвинутой и современной организацией. Она должна делать классный финансовый продукт. Для этого нужно, чтобы она жила как современная, динамичная IT-компания. И вот тут появляемся мы. Наша задача — «приземлить» IT-разработку на банковские реалии и учесть требования максимального числа участников процессов.
Что мы для этого делаем? Начну с того, чего не делаем: в самом процессе разработки мы ничего не меняем. Он у нас как у всех: придумали, разработали, протестировали, выкатили в прод, эксплуатируем. Но на каждом этапе, от идеи и до финала, есть множество нюансов, которые нужно учесть.
Если свести наши задачи к ключевым пунктам, получится три:
унификация и адаптация производственного процесса;
разработка и внедрение методик для расчета метрик процесса (Time to market, Cycle time и др.);
легализация производственных практик, которые наши коллеги внедряют внутри банка.
Последнее особенно важно.За созданием процесса всегда следует его легализация — то есть закрепление в официальном перечне других, ранее внедренных процедур. Это требование регулятора, работа непростая и небыстрая. Ее емы как раз и делаем. Расскажу, какую ценность она создает.
Максимально быстро и просто: ключевые бизнес-ценности методологии
Методологи работают на одну глобальную цель — сокращение параметра Time to market. На пути к «проду» у продукта может возникнуть много разных вызовов, и проблемы со взаимодействием команд — одни из ключевых.
Простой пример — тестирование. У нас есть специальные встречи по инцидентам в непроизводственных средах. Вот пришла на тестовый полигон одна команда, что-то потестировала, а по пути умудрилась поломать тестовую среду так, что другая команда не может начать тестирование своих продуктов, и у них возникает простой.
Мы садимся и начинаем разбираться, что произошло, и если причину можно «полечить» — пишем соответствующие инструкции и плейбуки, чтобы ситуация больше не повторялась. Главная цель в итоге — продуктовые команды должны вывести свои продукты на рынок в максимально короткий срок и с минимальным количеством проблем.
Помимо вывода на рынок в цикле разработки есть и обратная процедура — вывод из эксплуатации. В какой-то момент выяснилось, что четкой процедуры для этого нет, и каждый раз сотрудники должны были выходить на дорогу приключений, выложенную граблями. Мы собрали всех причастных к процессу и начали задавать вопросы: что нужно, чтобы легко вывести систему из эксплуатации и не создать при этом проблем (связанных, например, с требованиями регулятора)? Итогом стала подробно прописанная процедура, которой теперь пользуются все.
Ценность методологов в том, что они обладают хорошим кругозором и осведомленностью о процессах в разных командах, которые часто не знают, что происходит «по соседству» — они занимаются своими продуктовыми задачами, и вопросы, связанные с управленческим учетом, юридическими нюансами интересуют их в меньшей степени.
Вот еще пример: некая команда делает некую систему. Польза, которую она принесет, — огромна. Чем раньше система заработает, тем лучше. Можно ее запускать? Нет. Потому что пришли юристы и говорят: «Друзья, а где распоряжение о начале разработки системы?»
И это не просто какая-то хотелка. Есть требования регулятора, нужно поставить систему на баланс, должны быть оформлены права собственности на результат разработки и т. п. Это все важно для компании. Но для разработчика — лишняя, неинтересная и тормозящая процесс работа. А когда под рукой есть методолог, всю эту бюрократию он может взять на себя, а разработчику остается главное — разрабатывать.
Работа в стороне
Тут еще раз надо сказать, что мы не влезаем в разработку: не работаем внутри команд, не участвуем в процессах. Вместо этого регулярно приходим на мероприятия по разбору полетов. Обычно на «ретро» завершенных проектов. Наша задача — разобраться, какие проблемы возникли у команды в процессе и какие из них действительно были проблемами, а какие — нет.
Получаем и «точечную» обратную связь. Например, приходит коллега: «У нас проблемы с СБ, они долго согласовывают и вообще редиски. Давайте обяжем их “отрабатывать” наши проекты в конкретные сроки? Все же просто!»
Нет, не просто. Открываем статистику: у других команд такой проблемы с СБ нет. Значит затык либо в определенных людях, либо в процессах. Начали разбираться, опросили представителей обеих сторон и переписали процессы так, чтобы сотрудники службы безопасности вовлекались в процесс разработки на более раннем этапе. Проблема ушла.
Как выглядит такая история без «арбитража»? Сначала все друг с другом долго и упорно бодаются («ты виноват», «нет, ты»), затем разбирательство эскалируется на уровень выше, а там недалеко и до «волевого решения», которое, вполне возможно, не удовлетворит всех участников «конфликта». А еще в результате может появиться какое-нибудь распоряжение, которое будет затрагивать вообще всех, хотя разобраться в проблеме можно было локально.
Непрерывный процесс
Методологи компании чаще других оказываются перед необходимостью решать подобные вопросы, поскольку те неизбежно возникают по мере роста компании.
Архитектура процессов — это НЕ разовая работа. Из-за меняющихся условий какие-то внедренные процедуры могут перестать работать, а тому, что давно отлажено (кажется) и работает (не очень), нужна оптимизация.
Вот еще пример. У нас есть процесс согласования бизнес-требований. В том числе с юристами. В какой-то момент стало понятно, что на их этапе все здорово замедляется.
После короткого расследования выяснилось, что на юристов вываливают вообще все. Даже то, что согласовывать необязательно.
В результате мы придумали правила, с помощью которых PO может легко разобраться, что требует согласования с юристами, а что — нет. Оформили нововведение в виде обновления для процесса, запустили и стали наблюдать. Поток необязательных задач для юристов (и негатива в их сторону) уменьшился, работа ускорилась.
Другой пример нашей работы я бы назвал «примирением моделей». Изначально процесс IT-разработки был выстроен «водопадом». Потом пришел Agile, но работать в нем стали не все. В результате у нас появились две разработческие ветки. Народ путается, идет не по той части процесса, делает много лишней работы. Тогда мы снова пересмотрели процесс и получили гибрид, который подходит и для тех, кто работает в Agile, и для всех остальных.
Следующим этапом ушли от системоцентричной разработки (когда все крутилось вокруг IT-системы) к продуктоцентричной (когда система выстраивается вокруг продукта) и заново пересмотрели все процессы и взаимодействия. В общем, возвращаясь к тезису из начала этой части, «тюнинг» процессов — это постоянная работа. Пока мы выстраиваем процесс, в бэклоге копятся идеи, над которыми нужно подумать на будущее.
Сопротивление переменам
Ошибаются ли методологи? Процессная архитектура работает на то, чтобы ошибок во взаимодействиях между командами не было и чтобы не появлялись процессы, не подкрепленные реальной необходимостью. Сложно представить ситуацию, когда новый процесс, разработанный методологом, после запуска «ломает» всю устоявшуюся структуру. Задача в том, чтобы такого не происходило. Но иногда нововведения застопориваются из-за фактора «а мы так не привыкли».
У нас была довольно сложная и не очень удобная система электронного документооборота. Главная ее проблема была в затяжном процессе согласования, с кучей лишних ролей: даже обычный «ок» от линейного сотрудника должен был сначала пройти через начальство. Работало это очень медленно и рождало много боли.
Мы перетащили документооборот в Confluence и разобрались с ролями. Стало удобнее, проще, быстрее, появилась возможность получать согласование напрямую, минуя иерархические лабиринты. Но из-за «мы так не привыкли» и «нормально же работало» у нас ушло почти полтора года на то, чтобы пересадить всех на новый процесс. Затащили буквально на «морально-волевых».
А иногда люди, не видя всей картины целиком, просто не понимают, зачем нужен новый процесс. Когда внедряли новые инструменты контроля производства, от которых напрямую зависело качество продукта, мы столкнулись с удивлением команд разработки: «нам не нужен дополнительный контроль». В итоге же этот самый контроль облегчил жизнь всем, в первую очередь самим разработчикам.
Подобные и похожие вызовы, с которыми приходится сталкиваться в повседневной работе, необходимость уметь разбираться в разных областях — все это накладывает определенные требования на то, какими навыками должен обладать хороший методолог.
Методологами становятся
Мы редко нанимаем в команду — только если расширяемся. Но когда возникает такая необходимость, каждый раз сталкиваемся с проблемой: как описать вакансию? IT-методологии не учат в университетах, а конкретной «карьерной тропы» нет. Чаще всего такие специалисты вырастают в смежных профессиях. Они выходят из тестировщиков, аналитиков, тимлидов — то есть тех людей, которые много общаются со всеми.
Чтобы стать методологом, надо иметь хороший кругозор — знать (хотя бы в общих чертах) специфику работы разных подразделений, разбираться в процессах и главное — уметь генерить идеи, которые сделают эти процессы лучше.
Нужно иметь «вертолетную» точку зрения, чтобы видеть все в совокупности и понимать, что подход условного Пети: «У нас тут какие-то архитектурные документы сложные, они нам не нужны, давайте мы их не будем делать. Я у Васи спросил, ему тоже не надо», — плохой. Потому что эта документация нужна еще Маше, Леше и Вадиму. Петя просто кроме Васи никого не знает. А методолог как раз в курсе.
Помимо твердых знаний о том, как все устроено в компании, нужно быть хорошим переговорщиком. Из примеров выше понятно, что новые процессы не всегда встречают с распростертыми объятиями, поэтому нужно уметь их «продавать».
Все эти качества сложно найти в какой-то одной профессии, поэтому чаще всего мы хантим и потом «растим» кого-то из соседних подразделений. И это оптимальный путь, если вы собрались выделить процессную архитектуру в отдельную функцию.
Как понять, что компании нужны методологи
Как обычно организовывается взаимодействие между командами? Лиды обсуждают процессы внутри, потом встречаются с другими лидами, договариваются о сотрудничестве. Но хорошо работает это только до тех пор, пока команд мало. А вот когда их количество переваливает за сотню... Добавьте сюда новых людей, которые тянут за собой старые привычки, и вариант «мы как-нибудь друг с другом договоримся» перестает работать. Совсем.
Нужен медиатор, который усадит всех за один условный стол и поможет им сначала договориться, потом — зафиксировать на бумаге, а после — легализовать договоренности на уровне организации.
Возникновение необходимости в методологах распознать просто: если команда растет, а совокупная продуктивность — нет, то, скорее всего, в процессах есть проблемы. Так было и у нас: в определенный момент мы разрослись и «созрели» для того, чтобы начать работать упорядоченно.
Если компания нацелена на максимально продуктивную деятельность, то едва ли существует другой способ достичь этой цели.