Всем привет🥳 Меня зовут Гончаров Степанstepango.coma). Занимаюсь Android разработкой с 2008 года. Сейчас занимаю должность Engineering Manager в@GrabSGG отвечаю за Android & iOS CI, а так же еще кучу всего что не связанно с разработкой новых фич.

Я часто выступаю на @MobiusConf & @AppsConfRussia c докладами про мобильную архитектуру и Gradle. Буду рад вопросам на эти темы.

Я здесь всего на неделю, но вы можете найти меня в любое время тут ➡️ @stepango

1. Я работаю в компании #Grab и часто замечаю что представление об этой компании у всех очень разное, большинство людей недооценивают масштаб.
Текущая оценка компании 12млрд$, над каждым из основных мобильных приложений работает более 100 инженеров.

2. У нас 8 офисов где идет разработка, находятся они в разных странах и отвечают за более 10 бизнес направлений, которые оказываются в одном приложении. pic.twitter.com/sNHA7uihwY

Недельный план:

1. Приложение #Grab началось как заказ такси в Малайзии. Теперь мы делаем все остальное, включая доставку еды, платежи, продажу билетов в кино по всей Юго-Восточной Азии. Со средней оценкой приложения 4.6⭐

2. Размер приложения 60+ мб. Одна из причин этому - #Reactnative. Вторая #Flutter

3. #reactnative выпиливаем, того не стоит, поддержка кода написанного на RN, дороже и сложнее чем нативного. Типичная ситуация для индустрии

4. На #Flutter у нас большие надежды, недавно зарелизили приложение целеком на Flutter. play.google.com/store/apps/det…

По мимо работы в #Grab я занимаюсь инвестициями в акции и крипту.

1. И правда давайте про @gradle vs #Bazel по холиварим. Не все знают но у меня был второй доклад на @MobiusConf про @bazelbuild

Да уж, создавать треды в Twitter по ходу не моя тема pic.twitter.com/xETkQGO3C8

1. Ну что, давайте обсудим контроль качества для приложений с релизными циклом в 1 неделю и 100+ контрибуторов

2. Как водится у больших приложений - только trunk based, никакого git-flow. Все изменения идут сразу в мастер, все новые фичи включаются только флагом. Флаги контролируются через наше SDK. продукты и релиз инженеры смотрят за метриками при раскатке

3. Тестирование автоматизированное, всего что есть Unit + UI. Перед каждым релизом есть список фич которые менялись за неделю по которым проходит ручное тестирование, как только все команды дали зелёный свет - смок тесты гонятся в продакшене и потом релиз

4. Релиз разкатывается за неделю от 10% до 100% пользователей.

Каждые несколько месяцев мы форсим минимальную версию приложения.

В среднем чтоб 90% пользователей оказались на зарелиженой версии проходит 3-4 месяца.

5. Постоянно поднимать планку качества можно только литерами.

Если изменения не падают на CI - их смержат.

Для Android у нас более 40 кастомных проверок. Типа запрета на использование Subcomponents

6. У нас есть версия приложения для сотрудников, где по мимо прочего можно включить любой feature flag и по пользоваться фичами которые не включены в релизе.

Распространяем мы это приложение через кастомный сервис.

Перехожу в режим нового года🥳 увидимся завтра. Всех с праздником!

1. С добрым утром и новым годом! Вчера мы немного отдохнули. В сегодня поговорим о позиции Engineering Manager и о том как моя команда работает с запросами от 200+ инженеров и бизнеса.

2. Моя святая обязанность как EM это дать команде делать свою работу. Что значит оградить их от митингов и запросов и четко выставить приоритеты. Идеальная рабочая неделя для инженеров в моей команде должна содержать только 1:1, планирование, стендап и ретро

3. Конечно идеальных недель не бывает и часто инженеры вовлекаются в другие активности, такие как on-call и release manager что обязательно надо учесть при планировании.

