Команда мечты в эпоху пандемии
11 приемов для руководителей IT-команд, чтобы бизнесу не только выжить, но и развиться в условиях безумно быстрых изменений и неопределённости
Как в новых условиях перевести на удаленную работу больше 3000 сотрудников и при этом не потерять управляемость, производительность и динамику финансовых показателей?
Как в новых вирусных условиях перевести на удаленную работу больше 3000 сотрудников и при этом не потерять управляемость, производительность и динамику финансовых показателей?
Один из крупнейших российских финтех-провайдеров, Группа Компаний ЦФТ, поставляющая IT-продукты и услуги более чем 300 банкам и миллионам жителей из десятков стран в апреле 2020 года сделала это. И это было лишь одним из действий в большом плане переналадки бизнеса в связи с приходом пандемии.
Но еще важнее другое. Ситуация с ковидом высветила главную мировую тенденцию — мы должны быстро меняться, перестраивать процессы и выводить на рынок новые продукты. Олег Бунин, организатор IT-конференций Ontico.ru и эксперт в области высоких интернет-нагрузок встретился с менеджерами и техническими директорами ЦФТ, и между ними зашел разговор именно о том, как командам удаётся сохранять работоспособность в таких условиях.
Краткое руководство от команды ЦФТ по выживанию и развитию в 2020 году вышло таким:
- Информация в организации должна распространяться мгновенно. Это должно стать культурой компании и поддерживаться на всех уровнях: от ТОПов до линейных менеджеров. Хороши все средства коммуникаций, и каждая команда может следовать собственным предпочтениям.
- Больше невозможно опираться на долгосрочные планы и подробные ТЗ — работаем «с колёс».
- От бизнес-идеи до реализации в продукте должно проходить 2-4 недели. Это прежде всего ответственность владельца продукта, который разбивает большие задачи на отдельно поставляемые ценности. Лучше быстрее создать прототип и внедрить его, а «правильную» реализацию сделать позднее.
- Заказчик находится внутри команды и на постоянной связи с ней: он в любой момент готов ответить на вопрос команды и оценить сделанную работу.
- Управление имеет плоскую структуру: иерархические подчинения не мешают быстрому принятию решений.
- В каждой команде есть несколько человек, которые умеют и любят говорить с заказчиком на одном языке. Такая деятельность закрепляется не должностью, а ролью.
- Нужны технические евангелисты, которые по мере необходимости внедряют лучшие инженерные практики и развивают культуру производства через профессиональные сообщества.
- Людям в команде позволяют ошибаться, их профессиональному мнению доверяют и пытаются понять их позицию.
- Команда более устойчива к выгоранию, если у нее есть время на проекты-отдушины, напрямую связанные с развитием собственных технологий и продуктов, но не обременённые давлением со стороны бизнеса.
- Руководство должно исповедовать servant leadership — быть поддерживающими менеджерами.
- Hard skills должны оставаться на очень высоком уровне — это фундамент всей работы.
И если вам стало ясно, что всё ещё ничего не ясно, то ниже вас ждут подробности этого разговора.
Участники:
- Евгений Погарский — советник директора ПС «Золотая Корона»
- Галина Гребенникова — руководитель отдела анализа и экспертизы «ЦФТ — Банковские системы»
- Алексей Мирютов — руководитель томского центра разработки «Золотая Корона — Денежные переводы»
- Константин Полуэктов — главный системный архитектор «ЦФТ — Банковские системы»
- Артём Каличкин — технический директор межбанковского процессингового центра Faktura.ru
- В роли интервьюера и оппонента — Олег Бунин, ontico.ru
Все мы уже знаем, в каком мире теперь живём, и остаётся понять самую малость: как именно нам жить в этом мире. Весной 2020 года моя работа круто поменялась: мне запретили делать то, чем я занимался 15 лет. Мне пришлось перестроиться. И вам пришлось перестраиваться, и вообще всем. Вопрос: что такого особенного должно быть в команде, чтобы она была готова к изменениям? И была ли готова ваша команда?
Организация прежде всего должна быть быстрой. Не более быстрой, а просто быстрой. Это значит, что от идеи до реализации должны проходить не месяцы, а считанные недели. Чтобы это стало возможным, во-первых, информация должна распространяться по организации мгновенно, для чего нужен свой набор технических решений.
Далее, люди должны быть готовы работать в такой парадигме, когда нет ТЗ — нет времени на раскачку и решения надо выносить на клиентов «с колёс». Для этого должны измениться владельцы продуктов, также и командам надо стать более гибкими, более слышащими бизнес.
Были ли мы готовы? Наверное, в самом начале всеобщей изоляции — не очень, как впрочем, и весь мир. А с другой стороны — техническая готовность была, так что примерно за месяц мы осуществили грандиозную миграцию всех наших команд.
Здесь был важный момент. Когда мы переходили на удалёнку, люди ждали определённости, а определённости не было, да её и не могло быть. Я и другие технические директора весь апрель прожили в режиме колл-центра, отвечая нон-стоп каждому своему сотруднику, что будет завтра, какая сейчас парадигма, куда дует ветер.
В один момент все производственные планы перестали быть опорой бизнеса. Нам, программистам, понадобилось прийти к важному ментальному изменению: долгосрочных планов может не быть, они могут быть непонятны. Сегодня банк может сказать: мы замораживаем все проекты, а на следующий день — вот этот и этот продолжаем. Такую ситуацию надо внутренне принять.
Теперь мы по-честному живём спринтами. Раньше у нас спринты были, но были и роадмэпы на полгода вперёд, а теперь — только спринты. И это в текущих реалиях нормально.
Окей, информация должна быстро распространяться по команде. Это хорошие слова. А как?
Когда мы анализировали, почему тот или иной проект долго заезжает в работу, то увидели, что много времени теряется между представителями заказчика (по классике, это роль владельца продукта) и производством. Как мы пытались сокращать?
Предложения звучали очень кардинальные — вплоть до таких KPI для менеджеров, что, мол, ребята, у вас есть два часа — и за два часа ответ должен быть. В итоге мы научились договариваться с заказчиками о том, что нужны быстрые ответы.
Иногда приходилось «прозванивать» всю цепочку: если кто-то из менеджеров быстро не ответил, идём к следующему, и так вплоть до самого заказчика. Такая персональная настойчивость сильно сократила время поставки.
То есть вы попробовали «построить» заказчика, поместить его в некие рамки, чтобы он работал быстро.
Да. Коммуникация «заказчик-производство» объективно долгая. Раньше заказчик мог себе позволить, условно говоря, уйти в раздумья на три дня. Но если теперь мы поставлены в условия, что за десять дней должны пройти путь от постановки задачи до выпуска обновлённого продукта, то три дня — это неприемлемо. Важно донести эту информацию до заказчика так, чтобы он её принял.
Хорошо, как ещё ускорить коммуникацию с заказчиком?
Нужны плоские организационные структуры. Никаких многоуровневых иерархий, когда одни менеджеры транслируют информацию вторым, те третьим и так далее. В идеале, нужен один человек от бизнеса, который самостоятельно принимает решения, и нужна команда, которая также действует без длительных согласований. Архитектурные комитеты и другие замечательные инстанции — раньше они были весьма полезны, но сейчас рискуют затормозить реализацию.
Уточню, что эти структуры остаются, но они меняются, становятся более итерационными.
Можно сказать, что мы вносим заказчика в команду разработки?
Да, это один из путей. У нас были такие успешные истории, когда на старте новых тем с высокой неопределённостью заказчик всё время находится на связи с командой. В реалиях распределённой команды, мы просто собираем групповой чат в Teams, и заказчик сидит там вместе с нами. Команда что-то обсудила, порисовала, тут же спросили — тут же получили ответ. Работает очень здорово.
Для нас хорошей практикой стало подключение заказчика в некое общее пространство, в котором мы, с одной стороны, ведём сбор и обсуждение бизнес-требований, а с другой — выдаём на испытания и оценку готовые результаты.
А что делать с тем фактом, что бизнес и разработчики говорят на разных языках?
Известно, что, по заветам scrum и agile, есть владелец продукта, есть скрам-мастер, есть команда. В ЦФТ как-то всё эволюционно сложилось по-другому. У нас в каждой команде есть тимлид, и это не должность, а роль. Тимлидами являются аналитики, тестировщики, разработчики. Это люди, которые замыкают на себя микроменеджмент команды; они умеют до каждого донести прозрачную картинку, кто чем живёт. Владелец продукта, например, сейчас живёт не только фичами, а ещё и кастомер-девелопментом, и вот он прибегает и что-то на этом языке говорит. Благодаря тимлиду команда это всё может «переварить».
То есть тимлид — это такой переводчик?
Скорее даже не переводчик, а интерфейс перевода. Он может, когда надо, привлечь аналитика, дизайнера, кого-то ещё, но сам выступает некой точкой сборки.
Здесь ещё важно непрерывное участие технических лидеров в передаче знания от заказчика к исполнителю. В апреле — мае 2020 года у нас возник показательный кейс с одним из клиентов. Знания заказчика были однократно переданы в команду, после чего попытка решения задач «в лоб», строго по требованиям, привела к серьёзным потерям темпа разработки. Техлид включился в процесс только по факту пробуксовки, а по-хорошему, ему надо было сделать этот шаг с упреждением.
На ранних этапах проектирования решения нужно включать не только техлидов, но и ребят, которые отвечают за эксплуатацию, сопровождение, информационную безопасность. Вот тогда, подойдя вплотную к производству, не придётся всё переделывать.
Может, тогда сразу ещё и продавцов?
В идеале — да, ещё и продавцов. Здесь можно спеть мою любимую мантру: agile невозможно построить только в разработке — он должен быть во всей организации.
Хочу добавить своё видение по тимлидам. Несомненно, эта роль важна, но если её абсолютизировать, тимлид станет «бутылочным горлышком» для команды. В каждой своей команде я стараюсь выделить несколько человек, которые могут общаться с заказчиком. Не надо каких-то гениальных скилов — пусть хотя бы не боятся задавать вопросы. Когда заказчик принёс непонятное описание, требуется просто встать и сказать: «Нам непонятно». Здорово, когда несколько членов команды могут понимать тот язык, с которым приходит бизнес.
Полностью поддерживаю. Недавно как раз читал статью одного из основателей бережливого производства в ИТ под названием «Product Owner Is a Bad Bad Idea». Там основная мысль именно такова: роль владельца продукта должна со временем исчезнуть, а его работу будет делать вся команда. Это, может быть, пока от нас далеко, но думать в этом направлении надо. Не должно быть одного человека, который всё решает за команду.
В принципе согласна, но не была бы так категорична. Бизнес бизнесу рознь, и где-то роль владельца продукта крайне уместна.
Не вижу в этих позициях противоречия. Это, скорее, вопрос эволюции. Вот, например, ко мне приходят ребята и спрашивают: «Что является вершиной моих тимлидских достижений?» Я отвечаю: «Вершина — это когда тимлид перестал быть нужен в команде».
Прекрасный тезис, полностью его разделяю.
Итак, у нас есть быстрая живая команда, в отличие от медленной мёртвой. Она обладает, скорее всего, плоской структурой, в которую заказчик глубоко интегрирован. Между ним и командой царит взаимопонимание. А должен ли заказчик, понимать техническую сторону производства?
Конечно, заказчику сложно понимать все эти заморочки, вроде «давайте это сделаем в паттернах реактивного программирования» — зачем это ему надо?! Тут дело в другом. Парадигма быстрой плоской команды требует доверия. Но не безоговорочного, а как результата встречного движения. Это доверие должно подкрепляться результатом, компетенциями. Но доверие должно культивироваться, и это главнейшая компетенция, к которой должен прийти менеджмент всех уровней. Невозможно эффективно действовать на местах, когда за каждое решение бьют по рукам и когда его каждый раз оспаривают.
И как обеспечить такое доверие?
Где-то позволять ошибаться — в определённых рамках. Где-то услышать, попытаться понять, почему, допустим, инженер предлагает именно такое решение. Был у меня такой яркий пример: дизайнеры нарисовали кнопку, и андроид-разработчика бомбануло просто категорично: «Я так делать не буду». И пошёл конфликт. В результате, когда разобрали ситуацию, оказалось, что предложенное решение крайне не нативное для Android SDK и на его точную реализацию нужно будет потратить уйму времени. И вот каждый раз надо докопаться до контекста — почему Баба-яга, собственно, против.
Хорошо, на организационном уровне поговорили, понятно. Спускаемся на уровень пониже. Технически, технологически как команде подготовиться к быстрым изменениям? Каков инструментарий?
Сейчас будет выход Кэпа. Есть множество хорошо известных инженерных практик. Есть код-ревью, которое позволяет поддерживать качество на приемлемом уровне, есть автоматизированное тестирование, которое просто-напросто ускоряет процесс, есть целый набор книг, разных «библий разработки». Да тот же самый Фаулер и вся эта история с архитектурными паттернами — там и про сервисы, и про микросервисы, это применимо и к мобильной разработке. Просто на всех уровнях делаем всё, что позволяет снизить связанность наших компонентов.
Причём, если какие-то технологии появились 20-30 лет назад, это ещё не значит, что они перестали быть актуальными.
Допустим, я так никогда не делал. С чего начать?
Есть простой надёжный подход: делаем из монолита структурированный монолит, потом начинаем обкладывать его микросервисами — и постепенно уходим от связанности.
Я, скорее, про культурный аспект. Это же надо как-то по-другому думать?
Да не надо думать по-другому, все технические решения известны. У нас, например, в запасе уже пару лет лежал инструмент статического анализа кода на проприетарном языке. И в какой-то момент в нём возникла потребность, потому что появилось много некачественного кода внешней команды заказчика. Главное — помнить про ключевые инструменты и по мере необходимости быстро их внедрять.
Добавлю, что где-то в этой истории должны быть евангелисты, которые умеют применять любую технологию, знают, как её внедрить и хотят её применять. Вокруг этих евангелистов должны формироваться профессиональные сообщества, через которые и прививается культура производства.
Итак, у нас есть целый ряд инженерных практик, давно и хорошо известных, которые позволяют нам работать в быстро меняющемся мире. Чтобы их внедрить, нам нужно доверие в команде и некая культура в разработке, которую мы внедряем через профессиональные сообщества.</b>
И вот, смотрите — я программист, интроверт. А вы хотите заставить меня общаться с толпой каких-то людей, понимать бизнес, при этом применять кучу практик, которые дядюшка Фаулер давно описал. Через месяц я выгорю и уйду. Как этого не допустить?
Один из путей — не надо делать всё сразу. В scrum и agile есть представление о full stack feature team — то есть о команде в целом, которая обладает всеми компетенциями, необходимыми для доставки бизнес-ценностей. И вот кто-то в ней не умеет разговаривать с заказчиком. Ну и пусть не умеет, если есть кто-то другой, кто умеет. Задача менеджмента — составлять команду так, чтобы в ней были те, кто умеет и любит говорить, кого от этого не бомбит. Коммуникация, как и любой другой навык, должна быть обеспечена на уровне команды, а не героя-одиночки.
Для тимлида как раз навык коммуникации ведущий, именно поэтому он и нужен.
И здесь добавлю ещё один свежий лайфхак. У команды, чтобы она не выгорала, должны быть проекты-отдушины. Это не обязательно прошлая модель Google, когда я 20% времени вкладываю в какой-нибудь opensource проект, который вообще не нужен компании. Напротив — проект может быть интересен команде, но при этом в нём нет бизнес-бремени, нет завязки на внешнего партнёра. У меня в этом году такой отдушиной стал очень прагматичный, предметный проект по увеличению отказоустойчивости нашего сервиса. Мы решали вполне конкретные инженерные задачи: как увеличить доступность, производительность, перейти на кластеризацию всех модулей и так далее. И это сработало на сто процентов, потому что главное в этой истории — не бизнес, а интерес к собственной профессии. Вот что-то подобное надо искать — что даёт команде психологическую разгрузку.
Итого, чтобы команда не выгорала в бешеном ритме, у нас есть, во-первых, тимлиды и другие «люди-интерфейсы», есть проекты-отдушины, и у нас резко возрастает роль менеджмента в части soft skills: он должен всё мониторить и создавать благоприятную среду.
Да, руководство должно исповедовать servant leadrship — быть поддерживающими менеджерами.
С технарями понятно, но мы забыли про владельцев продуктов. Что меняется в их роли в новом мире?
Как я уже говорил, в долгосрочной перспективе эта роль должна раствориться в компетенциях команды, но сейчас продакты необходимы, от них зависит бизнес. Однако у них есть свои задачи. Так, у нас принято в некоторых подразделениях, что никакой эпик не должен длиться больше двух спринтов (четыре недели). Такой как бы принудительный MVP: как хочешь, но обеспечь. Не умеешь — будет делать другой. Продакт должен отлично оперировать сроками и объёмами, уметь из огромной задачи сделать быстрое решение, которым через 2-4 недели смогут пользоваться клиенты.
Ещё крайне важно, чтобы владельцы продуктов начали воспринимать себя как часть производственной команды. И когда такой момент придёт, команда и продакт станут только эффективнее. Такая коллаборация здорово работает.
Значит, коллаборация, коммуникация, слияние всех видов деятельности в одну команду.
И доверие.
И доверие. Всё это позволит пережить изменения. А как же hard skills?
Про них мы не говорим, потому что они по умолчанию должны быть на очень высоком уровне.
Согласен, это фундамент всего.
Харды — это must have. Иначе переживать изменения будет некому.
Cпасибо за интересную беседу. Что вам дал этот опыт?
Если взглянуть на всё, что мы сейчас нагенерили, может показаться, что ничего особенно оригинального в наших лайфхаках нет — понятные инженерные и менеджерские практики. Но для нас в этой истории было главным принять изменившуюся реальность как можно раньше. Нет смысла искать способы защиты от турбулентности бэклога и нестабильности требований. Незачем жаловаться на дождь и мокнуть под дождём — просто откройте зонт. Возьмите всё лучшее, что разрабатывалось в управлении ИТ за последние 20 лет и примените это. Тогда у вас будут и темпы производства, и стабильность кадров, и гибкость команд, и новые продукты, востребованные в новом мире.