Азат Хадиев, старший программист команды разработки PaaS: Нельзя сказать, что мы работаем только в B2B, это скорее что-то среднее между B2B и B2C. В чистом B2B нужно тесно общаться с заказчиком и очень формально документировать проект. Нужно все заранее заложить в ТЗ, любое отклонение от него довольно болезненно, требует долгого и непростого согласования с обеих сторон. А в B2C нет таких жестких формальностей и бюрократизированного документооборота, разрабатывать принято в виде постоянного потока изменений, особенно в последние годы. С одной стороны, мы B2B, потому что в основном работаем с корпоративными клиентами, хоть и без излишней бюрократии. Иногда новая функциональность появляется по их запросам, но потом она все равно становится доступна всем в публичном облаке. Но с точки зрения разработки мы ближе к B2C, потому что у нас частые и мелкие доработки, которые мы постоянно выкатываем в продакшен. В отличие от B2B разработки, где релизный цикл обычно минимум 3 месяца, мы релизимся как минимум каждые 2 недели.

Виктория Суслова, руководитель разработки IAM и Hotbox: Я не знаю, откуда берется это разделение — разработка B2B или B2C. Для меня важнее то, что я делаю нужный продукт, который не стоит на месте и полезен людям. А это может быть как в B2B, так и в B2C. Если компания пришла с заказом, значит, он действительно ей нужен и результатом будут пользоваться. Удовлетворить потребности большой компании интереснее, чем нескольких отдельных человек. Ведь реализация «хотелок» отдельных пользователей может оказаться работой в стол. Кроме того, общаясь с большим количеством крупных заказчиков, наши разработчики расширяют свои представления о современных инструментах и процессах разработки, которые применяются в ведущих российских и международных компаниях и зачастую начинают внедрять удобные практики в свою повседневную работу. Приватные инсталляции — это отдельный челлендж. По большей части в том, как привнести и совместить фичи публичного облака и приватного. С заказчиками мы общаемся без лишних формальностей, это приятные и адекватные люди.

Михаил Кебич, руководитель разработки MCS: С каждой командой работает Product Manager, который ведет сервис как продукт. Он знает желания и потребности клиентов. Команда разработки, со своей стороны, знает, как устроен сервис изнутри, его возможности и технические ограничения. На основе этих знаний постоянно происходит диалог между PM и технической командой, они вместе решают, что нужно делать, как и когда. Получается, что разработчики имеют представление о потребностях клиентов, а PM — о технических деталях, они говорят на одном языке, у них большое поле для совместного принятия решений. Такой подход дает возможность делать то, что нужно именно сейчас, без ущерба в технике или продукте.

Виктория Суслова, руководитель разработки IAM и Hotbox: Наши команды погружены в мир клиентов и их потребностей. Каждый из нас знает, какую пользу клиентам несет его работа, даже если это самый маленький скриптик. Поэтому принимать решения внутри команды — это для нас довольно просто.

Азат Хадиев, старший программист команды разработки PaaS: Добавлю, что по сравнению с централизованным развитием продукта в таком подходе есть определенные недостатки: Например, какие-то мелкие вещи мы можем делать дважды, трижды в разных командах. Вместо того чтобы объединить функционал в общую библиотеку, каждая команда делает его самостоятельно. Иногда это может дать осечку при интеграции сервисов. Хотя общие точки соприкосновения мы отрабатываем командами совместно, иногда что-то может пойти не так. Какой-нибудь нюанс сервиса, который другая команда попросту не знает. Возможно, как раз для таких случаев не хватает глобальных архитекторов, которые могут это все сразу предвидеть.

Виктория Суслова, руководитель разработки IAM и Hotbox: Срочная работа заставляет сойти с привычного пути, мозг начинает работать немного по-другому. То, на что в обычном режиме потратили бы месяц, сейчас нужно сделать за две недели. Это непросто, но зато потом получаешь удовлетворение от осознания того, что не каждый смог бы с этим справиться, а наша команда смогла.