4. Как я уже упоминал - релизный цикл основного приложения 1 неделя, но это не значит что он должен совпадать со спринтами вашей команды. У нас совпадает, в связи со спецификой.

Более 50% времени мы тратим на research что влияет на возможность планирования на 2 недели вперед

5. Интервью я тоже стараюсь брать на себя, к счастью в последнее время их не много. Но бывали периоды когда я проводил по 4 интервью в неделю. Шанс пройти интервью примерно 1:9

6. Инженеры не любят открыто обсуждать свои проблемы по этому в довесок к 1:1 у нас есть officevibe.com что помогает следить за настроением в команде.

Все понимают что счастливый разработчик - продуктивный разработчик.

7. Ещё одна особенность моей команды - отсутствие продактов. У нас есть цели на пол года и мы сами решаем как их достигать. Например Bazel😁

8. Конечно же когда остальным командам что то нужно они идут либо к нам либо к архитектурной команде, так уж вышло что мы больше по Android, а они по iOS запросам.

И тут ко мне на помощь приходят 4 важных скила: говорить нет, делегирование, сострадание и управление ожиданиями

9. Мы пишем очень много документации чтоб сделать деллигирование более эффективным. Так же большая часть нашей работы состоит в том чтоб безболезненно делать масштабные изменения изменения. Тут очень важна коммуникация, много и заранее.

10. Любые изменения которые требуют действий со стороны разработчиков - воспринимаются негативно и чем раньше, чаще и детальнее коммуникация - тем меньше недовольных в момент самого изменения. Мы стараемся делать такие изменения с помощью флага меняющим ворнинг на ошибку

Ещё немного про @bazelbuild, пока не забыл. У нас есть отдельный репозиторий для всего тулинга который мы используем на CI, так вот пара десятков тулов из этого репозитория собираются bazel'ем включая приложения на #Kotlin, #Swift, #Go, #Rust, #Python и даже #Bash с #Docker'ом

11. Сострадание важный навык для EM'a, от вас ожидают помощи, совета либо просто выслушать проблему.

В больших компаниях рано или поздно вам нужна будет помощь другой команды и вы будете ожидать того же от них.

12. Управление ожиданиями тоже очень важно, то что вы согласились помочь не значит что вы начнёте в тот же день и завтра это будет готово. Всегда обсуждайте даты, чтоб не было сюрпризов, если не уверены - обговорить дату следующего обсуждения.

Так, давайте наконец разберемся нужны ли Engineering Manager'ы

Engineering Manager'ы это как Монады, если ты думаешь что можешь объяснить для чего они нужны - значит ты их не понимаешь. pic.twitter.com/jau29khINz

1. Надо было мне раньше расписать что же это за должность такая Engineering Manager. Но лучше поздно чем никогда 😎

2. Engineering Manager (EM) это профессионал, владеющий скилами инженера и менеджера. Необходимость наличия экспертизы в двух областях важна для оценки инженеров и координации сложных проектов. Что, в зависимости от компании, может пересекаться с обязанностями инженеров

3. Так же в обязанности EM'а обязательно входит People Management. Если коротко, то туда входят любые активности и процессы направленные на найм, удержание и повышение продуктивности разработчиков. ИМХО самая сложная часть работы

4. В разных компаниях и командах набор обязанностей EM'ов может очень сильно отличаться. В моем случае сверху описанных обязанностей я занимаюсь Product Management'ом и Project Management'ом ибо отдельных людей под эти роли у нас нет, прямо как в стартапах

5. Если интересно более детальное описание каких либо пунктов - спрашивайте.

Наконец то я долетел до #singapore. Либо сезон дождей кончился, либо мне сегодня везёт с погодой.

Самый большой минус Сингапура - далеко лететь на @MobiusConf 🤣

Ну вот и подошёл к концу мой недельный квест по ведению коллективного твиттера. Если ещё остались вопросы пишите @stepango и добавляйтесь в sg.linkedin.com/in/stepango

Спасибо всем кто участвовал в обсуждении и задавал вопросы!