Как сохранить тесную коммуникацию в стремительно растущей команде
Какие бывают проблемы роста, кроме очевидных, когда из 15 человек становится 80, а из одной команды вырастает 10? Почему разработчики начинают удаляться от пользователей и перестают чувствовать их боль? Как им не выпадать из коммуникационных процессов?
Я Дмитрий Шаронов, и я расскажу, как мы в Tarantool преодолевали проблемы роста и пытались избежать разделения между разработчиками при переходе из опенсорса в ентерпрайз. Какие решения использовали, зачем привлекали новичков и стажеров. Мы выделили 4 проблемы коммуникации в стремительно растущей команде и унифицировали инструменты для этого.
Это расшифровка доклада, прочитанного мной на TeamLeadConf 2021. Видео доклада можно посмотреть тут.
Как технологии, Tarantool лет 10–12, но бизнес из него начали делать только 4 года назад. Сейчас это не просто технология, которую Mail.ru выложил в опенсорс. Хотя даже опенсорс можно консалтить, внедрять, решать проблемы банков, телекомов и других крупных клиентов под ключ. Tarantool — это бизнес-юнит внутри Mail.ru Group, у нас есть свои P&L (Profit and Loss), мы пытаемся зарабатывать деньги. В каких-то ипостасях мы конкурируем с Redis, когда это больше про in-memory и про кэши, а в каких-то с Ignite, GridGain, Hazelcast и прочими решениями класса Data Grid, где нужно делать сложные вычисления в памяти.
Если 5 лет назад 15 системных программистов делали опенсорс-технологию, ядро БД и сервер приложений, то сейчас в Tarantool под сотню человек, и почти все из них инженеры, либо руководители инженеров, которые из них выросли.
Проблемы роста
При переходе из опенсорса в бизнес у нас начались проблемы роста, на это наложилась своя специфика и появилось разделение между «физиками» и «лириками». Даже в идеальной ситуации, когда все со всеми дружат и занимаются всем, у людей видна психологическая склонность. Разработчики не исключение. Кому-то важнее насколько просто принести к нам pull request со стороны и как много людей у нас в комьюнити. Другим — насколько мы хорошо решаем задачи клиентов; такие люди переживают, что выложат лишние данные по какому-то баг-репорту на GitHub, это подпадет под NDA и кто-то пойдёт под суд. Эти люди друг друга недолюбливают. Как ни старайся, этот антагонизм будет присутствовать. Его можно только сглаживать.
Техническая поддержка
Кроме системных программистов у нас сначала появились люди, которые занимаются экосистемой вокруг — чуть больше прикладным программированием и прикладными модулями. Потом появились field и delivery инженеры, которые это внедряют и кастомят под заказчика. Под самый финал появилась техподдержка с человеческим лицом — люди, у которых первостепенный скилл — думать о пользователе, отвечать на его вопросы и вместе с ним разбираться.
Если пройти по всем уровням, переходы будут постепенные, но с конца видно лучше всего. У техподдержки другие требования к инструментам, в том числе к таск-трекерам. Их не устраивает GitHub issues потому, что они не могут настроить, например, контроль SLA и нотификации на неотвеченные вопросы. Они привыкли к инструментам классической B2C поддержки и сервис-менеджерам.
Стало гораздо больше кода
Мы не просто делаем какое-то приложение, мы делаем софт, и его становится все больше. Пока мы были опенсорсом, можно было опираться на модули из комьюнити и раздавать опенсорсные модули. Это работало и все еще работает, но это нельзя перетащить в бизнес. Если мы продаем лицензию или саппорт (даже на опенсорс) мы должны гарантировать, что разберем баг в этом модуле, внесем фикс и соберем новые дистрибутивы. Мы не закрываем старые модули, они по-прежнему под той же самой лицензией, но мы обязаны контролировать и гарантировать, что можем в любой момент собрать новую версию и доставить фикс.
Плюс к этому, увеличилось количество проектов, общие части в них выделились как наработки и модули, их выложили на GitHub, и за всем этим нужно следить. Где 5 лет назад было 5 репозиториев, которые поддерживала команда, и 15, которые поддерживало комьюнити, сейчас стало 300 репозиториев на GitHub, 50 из которых мы поддерживаем как продуктовые и принимаем на них баги от наших клиентов. Вместо 500 незакрытых тикетов, стало под 5000 и всё, что работало раньше больше не работает.
Мне кажется, что наша команда со стороны пользователей похожа на луковицу. В самом её центре находятся системные программисты, которые делают ядро БД, дальше идут разработчики экосистемы и коммерческих модулей, за ними field-инженеры. А снаружи люди, которые принимают на себя гнев пользователей, когда что-то не работает, поэтому они быстро выгорают, как сухие чешуи у луковицы.
Наша задача в том, чтобы луковица оставалась свежей и сочной, ее центр не гнил раньше времени, а то, что снаружи, не пересыхало и не перегорало.
Проблема №1
Те, кто находятся ближе к центру луковицы, начинают забывать про проблемы пользователей. Несмотря на то, что они и раньше были системными программистами, они непосредственно взаимодействовали своей командой с пользователями. В ситуации большого бизнеса они про них забывают и перестают чувствовать их боль.
Способы борьбы с этой проблемой в основном организационные — люди важнее, чем процессы, а процессы важнее, чем инструменты. Организационные способы — это ротация людей между командами, культура постмортемов, то есть культура красиво рассказывать, что у клиента идет не так. Это канал информации снаружи внутрь.
Но есть и технические, инструментальные решения. Самое важное из них — это инцидент-трекер.
Самая распространенная ошибка техсаппорта в том, что поддержка сидит в сервис-менеджере и варится в своих заявках, в сервис-менеджере копится боль, но другие туда не ходят. Потому что надо отдельно логиниться и настраивать права. Поэтому легкий доступ к инцидент-трекеру, желательно с переходами из остальных инструментов, должен быть у всей команды.
Проблема №2
При переходе из опенсорса в бизнес поменялись и пользователи, но разделение между ними еще жестче, чем между разработчиками. Более того, если мы со временем выросли в 4 раза, то количество пользователей увеличилось в 10 раз.
Самые крупные антагонистические группы, которые требуют разных подходов — это пользователи опенсорса и те, что пришли из энтерпрайз-компаний. Они задают разные вопросы и у них разные ожидания от софта. Опенсорс-пользователь спрашивает, какие флаги поставить в компиляции, чтобы все собралось под его любимый BSD-дистрибутив. А энтерпрайз-пользователь хочет знать, как интегрироваться в древнейшую версию IBM Q, в которой нет того и сего, авторизация не работает, какие-то модули не подходят.
Но если разделить разработчиков, которые занимаются проблемами разных групп пользователей, они начнут тянуть одеяло на себя. Если опенсорсники перетягивают одеяло на себя, мы всё выкладываем в опенсорс, а потом выясняем, что деньги зарабатывать нечем и новые ставки брать неоткуда. Если энтерпрайзники выпускают все самое лучшее только в закрытой редакции, то этим пользуется в разы меньше людей, мы собираем мало фидбэка и итоговое качество получается ниже.
Поэтому лучше не отделяйте разработчиков энтерпрайз от разработчиков опенсорса, а делите разные фичи между командами через фиче-тогглы (feature toggle) или давайте одной команде по несколько модулей, часть из которых открыта, а другие закрыты, но собираются и дистрибьютятся по общим лекалам. В таком случае разработчики будут помнить про всех пользователей.
Проблема №3
Если сначала вся команда Tarantool сидела в одном чате и чувствовала общее плечо. Постепенно количество чатов перевалило за сто, но никто не сидел одновременно во всех 100 чатах. Информация по чатам плохо шарилась и кто-то что-то обязательно пропускал. Например, сегодня пользователь задает в клиентском чате вопрос, а на него никто не отвечает. Но даже если отвечает, а завтра другой пользователь спрашивают в другом чате то же самое, то некому переправить ему вчерашний правильный ответ. Потому что саппорт не только должен одновременно сидеть в обоих чатах, но еще и догадаться, что ответы одинаковые и их можно повторно использовать.
В отличие от предыдущих проблем, где я больше говорил про организационные элементы, здесь — чисто техническое решение. Чат — это хороший инструмент для личного контакта с пользователем, но он не позволяет сделать тиражируемую поддержку. Она не получится без регистрации обращения, то есть того самого сервис-менеджера и накапливаемой базы знаний. К её решению вернёмся позже, а пока стоит запомнить, что без инцидент-трекера не обойтись, даже если у вас нет выделенной техподдержки и вы сами отвечаете на все вопросы клиентов.
Проблема №4
Такс-трекеров, issue-трекеров и репозиториев много, команды могут по каким-то причинам выбирать разные инструменты. Но при увеличении количества проектов без унификации коммуникаций возникают проблемы. Мы использовали облачный GitHub потому, что туда изначально выложили как опенсорс самый первый репозиторий Tarantool. Со временем стало 50 открытых репозиториев. Несколько лет назад на GitHub было ограничение на число бесплатных закрытых репозиториев для организаций. Поэтому по мере роста закрытой части, как коммерческих модулей, так и проектной, мы поняли, что не влезаем в GitHub и пошли в GitLab. Там нет ограничений на репозитории и очень удобный CI.
Мы сами не заметили, как в GitHub оказалось 200 опенсорсных репозиториев и в GitLab тоже 200 закрытых коммерческих и проектных репозиториев. Тогда особенно остро встала коммуникационная задача — все должны быть обо всём более или менее осведомлены. Для этого нужно, чтобы человек был и там и там зарегистрирован и залогинен, но он все равно не сможет одновременно искать проблему в обоих хранилищах. Потому что надо искать стек-трейс совпадений, смотреть, произошло ли что-то подобное у кого-нибудь в комьюнити, а потом в энтерпрайз-клиентах. Невозможно сослаться из тикета одного облака в другом и как-то увязать их. Помимо этого такое техническое решение начинает вызывать организационные изменения. Когда одни люди пользуются GitHub досками, а другие GitLab Канбаном, они перестают разговаривать.
У нас эта проблема решилась сама собой. Microsoft отменил ограничения на закрытые репозитории на GitHub. Мы приняли волевое решение, 3 месяца мучились с перевозом CI, но все мигрировали в GitHub. Более того, при этом выяснилось, что 100 репозиториев устарели, и мы не стали их переносить. Так из 400 репозиториев осталось 300, но теперь по всем ним можно искать в одном интерфейсе.
Теперь от проблем перейдем к решениям.
Решения
Мы организуем через GitHub совместную работу полусотни человек в десятке команд. У него хорошая имплементация Git-репозиториев, достаточно хорошая тикетница GitHub issues и автоматизация рабочих процессов GitHub Actions.
GitHub Actions появился недавно, он позволяет стандартно делать CI на GitHub. У него простая и понятная схема: если у вас опенсорс, пользуйтесь облачными раннерами бесплатно, если у вас закрытый репозиторий, либо платите за квоты на использование раннеров, либо поднимайте и используйте собственные.
У GitHub хорошая ролевая модель доступа. Можно настроить разные команды, разные доступы, разные группы. Мы можем организовывать внутренние команды, добавить контрактеров и завести клиентов с ограниченным доступом к 2–3 репозиториям.
А благодаря тому, что сервис облачный, у нас не болит голова как его хостить и обновлять. И падает он реже, чем GitLab.
Для инцидент-трекера и саппорт-трекера мы перебрали множество вариантов. Даже сделали собственный простенький саппорт-трекер. Взяли стажера, дали ему Python, Heroku, Postgres, Telegram API для написания бота. Бот умел создавать тикеты, сохранять их в Postgres, дописывать туда истории с чата и закрывать эти тикеты, но закрыть все задачи не смог. Зато мы поняли, что нам нужно для инцидент-трекера. Стали пробовать другие альтернативы от Zendesk до ZenHub, но параллельно пытались сделать все это на Jira. Базовая Jira сама по себе не очень сложная. В ней можно настроить плагины SLA и базовые счетчики на то, что тикет лежит неотвеченным столько-то времени. Поэтому мы решили использовать корпоративную Mail.ru Jira.
Можно было использовать облачную Jira, но тогда всем бы пришлось в ней регистрироваться и удаляться. Она тоже подтормаживает, правда туда можно пускать внешних людей. Но с Jira от Mail.ru мы автоматом имеем Active Directory и права доступа на всю команду без необходимости лишний раз логиниться. Например. я делаю рассылку на команду о том, что есть неотвеченные тикеты. Люди, которые могут помочь, кликают на ссылку, а их там просят зарегистрироваться. Скорее всего, они этого не сделают. Поэтому легкий доступ очень важен для снижения порога входа в инструменты смежных команд.
Я уже говорил про ботов. Почти у всех разработческих инструментов есть API. Поэтому если у вас маленькая команда, все занимаются всем и вы не можете заливать проблемы деньгами, автоматизируйте, берите джунов и стажеров, для них это будет интересно, и связывайте вендорские и облачные инструменты друг с другом через API.
Самописный саппорт-бот у нас не нашел применения, но бот, который связывает Telegram-чаты с корпоративной Jira оказался идеальным решением. Пользователи понимают, что им вживую отвечают в чате, а мы, если не можем быстро ответить на вопрос, в один клик переводим его в Jira, где на него обязательно кто-нибудь ответит. Все это достижимо собственными силами с учетом вашей специфики под ваши процессы.
К чему мы пришли?
Обзор инструментов
Получается, что мы используем мало инструментов, и я считаю, что это преимущество. Чем больше инструментов человеку надо освоить, тем меньше вероятность, что он все их освоит, и тем больше вероятность, что он начнет выпадать из каких-то коммуникационных процессов.
Мы пользуемся GitHub для хранения кода, код-ревью, Continuous Integration, для ведения бэклога, который разбит на задачи и заведен в GitHub issues и для командных досок. Они организованы в разном стиле под разные команды: одни ближе к Канбану, другие к SCRUM.
Мы пользуемся Jira, чтобы регистрировать обращения пользователей и следить за SLA, то есть как часто мы на них отвечаем, не теряем ли. Если запланировали через месяц, говорим, что да, запланировано, обязательно пофиксим, но через месяц. Через месяц должна сработать напоминалка о том, что нужно проверить, правда ли баг-фикс пошел в релиз и напомнить об этом пользователю.
Мы продолжаем пользоваться Telegram, как основным мессенджером для рабочего общения внутри команды и с пользователями.
Все, чего нам не хватает на стыках между этими инструментами, мы автоматизируем простенькими ботами.
Открытые проблемы
Чтобы вам не казалось, что у нас все идеально, расскажу, какие у нас есть проблемы. Например, в GitHub нет namespace. То есть нельзя сделать namespace «sandbox» для того, чтобы кто хочет мог создавать репозитории. Точно также нельзя сделать namespace под клиента и выдать клиентской команде доступ. Нельзя выделить namespace, допустим, под все наши продуктовые модули и следить, чтобы в него не получали доступ лишние люди.
Наши 300 репозиториев лежат в одном плоском namespace. Конечно, мы приняли правила именования. Остальное решается организационно: отслеживаем, чтобы в нужных группах были нужные люди и у них был доступ к нужным репозиториям.
Другая боль — «закрытая» Jira. Внутрь корпоративной Jira от Mail.ru нельзя пускать внешних людей. Это значит, что в наш прекрасный инцидент-трекер, про который я так вкусно рассказывал, не может зайти клиент и посмотреть, что там с его тикетом. Это убивает идею прямого контакта с пользователем.
Пока мы построили схему с двумя Jira. Одна внутри Mail.ru, в которой сидит команда, а вторая облачная, где сидят клиенты. Мы делаем бота, который будет перекладывать тикеты из одной в другую. Схема, к сожалению, напоминает слона, который лезет через забор и носит тикеты туда-обратно. Поэтому, возможно, с этим будут проблемы.
Учитесь на наших ошибках!
Выводы всегда кажутся очевидными, но, возможно, подкрепленные примерами, они будут вам полезны.
По мере роста продукта и команды или числа команд обязательно меняйте процессы. Пока у вас 2, 5, 10 чатов — все хорошо. Даже 20 чатами можно пользоваться, если 80% команды сидит везде и всё форвардит. Но в какой-то момент количество чатов переходит за 100, и уже никто не понимает, что происходит. Этот момент сложно не упустить. Поэтому старайтесь все отслеживать, задавая себе вопросы, пользовались ли мы этим инструментом год назад и сколько у нас было тогда людей. Если ответ отличается меньше, чем в 2 раза, то, скорее всего, всё пока нормально.
Унифицируйте инструментарий работы разных команд. Если вы посадили две команды в разные трекеры, они естественным образом будут меньше общаться друг с другом, меньше решать общие задачи, и в итоге станут антагонистами. Наши опенсорсники сидели в GitHub, а те кто занимался коммерцией — в GitLab. В итоге у некоторых модулей появилось по 2 реализации. Потом было непонятно как из них выбирать, какая версия лучше и что делать дальше, чтобы никого не обидеть.
Задачи по повседневной автоматизации мелких инженерных процессов очень хорошо ложатся на новичков и стажеров. На них меньше нагрузки и меньше требований, что позволяет быстрее проверять процессные вещи. Потом можно решить, подойдет вам такое изменение процесса или нет, и если нет, начать искать подходящее решение на рынке. И вкладывайтесь в доработку процессного софта: мелких ботов и скриптов.
Узнать больше про Tarantool можно на официальном сайте, а задать вопросы — в Telegram-чате.
В 2022 году конференция TechLead пройдет в рамках конференции DevOps Conf 2022 — 9 и 10 июня в Москве, в Крокус-Экспо. Подать заявку на выступление вы можете здесь.
