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