Правда ли, что разработка в B2B и B2C — это совершенно два разных мира? Многие разработчики считают, что в B2B:
медленная и неповоротливая разработка;
используются технологии 10-летней давности;
мало возможностей для профессионального развития;
нужно постоянно писать кучу ненужных документов;
приходится делать продукт только для клиента и сложно увидеть результат своей деятельности.
На самом деле нет. Можно организовать разработку в B2B так, чтобы было интересно работать, быстро принимать решения и постоянно развивать свои навыки.
Я Дмитрий Лазаренко, директор по продуктам облачной платформы Mail.ru Cloud Solutions (MCS). Наша компания — B2B-проект, который вырос из стартапа внутри большой группы компаний.
Расскажу о том, как у нас организованы процессы, вместе с нашими разработчиками: руководителем разработки MCS Михаилом Кебичем, руководителем разработки IAM и Hotbox Викторией Сусловой, старшим программистом команды разработки PaaS Азатом Хадиевым.
Как сделать, чтобы для разработчиков не было разницы между B2B и B2C
Есть мнение, что программистам в B2B-разработке плохо живется. Приходится работать с древними технологиями, общаться с нудными заказчиками и дорабатывать какие-то старые админки.
У нас все не так. Облачная платформа — это технологически сложный и разнообразный проект, который должен идти в ногу со временем, и для легаси тут просто нет места. Нам приходится использовать самые последние технологии и методологии для того, чтобы выпускать сервисы быстрее конкурентов, более удобно их эксплуатировать и траблшутить. Безусловно, у нас нет такого количества пользователей как в популярных B2C-проектах, но зато нагрузка, которую они создают зачастую превышает нагрузку многих B2C-сервисов.
У нас есть два типа платформы: публичная на сайте mcs.mail.ru и приватные инсталляции, когда мы разворачиваем платформу для заказчика на его оборудовании. Но даже в приватных инсталляциях нет избыточно формализованного документооборота и прочих ненужных вещей, которые мешают быстро работать и принимать решения.
Азат Хадиев, старший программист команды разработки PaaS: Нельзя сказать, что мы работаем только в B2B, это скорее что-то среднее между B2B и B2C. В чистом B2B нужно тесно общаться с заказчиком и очень формально документировать проект. Нужно все заранее заложить в ТЗ, любое отклонение от него довольно болезненно, требует долгого и непростого согласования с обеих сторон. А в B2C нет таких жестких формальностей и бюрократизированного документооборота, разрабатывать принято в виде постоянного потока изменений, особенно в последние годы.
С одной стороны, мы B2B, потому что в основном работаем с корпоративными клиентами, хоть и без излишней бюрократии. Иногда новая функциональность появляется по их запросам, но потом она все равно становится доступна всем в публичном облаке. Но с точки зрения разработки мы ближе к B2C, потому что у нас частые и мелкие доработки, которые мы постоянно выкатываем в продакшен. В отличие от B2B разработки, где релизный цикл обычно минимум 3 месяца, мы релизимся как минимум каждые 2 недели.
Виктория Суслова, руководитель разработки IAM и Hotbox: Я не знаю, откуда берется это разделение — разработка B2B или B2C. Для меня важнее то, что я делаю нужный продукт, который не стоит на месте и полезен людям. А это может быть как в B2B, так и в B2C. Если компания пришла с заказом, значит, он действительно ей нужен и результатом будут пользоваться. Удовлетворить потребности большой компании интереснее, чем нескольких отдельных человек. Ведь реализация «хотелок» отдельных пользователей может оказаться работой в стол.
Кроме того, общаясь с большим количеством крупных заказчиков, наши разработчики расширяют свои представления о современных инструментах и процессах разработки, которые применяются в ведущих российских и международных компаниях и зачастую начинают внедрять удобные практики в свою повседневную работу. Приватные инсталляции — это отдельный челлендж. По большей части в том, как привнести и совместить фичи публичного облака и приватного. С заказчиками мы общаемся без лишних формальностей, это приятные и адекватные люди.
Решения принимают разработчики, а не CIO
MCS начинался с небольшой команды из нескольких технических специалистов. Тогда это был стартап: брали идею сервиса, показывали его пользователям и смотрели, что из этого выйдет. Все решения по развитию сервисов команда принимала сообща, и не было одного человека, который решал за всех, что нужно делать. В таком режиме MVP запустили Marketplace, Kubernetes ааS, DBaaS.
Сейчас проект вырос, сервисов стало больше, на многие из них наши клиенты полностью полагаются. Поэтому мы используем более зрелый подход, не можем позволить себе даунтайм, все решения должны быть проверенными и стабильными. Несмотря на это, мы стараемся сохранить быстроту принятия решения и реализации.
Масштабирование команды поставило вопрос о том, в какой точке принимаются ключевые решения. Можно было бы централизованно принимать ключевые решения через общую команду архитекторов, и, в принципе, это хороший вариант. Но это заведомо создает бутылочное горлышко в прогрессе проектов, которые замкнуты на одного или нескольких людей.
Мы пошли по другому пути: сделать так, чтобы решения могли приниматься в командах, и свести к минимуму все возникающие от этого сложности. Главное, что это дает, — отсутствие узкого места в принятии решений. Кроме того, команды и сотрудники учатся на всех уровнях брать ответственность на себя. В итоге, как и раньше, каждая команда ведет и полностью отвечает за свой сервис. Задачи по его развитию команда получает в виде заданных требований и ограничений, но решения по их реализации принимает внутри себя самостоятельно. Это помогает быстро принимать решения, добавлять функциональности небольшими порциями и быстрее выводить их на рынок. Например, таким образом у нас в Kubernetes появились Autoscaling и поддержка CSI. Команды сами оценили возможность реализации, приняли решение и выпустили функциональность.
Михаил Кебич, руководитель разработки MCS: С каждой командой работает Product Manager, который ведет сервис как продукт. Он знает желания и потребности клиентов. Команда разработки, со своей стороны, знает, как устроен сервис изнутри, его возможности и технические ограничения. На основе этих знаний постоянно происходит диалог между PM и технической командой, они вместе решают, что нужно делать, как и когда. Получается, что разработчики имеют представление о потребностях клиентов, а PM — о технических деталях, они говорят на одном языке, у них большое поле для совместного принятия решений. Такой подход дает возможность делать то, что нужно именно сейчас, без ущерба в технике или продукте.
Виктория Суслова, руководитель разработки IAM и Hotbox: Наши команды погружены в мир клиентов и их потребностей. Каждый из нас знает, какую пользу клиентам несет его работа, даже если это самый маленький скриптик. Поэтому принимать решения внутри команды — это для нас довольно просто.
Азат Хадиев, старший программист команды разработки PaaS: Добавлю, что по сравнению с централизованным развитием продукта в таком подходе есть определенные недостатки.
Например, какие-то мелкие вещи мы можем делать дважды, трижды в разных командах. Вместо того чтобы объединить функционал в общую библиотеку, каждая команда делает его самостоятельно. Иногда это может дать осечку при интеграции сервисов. Хотя общие точки соприкосновения мы отрабатываем командами совместно, иногда что-то может пойти не так. Какой-нибудь нюанс сервиса, который другая команда попросту не знает.
Возможно, как раз для таких случаев не хватает глобальных архитекторов, которые могут это все сразу предвидеть.
Как вовлеченность разработчиков влияет на финальный продукт
В наших командах специалисты вовлечены в продукт, а не только в процесс его создания. Они знают, куда продукт движется, какие есть потребности у клиентов и что еще можно улучшить. У нас редко бывают задачи, которые можно делать без оглядки на финальный продукт и пользователей. Большинство задач разработчики получают в виде ясного результата для продукта: добавить или оптимизировать функциональность, сделать удобней и понятней. Даже когда мы делаем чисто технические решения, которые не видны пользователям, результаты все равно отслеживаем через мониторинг и метрики.
Команда постоянно совещается: как будет удобнее для пользователей, что можно еще улучшить. Продукту уделяется много времени, и нужно знать, как им пользуются клиенты и чего они хотят. Поэтому разработчики довольно плотно общаются с технической поддержкой, получают заявки от пользователей, по которым видны вопросы и пожелания клиентов.
Такой подход позволяет передать больше ответственности непосредственно командам разработки, и они становятся более самостоятельными в принятии решений. Команда сама может оценить важность каждой задачи и принимать решения. Например, она может решить, что сейчас важнее сделать определенную техническую задачу, улучшающую observability и облегчающую траблшутинг, а не продуктовую.
Как избежать авралов и дать возможность разработчикам проявить себя
Мы используем Agile и двухнедельные спринты, по которым живут даже продажи, дизайн и маркетинг. Все основные задачи мы планируем на квартал вперед и не берем на себя срочных обязательств по разработке сложной функциональности. Сначала мы выпускаем и тестируем новые фичи, а потом уже объявляем о них публично.
Иногда бывает срочная внеплановая работа, которую нужно сделать за несколько часов. Но это редкость, в таком режиме мы правим только критичные ошибки. На любые внеплановые доработки, даже очень важные, есть как минимум несколько недель.
Виктория Суслова, руководитель разработки IAM и Hotbox: Срочная работа заставляет сойти с привычного пути, мозг начинает работать немного по-другому. То, на что в обычном режиме потратили бы месяц, сейчас нужно сделать за две недели. Это непросто, но зато потом получаешь удовлетворение от осознания того, что не каждый смог бы с этим справиться, а наша команда смогла.
Все задачи запланированы и в целом фронт работ известен, но это не означает, что все скучно и банально. Разработчики регулярно сталкиваются с нетривиальными задачами и челленджами.
Михаил Кебич, руководитель разработки MCS: У нас был один очень интересный челлендж. К нам обратился клиент, у которого в период пандемии резко выросла нагрузка, с которой он не мог справиться сам. Мобильное приложение превышало лимиты запросов к нашему хранилищу в несколько раз и медленно работало. Решение нужно было найти быстро, потому что нагрузка росла каждый день. К задаче подключились несколько команд разработчиков и администраторов. Все вместе мы обсуждали проблему, предлагали идеи и проверяли их, спорили и договаривались.
Клиент обратился к нам в пятницу вечером, когда его уже никто не хотел консультировать. В тот день мы работали до полуночи и потом еще все выходные. Но в итоге за 2–3 дня нашли решение, которое позволило клиенту правильно распределить свою нагрузку. Также мы улучшили и свое решение: сильно покопались во внутренностях nginx, чтобы повысить его производительность для нашего профиля нагрузки. В результате смогли увеличить лимиты для конкретного клиента так, чтобы это больше ни на кого не повлияло. Но несмотря на трудности, нам это понравилось. Мы понимали, что помогаем клиенту в тот момент, когда ему уже никто не хотел помогать. К тому же мы смогли справиться с такой сложной задачей в сжатые сроки.
Как помочь разработчикам учиться и какую роль в этом играет Open Source
Сейчас IT-технологии меняются стремительно, если долго сидеть на месте и не узнавать ничего нового, через 3–4 года можно не понять, о чем говорят коллеги. Мы стараемся поддерживать разработчиков в их стремлении учиться. Не обязательно проводить курсы и тренинги. Часто люди сами готовы делиться знаниями внутри коллектива. Для этого как минимум не должно быть постоянных завалов (иначе делиться знаниями просто не будет времени) и нужно давать возможность пробовать что-то новое.
Виктория Суслова, руководитель разработки IAM и Hotbox: У нас знания свободно перетекают, это здорово. Любой человек из другой команды может прийти к тебе и сказать: «Привет! Я придумал кое-что интересное, пойдемте, расскажу за чашкой кофе». Сейчас, разумеется, это происходит в Zoom. Мы обсуждаем идею вместе, думаем, как ее можно развить и где лучше применить. А если я сталкиваюсь с вещами, которых вообще не понимаю, то могу пойти к человеку из любой команды и мне помогут.
Самостоятельному и естественному обучению способствуют Open Source-технологии. Открытый код помогает быстро учиться, узнавать новые практики и подходы к разработке. Большинство технологий, которые мы используем, — это Open Source-решения.
Азат Хадиев, старший программист команды разработки PaaS: Сложность технологий и инструментов растет очень быстро. Еще десять лет назад один разработчик мог делать десктопное приложение и сервисы, разбираться с данными и проектировать схему БД. Сейчас таких Full Stack-специалистов практически нет, потому что в каждой области есть огромный пласт технологий, за которыми нужно следить, и поддерживать свои навыки на уровне. Open Source помогает в этом. Разработчики видят код, подходы к разработке и процессы принятия решений. Большинство открытых проектов позволяют быстро развернуть их и попробовать в действии.
Open Source — огромное сообщество и масса возможностей по обучению на практике. В проприетарных продуктах обучение в корне отличается. Мы можем научиться пользоваться продуктом, но не узнаем, как он устроен, и не сможем взять хорошие примеры на вооружение. Плюс вендор монополизирует и ограничивает возможности обучения. Даже в наше время обучаться некоторым закрытым продуктам приходится по огромным бумажным книгам.
Устроиться в большую компанию несложно
Кажется, что в большую компанию трудно устроиться: слишком высокие требования, какие-то особые собеседования, туда могут устроиться только специалисты со сверхъестественными возможностями. На самом деле все просто: мы большая компания, но у нас работают обычные люди и решают обычные проблемы.
Собеседования проходят стандартно, нет излишней бюрократии. Мы не просим кандидатов заполнять кучу ненужных опросных листов и проходить пять кругов собеседований и всевозможных тестов. Вопросы касаются только работы и экспертности. При этом кандидаты не решают задачи из университетского курса математического анализа и не гадают, «был бы Махатма Ганди хорошим программистом и почему».
Мы не ждем сверхъестественных знаний или очень узких навыков в определенной технологии: 90% задач не требуют экспертного знания в предметной области. В IT все меняется быстро, и технологии, которые мы знаем сегодня, могут уже не пригодиться завтра. Гораздо важнее общее инженерное мышление и способность найти решение проблемы.
Михаил Кебич, руководитель разработки MCS: Когда я устраивался разработчиком в Mail.ru, я волновался: это большая компания, наверное, с особыми требованиями и этапами собеседования. Оказалось, что волновался я совершенно напрасно. А HR-специалисты меня здорово поддержали, провели по всем этапам, отвечали на все мои вопросы. На собеседовании мы всегда работаем в режиме ограниченного времени, поэтому важно услышать и понять проблему, прежде чем пытаться ее решить. Простое и корректное решение, пускай и с недостатками, всегда лучше, чем филигранное, но не доведенное до конца.
Если выделять актуальные на сегодня знания, которые нам нужны, то это проектирование распределенных систем, обеспечение их отказоустойчивости и масштабирование, асинхронное программирование.
Азат Хадиев, старший программист команды разработки PaaS: Еще до MCS я начинал карьеру как системный администратор, потом стал SRE-инженером. Работал в разных компаниях, везде использовались разные комбинации технологий и подходы к построению инфраструктуры. Благодаря этому я получил разносторонний опыт, и мне это очень помогает в работе.
Нам в MCS особенно хорошо подходят разработчики, у которых есть эксплуатационный опыт. Такой разработчик знает, как его продукт работает в большом масштабе, какие возникают нюансы и проблемы. Такой опыт есть не у всех, ведь часто знания разработчиков о продукте ограничены только тем кодом, над которым они работают.
Если вам любопытно попробовать себя в нашей команде, пишите. Прямо сейчас мы ищем Python/Go-разработчика в команду PaaS и Go-разработчиков в команды объектного хранилища и IAM.
Полный и актуальный список наших вакансий.