Михаил Кебич, руководитель разработки MCS: У нас был один очень интересный челлендж. К нам обратился клиент, у которого в период пандемии резко выросла нагрузка, с которой он не мог справиться сам. Мобильное приложение превышало лимиты запросов к нашему хранилищу в несколько раз и медленно работало. Решение нужно было найти быстро, потому что нагрузка росла каждый день. К задаче подключились несколько команд разработчиков и администраторов. Все вместе мы обсуждали проблему, предлагали идеи и проверяли их, спорили и договаривались. Клиент обратился к нам в пятницу вечером, когда его уже никто не хотел консультировать. В тот день мы работали до полуночи и потом еще все выходные. Но в итоге за 2–3 дня нашли решение, которое позволило клиенту правильно распределить свою нагрузку. Также мы улучшили и свое решение: сильно покопались во внутренностях nginx, чтобы повысить его производительность для нашего профиля нагрузки. В результате смогли увеличить лимиты для конкретного клиента так, чтобы это больше ни на кого не повлияло. Но несмотря на трудности, нам это понравилось. Мы понимали, что помогаем клиенту в тот момент, когда ему уже никто не хотел помогать. К тому же мы смогли справиться с такой сложной задачей в сжатые сроки.

Виктория Суслова, руководитель разработки IAM и Hotbox: У нас знания свободно перетекают, это здорово. Любой человек из другой команды может прийти к тебе и сказать: «Привет! Я придумал кое-что интересное, пойдемте, расскажу за чашкой кофе». Сейчас, разумеется, это происходит в Zoom. Мы обсуждаем идею вместе, думаем, как ее можно развить и где лучше применить. А если я сталкиваюсь с вещами, которых вообще не понимаю, то могу пойти к человеку из любой команды и мне помогут.

Азат Хадиев, старший программист команды разработки PaaS: Сложность технологий и инструментов растет очень быстро. Еще десять лет назад один разработчик мог делать десктопное приложение и сервисы, разбираться с данными и проектировать схему БД. Сейчас таких Full Stack-специалистов практически нет, потому что в каждой области есть огромный пласт технологий, за которыми нужно следить, и поддерживать свои навыки на уровне. Open Source помогает в этом. Разработчики видят код, подходы к разработке и процессы принятия решений. Большинство открытых проектов позволяют быстро развернуть их и попробовать в действии. Open Source — огромное сообщество и масса возможностей по обучению на практике. В проприетарных продуктах обучение в корне отличается. Мы можем научиться пользоваться продуктом, но не узнаем, как он устроен, и не сможем взять хорошие примеры на вооружение. Плюс вендор монополизирует и ограничивает возможности обучения. Даже в наше время обучаться некоторым закрытым продуктам приходится по огромным бумажным книгам.

Михаил Кебич, руководитель разработки MCS: Когда я устраивался разработчиком в Mail.ru, я волновался: это большая компания, наверное, с особыми требованиями и этапами собеседования. Оказалось, что волновался я совершенно напрасно. А HR-специалисты меня здорово поддержали, провели по всем этапам, отвечали на все мои вопросы. На собеседовании мы всегда работаем в режиме ограниченного времени, поэтому важно услышать и понять проблему, прежде чем пытаться ее решить. Простое и корректное решение, пускай и с недостатками, всегда лучше, чем филигранное, но не доведенное до конца. Если выделять актуальные на сегодня знания, которые нам нужны, то это проектирование распределенных систем, обеспечение их отказоустойчивости и масштабирование, асинхронное программирование.

Азат Хадиев, старший программист команды разработки PaaS: Еще до MCS я начинал карьеру как системный администратор, потом стал SRE-инженером. Работал в разных компаниях, везде использовались разные комбинации технологий и подходы к построению инфраструктуры. Благодаря этому я получил разносторонний опыт, и мне это очень помогает в работе. Нам в MCS особенно хорошо подходят разработчики, у которых есть эксплуатационный опыт. Такой разработчик знает, как его продукт работает в большом масштабе, какие возникают нюансы и проблемы. Такой опыт есть не у всех, ведь часто знания разработчиков о продукте ограничены только тем кодом, над которым они работают.