В чем проблемы роста, кроме очевидных, когда из 15 человек становится 80, а одна команда вырастает в 10? Почему разработчики начинают дистанцироваться от пользователей и перестают чувствовать их боль? Как им не выпасть из коммуникационных процессов? Я Дмитрий Шаронов, и я расскажу вам, как мы в Tarantool преодолели трудности роста и попытались избежать разделения между разработчиками при переходе от open source к Enterprise. Какие решения использовались, почему привлекли новичков и стажеров.
Мы выявили 4 проблемы коммуникации в быстро растущей команде и унифицировали для этого инструменты.
Это стенограмма доклада, читать я на TeamLeadConf 2021. Видео доклада можно посмотреть здесь .
Как технологии Tarantool 10–12 лет, но бизнес на ней начали делать всего 4 года назад. Теперь это не просто технология, которую Mail.ru сделала открытым исходным кодом.
Хотя даже open source можно проконсультировать, внедрить и решить задачи банков, телекомов и других крупных клиентов «под ключ».
Tarantool — это бизнес-подразделение в составе Mail.ru Group, у нас есть свои P&L (прибыли и убытки), мы пытаемся зарабатывать.
В чем-то мы конкурируем с Redis, когда речь идет больше об in-memory и кэшах, а в чем-то с Ignite, GridGain, Hazelcast и другими решениями класса Data Grid, где нужно выполнять сложные вычисления в памяти.
Если 5 лет назад над технологией open source, ядром базы данных и сервером приложений работало 15 системных программистов, то сейчас в Tarantool около ста человек, и почти все они — инженеры, или менеджеры выросших из них инженеров.
Растущая боль
При переходе от open source к бизнесу у нас начались боли роста, это наложилось на свою специфику и появилось разделение на «физиков» и «лириков».Даже в идеальной ситуации, когда все со всеми дружат и все делают, у людей есть психологическая склонность.
Разработчики не являются исключением.
Для некоторых важнее, насколько легко принести нам запрос на извлечение извне и сколько людей у нас в сообществе.
Для других — насколько хорошо мы решаем проблемы клиентов; Такие люди обеспокоены тем, что если они опубликуют ненужные данные в каком-нибудь отчете об ошибке на GitHub, он попадет под NDA и кто-то обратится в суд. Эти люди не любят друг друга.
Как бы вы ни старались, этот антагонизм будет присутствовать.
Его можно только сгладить.
Техническая поддержка
Помимо системных программистов, у нас сначала были люди, которые занимаются окружающей нас экосистемой — еще немного прикладным программированием и прикладными модулями.Потом появились инженеры по эксплуатации и доставке, которые внедряют и настраивают под заказчика.
Под самый конец появилась техподдержка с человеческим лицом — люди, основная способность которых — думать о пользователе, отвечать на его вопросы и во всем разбираться вместе с ним.
Если пройти все уровни, то переходы будут постепенными, но лучше всего это видно с конца.
У техподдержки другие требования к инструментам, включая трекеры задач.
Их не устраивают проблемы с GitHub, потому что они не могут настроить, например, контроль SLA и уведомления о проблемах, оставшихся без ответа.
Они привыкли к классическим инструментам поддержки B2C и менеджерам по обслуживанию.
Там намного больше кода
Мы не просто делаем какое-то приложение, мы делаем программное обеспечение, и его становится все больше и больше.Пока у нас был открытый исходный код, можно было полагаться на модули сообщества и распространять модули с открытым исходным кодом.
Оно работало и работает до сих пор, но в бизнес это не перетащишь.
Если мы продаем лицензию или поддержку (даже с открытым исходным кодом), мы должны гарантировать, что проанализируем ошибку в этом модуле, исправим и построим новые дистрибутивы.
Мы не закрываем старые модули, они по-прежнему находятся под той же лицензией, но мы обязаны контролировать и гарантировать, что сможем скомпилировать новую версию и поставить исправление в любой момент. Плюс количество проектов увеличилось, общие части в них выделены как разработки и модули, они выложены на GitHub, и за всем этим нужно следить.
Если 5 лет назад было 5 репозиториев, которые поддерживались командой, и 15, которые поддерживались сообществом, то сейчас на GitHub 300 репозиториев, 50 из которых мы поддерживаем как продуктовые и принимаем для них ошибки от наших клиентов.
Вместо 500 незакрытых билетов осталось почти 5000 и все, что работало раньше, уже не работает. Мне кажется, наша команда со стороны пользователя похожа на луковицу.
В самом ее центре находятся системные программисты, создающие ядро базы данных, за ними следуют разработчики экосистемы и коммерческих модулей, за ними следуют полевые инженеры.
А снаружи есть люди, которые берут на себя гнев пользователей, когда что-то не работает, поэтому они быстро сгорают, как сухая чешуя на луковице.
Наша задача – сделать так, чтобы лук остался свежим и сочным, его серединка не сгнила раньше времени, а то, что снаружи, не пересохло и не подгорело.
Проблема №1
Те, кто ближе к центру луковицы, начинают забывать о проблемах пользователей.Хотя раньше они были системными программистами, их команда напрямую взаимодействовала с пользователями.
В ситуации большого бизнеса о них забывают и перестают чувствовать их боль.
Способ борьбы с этой проблемой в основном организационный – люди важнее процессов, а процессы важнее инструментов.
Организационные методы включают в себя ротацию людей между командами, культуру post-mortems, то есть культуру красивого рассказа о том, что с клиентом не так.
Это канал информации снаружи внутрь.
Но есть и технические, инструментальные решения.
Самый важный из них — трекер инцидентов.
Самая распространенная ошибка техподдержки – поддержка сидит в сервис-менеджере и варится в своих обращениях, боль копится в сервис-менеджере, а другие туда не идут. Потому что нужно отдельно зайти и настроить права.
Поэтому вся команда должна иметь легкий доступ к трекеру инцидентов, желательно с переходами из других инструментов.
Проблема №2
При переходе от open source к бизнесу пользователи тоже поменялись, но разделение между ними еще строже, чем между разработчиками.При этом если мы за время выросли в 4 раза, то количество пользователей увеличилось в 10 раз.
Крупнейшими антагонистическими группами, требующими разных подходов, являются пользователи открытого исходного кода и представители корпоративных компаний.
Они задают разные вопросы и имеют разные ожидания от программного обеспечения.
Пользователь открытого исходного кода спрашивает, какие флаги поставить при компиляции, чтобы все скомпилировалось под его любимый дистрибутив BSD. А корпоративный пользователь хочет знать, как интегрироваться в самую старую версию IBM Q, в которой нет того и этого, не работает авторизация, некоторые модули не подходят. Но если разделить разработчиков, занимающихся проблемами разных групп пользователей, они начнут тянуть одеяло на себя.
Если опенсорс-разработчики тянут одеяло на себя, мы выкладываем все в опенсорс, а потом обнаруживаем, что зарабатывать нечем и новые ставки брать неоткуда.
Если предприятия выпускают все лучшее только в закрытом издании, то этим пользуется в разы меньше людей, мы собираем мало отзывов и итоговое качество ниже.
Поэтому лучше не отделять корпоративных разработчиков от разработчиков открытого исходного кода, а разделить разные фичи между командами через функциональные переключатели или дать одной команде несколько модулей, некоторые из которых открыты, а другие закрыты, но собираются и распределяются по общим узоры.
В этом случае разработчики запомнят обо всех пользователях.
Проблема №3
Если сначала вся команда Tarantool сидела в одном чате и чувствовала общее плечо.Постепенно количество чатов перевалило за сотню, но во всех 100 чатах одновременно никого не было.
Информация в чатах плохо распространялась и кто-то обязательно что-то упускал.
Например, сегодня пользователь задает вопрос в клиентском чате, но на него никто не отвечает. Но даже если он ответит, и завтра другой пользователь спросит то же самое в другом чате, то переслать ему вчерашний правильный ответ некому.
Потому что поддержка не только должна быть в обоих чатах одновременно, но и должна догадываться, что ответы одинаковые и их можно использовать повторно.
В отличие от предыдущих задач, где я больше говорил об организационных элементах, здесь чисто техническое решение.
Чат — хороший инструмент для личного контакта с пользователем, но он не позволяет обеспечить тиражируемую поддержку.
Без регистрации запроса не получится, то есть того самого сервис-менеджера и накопленной базы знаний.
К ее решению мы вернемся позже, а пока стоит помнить, что без трекера инцидентов не обойтись, даже если у вас нет выделенной технической поддержки и вы сами отвечаете на все вопросы клиентов.
Проблема №4
Существует множество трекеров задач, трекеров проблем и репозиториев; по каким-то причинам команды могут выбирать разные инструменты.Но с увеличением количества проектов без унифицированных коммуникаций возникают проблемы.
Мы использовали облачный GitHub, потому что самый первый репозиторий Tarantool изначально был размещен там с открытым исходным кодом.
Со временем было открыто 50 репозиториев.
Несколько лет назад у GitHub было ограничение на количество бесплатных частных репозиториев для организаций.
Поэтому по мере роста закрытой части, как коммерческих модулей, так и проектных, мы поняли, что не можем вписаться в GitHub и перешли на GitLab. Нет ограничений по репозиториям и очень удобный CI. 
Мы сами не заметили, как появилось 200 репозиториев с открытым исходным кодом в GitHub и 200 закрытых коммерческих и проектных репозиториев в GitLab. Тогда задача коммуникации стала особенно острой – каждый должен был быть более или менее в курсе всего.
Для этого человеку необходимо зарегистрироваться и авторизоваться в обоих местах, но одновременно искать проблему в обоих репозиториях он все равно не сможет. Потому что нужно поискать трассировку стека совпадений, посмотреть, не случилось ли что-то подобное с кем-то в сообществе, а затем и в корпоративных клиентах.
Невозможно передать тикет из одного облака в другое и как-то их связать.
Кроме того, такое техническое решение начинает вызывать организационные изменения.
Когда одни люди используют доски GitHub, а другие — GitLab Kanban, они перестают говорить.
Для нас эта проблема решилась сама собой.
Microsoft сняла ограничения на частные репозитории на GitHub. Мы приняли волевое решение, 3 месяца мучились с переносом CI, но все перекочевало на GitHub. Более того, оказалось, что 100 репозиториев устарели, и мы не стали их перемещать.
Итак из 400 репозиториев осталось 300, но теперь их все можно искать в одном интерфейсе.
Теперь перейдем от проблем к решениям.
Решения
Мы организуем совместную работу пятидесяти человек в десяти командах через GitHub. Он имеет хорошую реализацию репозиториев Git, довольно хорошую систему заявок GitHub и автоматизацию рабочих процессов GitHub Actions. Действия GitHub появились недавно; он позволяет вам выполнять 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 для хранения кода, code review, Continuous Integration, для ведения бэклога, который разбивается на задачи и заносится в задачи GitHub и для командных досок.
Для разных команд они организованы в разных стилях: одни ближе к Канбану, другие — к SCRUM. Мы используем Джира , регистрировать запросы пользователей и следить за соблюдением SLA, то есть как часто мы на них отвечаем и не теряем ли мы их.
Если планируется через месяц, говорим, что да, запланировано, обязательно исправим, но через месяц.
Через месяц должно сходить напоминание о том, что нужно проверить, действительно ли исправление ошибки есть в релизе, и напомнить об этом пользователю.
Мы продолжаем использовать Телеграмма , как основной мессенджер для рабочего общения внутри команды и с пользователями.
Все, чего нам не хватает в интерфейсах между этими инструментами, мы автоматизируем с помощью простых боты .
Открытые вопросы
Чтобы вы не думали, что у нас все идеально, я расскажу вам, какие у нас проблемы.Например, на GitHub нет пространства имен .
То есть вы не можете сделать пространство имен «песочницей», чтобы каждый мог создавать репозитории.
Точно так же вы не можете сделать пространство имен для клиента и дать доступ клиентской команде.
Невозможно выделить пространство имен, например, для всех модулей нашего продукта и сделать так, чтобы к нему не получили доступ лишние люди.
Наши 300 репозиториев расположены в одном плоском пространстве имен.
Конечно, мы приняли правила наименования.
Остальное решается организационно: мы следим за тем, чтобы в нужных группах были нужные люди и у них был доступ к нужным репозиториям.
Еще одна боль «закрытая» Джира.
Посторонних людей нельзя пускать внутрь корпоративной Jira от Mail.ru. Это значит, что к нашему замечательному трекеру инцидентов, о котором я так хорошо рассказал, клиент не может получить доступ и посмотреть, что происходит с его заявкой.
Это убивает идею прямого контакта с пользователем.
На данный момент мы построили диаграмму с двумя Jira. Один внутри Mail.ru, где сидит команда, а второй облачный, где сидят клиенты.
Делаем бота, который будет переносить билеты из одного в другой.
Схема, к сожалению, напоминает слона, который перелезает через забор и носит туда-сюда билеты.
Поэтому с этим могут быть проблемы.
Учитесь на наших ошибках!
Выводы всегда кажутся очевидными, но, возможно, подкрепленные примерами, они будут вам полезны.По мере роста вашего продукта и команды или количества команд обязательно меняйте свои процессы.
Пока у вас есть 2, 5, 10 чатов, все в порядке.
Даже 20 чатов можно использовать, если 80% команды везде сидят и всё пересылают. Но в какой-то момент количество чатов переваливает за 100, и никто не понимает, что происходит. Трудно не упустить этот момент. Поэтому постарайтесь за всем следить, спрашивая себя, использовали ли мы этот инструмент год назад и сколько у нас тогда было людей.
Если ответ отличается менее чем в 2 раза, то, скорее всего, пока все в порядке.
Унифицируйте рабочие инструменты разных команд. Если поместить две команды в разные трекеры, они, естественно, будут меньше общаться друг с другом, решать менее распространенные проблемы и в итоге станут антагонистами.
Наши опенсорсисты были в GitHub, а те, кто занимался коммерцией, — в GitLab. В результате некоторые модули имели по 2 реализации.
Тогда было непонятно, как из них выбрать, какая версия лучше и что делать дальше, чтобы никого не обидеть.
Задачи по повседневной автоматизации небольших инженерных процессов очень хорошо ложатся на новичков и стажеров.
У них меньше нагрузка и меньше требований, что позволяет быстрее проверять процесс.
Затем вы сможете решить, подходит ли вам это изменение процесса или нет, а если нет, начать искать подходящее решение на рынке.
И инвестируйте в улучшение программного обеспечения процессов: небольших ботов и скриптов.
Вы можете узнать больше о Tarantool на официальном сайте и задавать вопросы - в Telegram-чате .Теги: #Управление разработкой #открытый код #tarantool #Управление персоналом #Управление продуктом #коммуникации #автоматизация #управление командой #процессы разработки #процессы в ней #автоматизация рутинной работы #предприятиеВ 2022 году в рамках конференции пройдет конференция TechLead DevOps-конференция 2022 — 9 и 10 июня в Москве, в «Крокус-Экспо».
Вы можете подать заявку на выступление Здесь .
-
История Игрового Рынка, Часть 1
19 Oct, 24 -
Интернет-Цензура. Нужно Что-То Сделать
19 Oct, 24 -
Выбор Смс-Биллинга Для Рутрафа
19 Oct, 24
