Архив недели @stepango
Понедельник
Всем привет🥳 Меня зовут Гончаров Степан(stepango.com). Занимаюсь Android разработкой с 2008 года. Сейчас занимаю должность Engineering Manager в @GrabSG отвечаю за Android & iOS CI, а так же еще кучу всего что не связанно с разработкой новых фич.
Я часто выступаю на @MobiusConf & @AppsConfRussia c докладами про мобильную архитектуру и Gradle. Буду рад вопросам на эти темы.
Я здесь всего на неделю, но вы можете найти меня в любое время тут ➡️ @stepango
Я работаю в компании #Grab и часто замечаю что представление об этой компании у всех очень разное, большинство людей недооценивают масштаб.
Текущая оценка компании 12млрд$, над каждым из основных мобильных приложений работает более 100 инженеров.
У нас 8 офисов где идет разработка, находятся они в разных странах и отвечают за более 10 бизнес направлений, которые оказываются в одном приложении.
Недельный план:
Рассказать про процесс разработки и контроль качества в Grab
Как не сойти с ума когда 200+ инженеров постоянно чего то хотят от твоей команды?
Gradle vs Bazel
Как развиваться дальше, если ты уже Senior?
Каково жить в Сингапуре 5+ лет
Приложение #Grab началось как заказ такси в Малайзии. Теперь мы делаем все остальное, включая доставку еды, платежи, продажу билетов в кино по всей Юго-Восточной Азии. Со средней оценкой приложения 4.6⭐
Размер приложения 60+ мб. Одна из причин этому - #Reactnative. Вторая #Flutter
#reactnative выпиливаем, того не стоит, поддержка кода написанного на RN, дороже и сложнее чем нативного. Типичная ситуация для индустрии
На #Flutter у нас большие надежды, недавно зарелизили приложение целеком на Flutter. play.google.com/store/apps/det…
По мимо работы в #Grab я занимаюсь инвестициями в акции и крипту.
И правда давайте про @Gradle vs #Bazel по холиварим. Не все знают но у меня был второй доклад на @MobiusConf про @bazelbuild
Да уж, создавать треды в Twitter по ходу не моя тема
Вторник
Ну что, давайте обсудим контроль качества для приложений с релизными циклом в 1 неделю и 100+ контрибуторов
Как водится у больших приложений - только trunk based, никакого git-flow. Все изменения идут сразу в мастер, все новые фичи включаются только флагом. Флаги контролируются через наше SDK. продукты и релиз инженеры смотрят за метриками при раскатке
Тестирование автоматизированное, всего что есть Unit + UI. Перед каждым релизом есть список фич которые менялись за неделю по которым проходит ручное тестирование, как только все команды дали зелёный свет - смок тесты гонятся в продакшене и потом релиз
Релиз разкатывается за неделю от 10% до 100% пользователей.
Каждые несколько месяцев мы форсим минимальную версию приложения.
В среднем чтоб 90% пользователей оказались на зарелиженой версии проходит 3-4 месяца.
Постоянно поднимать планку качества можно только литерами.
Если изменения не падают на CI - их смержат.
Для Android у нас более 40 кастомных проверок. Типа запрета на использование Subcomponents
У нас есть версия приложения для сотрудников, где по мимо прочего можно включить любой feature flag и по пользоваться фичами которые не включены в релизе.
Распространяем мы это приложение через кастомный сервис.
Перехожу в режим нового года🥳 увидимся завтра. Всех с праздником!
Четверг
С добрым утром и новым годом! Вчера мы немного отдохнули. В сегодня поговорим о позиции Engineering Manager и о том как моя команда работает с запросами от 200+ инженеров и бизнеса.
Моя святая обязанность как EM это дать команде делать свою работу. Что значит оградить их от митингов и запросов и четко выставить приоритеты. Идеальная рабочая неделя для инженеров в моей команде должна содержать только 1:1, планирование, стендап и ретро
Конечно идеальных недель не бывает и часто инженеры вовлекаются в другие активности, такие как on-call и release manager что обязательно надо учесть при планировании.
Как я уже упоминал - релизный цикл основного приложения 1 неделя, но это не значит что он должен совпадать со спринтами вашей команды. У нас совпадает, в связи со спецификой.
Более 50% времени мы тратим на research что влияет на возможность планирования на 2 недели вперед
Интервью я тоже стараюсь брать на себя, к счастью в последнее время их не много. Но бывали периоды когда я проводил по 4 интервью в неделю. Шанс пройти интервью примерно 1:9
Инженеры не любят открыто обсуждать свои проблемы по этому в довесок к 1:1 у нас есть officevibe.com что помогает следить за настроением в команде.
Все понимают что счастливый разработчик - продуктивный разработчик.
Ещё одна особенность моей команды - отсутствие продактов. У нас есть цели на пол года и мы сами решаем как их достигать. Например Bazel😁
Конечно же когда остальным командам что то нужно они идут либо к нам либо к архитектурной команде, так уж вышло что мы больше по Android, а они по iOS запросам.
И тут ко мне на помощь приходят 4 важных скила: говорить нет, делегирование, сострадание и управление ожиданиями
Мы пишем очень много документации чтоб сделать деллигирование более эффективным. Так же большая часть нашей работы состоит в том чтоб безболезненно делать масштабные изменения изменения. Тут очень важна коммуникация, много и заранее.
Любые изменения которые требуют действий со стороны разработчиков - воспринимаются негативно и чем раньше, чаще и детальнее коммуникация - тем меньше недовольных в момент самого изменения. Мы стараемся делать такие изменения с помощью флага меняющим ворнинг на ошибку
Ещё немного про @bazelbuild, пока не забыл. У нас есть отдельный репозиторий для всего тулинга который мы используем на CI, так вот пара десятков тулов из этого репозитория собираются bazel'ем включая приложения на #Kotlin, #Swift, #Go, #Rust, #Python и даже #Bash с #Docker'ом
Сострадание важный навык для EM'a, от вас ожидают помощи, совета либо просто выслушать проблему.
В больших компаниях рано или поздно вам нужна будет помощь другой команды и вы будете ожидать того же от них.
Управление ожиданиями тоже очень важно, то что вы согласились помочь не значит что вы начнёте в тот же день и завтра это будет готово. Всегда обсуждайте даты, чтоб не было сюрпризов, если не уверены - обговорить дату следующего обсуждения.
Пятница
Так, давайте наконец разберемся нужны ли Engineering Manager'ы
Engineering Manager'ы это как Монады, если ты думаешь что можешь объяснить для чего они нужны - значит ты их не понимаешь.
Суббота
Надо было мне раньше расписать что же это за должность такая Engineering Manager. Но лучше поздно чем никогда 😎
Engineering Manager (EM) это профессионал, владеющий скилами инженера и менеджера. Необходимость наличия экспертизы в двух областях важна для оценки инженеров и координации сложных проектов. Что, в зависимости от компании, может пересекаться с обязанностями инженеров
Так же в обязанности EM'а обязательно входит People Management. Если коротко, то туда входят любые активности и процессы направленные на найм, удержание и повышение продуктивности разработчиков. ИМХО самая сложная часть работы
В разных компаниях и командах набор обязанностей EM'ов может очень сильно отличаться. В моем случае сверху описанных обязанностей я занимаюсь Product Management'ом и Project Management'ом ибо отдельных людей под эти роли у нас нет, прямо как в стартапах
Если интересно более детальное описание каких либо пунктов - спрашивайте.
Воскресенье
Наконец то я долетел до #singapore. Либо сезон дождей кончился, либо мне сегодня везёт с погодой.
Самый большой минус Сингапура - далеко лететь на @MobiusConf 🤣
Ну вот и подошёл к концу мой недельный квест по ведению коллективного твиттера. Если ещё остались вопросы пишите @stepango и добавляйтесь в sg.linkedin.com/in/stepango
Спасибо всем кто участвовал в обсуждении и задавал вопросы!
