Русский
Русский
English
Статистика
Реклама

DreamTeam в эпоху быстрых перемен

11 лайфхаков менеджерам IT-команд, которые стремятся обеспечить жизнеспособность и развитие своего бизнеса в условиях безумных скоростей и неопределённости


В апреле 2020 года Группа компаний ЦФТ, один из крупнейших российских финтех-провайдеров, поставляющий ИТ-продукты и услуги более чем 300 банкам и миллионам жителей из десятков стран, смогла перевести на удалённую работу 3000+ своих сотрудников, при этом не потеряв в управляемости, производительности и динамике финансовых показателей. Это лишь одно из действий в большом плане переналадки бизнеса в связи с приходом пандемии.

Но важно даже не это. Ситуация с ковидом подсветила мировые тенденции последних цати лет, которые заключаются в необходимости быстро меняться, перестраивать процессы, выводить на рынок новые продукты. И на нашей очередной встрече с менеджерами и техническими директорами ЦФТ зашел разговор, как командам удаётся сохранять работоспособность в таких условиях.



Краткое руководство от команды ЦФТ по выживанию и развитию в 2020 году вышло таким:

  1. Информация в организации должна распространяться мгновенно. Это должно стать культурой компании и поддерживаться на всех уровнях: от ТОПов до линейных менеджеров. Хороши все средства коммуникаций, и каждая команда может следовать собственным предпочтениям.
  2. Больше невозможно опираться на долгосрочные планы и подробные ТЗ работаем с колёс.
  3. От бизнес-идеи до реализации в продукте должно проходить 2-4 недели. Это прежде всего ответственность владельца продукта, который разбивает большие задачи на отдельно поставляемые ценности. Лучше быстрее создать прототип и внедрить его, а правильную реализацию сделать позднее.
  4. Заказчик находится внутри команды и на постоянной связи с ней: он в любой момент готов ответить на вопрос команды и оценить сделанную работу.
  5. Управление имеет плоскую структуру: иерархические подчинения не мешают быстрому принятию решений.
  6. В каждой команде есть несколько человек, которые умеют и любят говорить с заказчиком на одном языке. Такая деятельность закрепляется не должностью, а ролью.
  7. Нужны технические евангелисты, которые по мере необходимости внедряют лучшие инженерные практики и развивают культуру производства через профессиональные сообщества.
  8. Людям в команде позволяют ошибаться, их профессиональному мнению доверяют и пытаются понять их позицию.
  9. Команда более устойчива к выгоранию, если у нее есть время на проекты-отдушины, напрямую связанные с развитием собственных технологий и продуктов, но не обременённые давлением со стороны бизнеса.
  10. Руководство должно исповедовать servant leadership быть поддерживающими менеджерами.
  11. Hard skills должны оставаться на очень высоком уровне это фундамент всей работы.

И если вам стало ясно, что всё ещё ничего не ясно, то теперь вы можете обстоятельно углубиться в подробности.

Участники разговора:

Олег Бунин: Все мы уже знаем, в каком мире теперь живём, и остаётся понять самую малость: как именно нам жить в этом мире. Весной 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 лет и примените это. Тогда у вас будут и темпы производства, и стабильность кадров, и гибкость команд, и новые продукты, востребованные в новом мире.
Источник: habr.com
К списку статей
Опубликовано: 29.10.2020 14:07:14
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Блог компании конференции олега бунина (онтико)

Управление разработкой

Управление проектами

Управление продуктом

Управление персоналом

Управление командой

Управление людьми

Менеджмент продукта

Менеджмент

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru