Архив недели
Понедельник
Всем привет! Я Тимлид в кросс-функциональной команде, но больше известен по Android Crew. За эту неделю я постараюсь это исправить рассказом о том как управлять командой в которой нет твоего стека совсем.
План будет примерно такой:
Какой вообще у нас стек и в чем из этого я понимаю
Как меняется взаимодействие разных частей проекта, когда лид «фронтовик»
Найм людей
Правда ли нужно разбираться во всем
Как развивать команду
Разгрузочный день
Вторник
Давайте прежде чем расскажу про стек, скажу пару слов про саму компанию. Мы аутсорс, но клиент как правило не диктует нам чего использовать, поэтому у нас есть небольшая свобода в этом плане.
Обычно это вот так:
Php (laravel) + vue js + flutter
Либо
Python (Django) + vue js + flutter
Либо вместо Flutter это Android и редко android + iOS
Да, все что показывается в браузере у нас на vue js
С мобильной частью все просто: андроид я пишу либо сам либо просто знаю что происходит, с Flutter перед затаскиваем его в компанию я тоже достаточно подробно разобрался и мы сделали предварительно пару мелких приложений чтобы понять где зайдет, а где нет.
Сейчас расскажу про фронт, а потом перейдём к самому страшному: php на бекенде.
Вариантов у нас было немного, либо react либо vue, очень быстро оценив рынок выбрали второе. Найти человека на React - ну ооочень дорого.
Теперь про бекенд, если про Python набросить обычно нечего, то про PHP обычно много шутят и воротят носы :) но всё-таки выяснилось, что если быть немного инженером и подходить к проектированию с головой - то он даже очень ок.
Несмотря на то что технологии разные, языки разные и (под) команды немного разные, их всех объединяет несколько общих вещей: таски в трекере, единая модель ветвления (gitflow) и одинаковый для всех процесс доставки (везде автодеплой)
Среда
Давайте расскажу какие произошли трансформации в одном из проектов с точки зрения взаимодействия всех частей когда на проект пришёл я и отнял бразды у бекендера.
Что было: логика максимально вынесена на клиент, очень много «зашитых» моментов, например тексты ошибок или порядок экранов там где можно это не делать
Казалось бы, ничего не страшного, но этот день всегда наступает: приходит клиент и говорит что срочно нужно что-то добавить
Выяснилось, что для того чтобы добавить пару строчек нам нужно примерно 2 недели и перевыпуск приложения. Нужно было что-то менять
Конечно, со стороны всегда все кажется понятным, но в жизни мы всегда натыкаемся на какие-то грабли :)
Первое что я сделал, установил правило «на чьей стороне фиксим баги», где почти всегда мы начали решать не в пользу бекенда, потому что его можно доставить за 5 минут
Второе с чем мы начали работать это максимальное «сужение» клиентов. Мы начали все-все-все что можно выносить на бекенд и если можно где-то заложиться и вынести на сервер, то выносим.
Казалось бы, простые и очевидные действия. Но структура проекта начала поразительным образом меняться.
Что поменялось: самое главное, уменьшился TTM и релизы стали происходить ради новых фич, а не для тюнинга старых.
Бекенд начал лучше понимать боли фронтов и уже сам предлагать чего бы ещё можно вынести к ним.
Самое крутое: после кучи итераций именно бекенд стал источником правды. И там стало настолько интересно что я в какой-то момент захотел сам что-то там попрограммиовать :)
Это была уже трансформация меня: мне всегда казалось что на бекенде как и на мобилах тоже json перекладывают :) а тут и связи и там логика интересная и там, огонь!
Четверг
Ночной тред про найм.
Как вы понимаете, мне досталась задача как-то нанять хороших людей на те области, в которых у меня нет большой экспертности.
Самый важный момент который я осознал в процессе своего развития: на найм тоже нужен бюджет.
Тут нам немного повезло: бюджет позволял пару раз ошибиться. Самый большой челлендж был найти бекендера.
Кое-какой опыт всё-таки был, поэтому собесы строились по схеме «взять самые частые вопросы по php» и задать их. Удивительно, но уже на этом этапе половина кандидатов отвалилась.
Дальше мы уходили в архитектуру, ведь какой андроид-разработчик не захочет поговорить про архитектуру.
Если тут все нормально, то начиналась самая важная часть, которую можно обозвать hr-бинго, с вопросами про 5 лет и вот это вот все.
Мой подход к найму в целом звучит так: я не хочу рок-звезду, я хочу команду адекватных людей, которые смогут сработаться друг с другом.
Я считаю, что этот подход в целом оправдал себя. Мы искали долго, с одним не сработались, но сейчас мне очень нравится команда.
С фронтами было попроще: на vue очень популярен vuex, чей подход взят с Elm architecture, которая уже так иначе должна быть знакома любому андроид-разработчику. После серии стандартных вопросов я мог радостно накинуть на архитектуру и общее понимание что вообще происходит.
Взяли двоих и уже год успешно работаем
Самый забавный оффер и мэтч случился с флаттером. Нам нужна была консультация по платежной интеграции, я поступил как настоящий разработчик и спросил в канале ТГ.
Получив ответ, спросил не хочет ли человек взяться за эту задачу сам. Попутно выяснилось, что он сейчас без работы. Работаем уже 2 года, очень довольны :)
Помогать в чатах полезно :)
Пятница
Гоу тред про всезнайство и как всё-таки представлять что происходит в проекте
Конечно же, разбираться во всем на экспертном уровне невозможно. Но можно немного улучшить ситуацию.
Если у вас много времени или просто есть огромная тяга к знаниям - МОКи (онлайн курсы) для вас
Я проходил такие для Флаттера, я получил целую Нанодегри для Иос. Конечно же я не стал специалистом которого после этого захочет взять любая компания, но понять потом что написано в коде - достаточно.
Если у вас нет времени, то второе что вы можете начать делать - смотреть MR, особенно если вы приучили команду делать их нормально. Т.е 1 таска = 1MR
Самый высокий уровень - начать делать маленькие тасочки. Не бывает таких проектов, где нужно пилить только огромные фичи, всегда найдётся что-то небольшое. К тому же вы тимлид, придумайте что-нибудь.
И еще, вот самая важная фраза которую вам нужно использовать при разговоре: я не разбираюсь в теме, можешь рассказать как бабушке?
Во-первых вы и правда плохо разбираетесь, во-вторых это очень сильно разряжает обстановку и вам начинают раскладывать все по полочкам и объяснять ограничения системы или языка
И не могу не заметить, что техническое образование всё-таки очень сильно помогает в подобных историях. Как-будто бы ничего напрямую не пригодилось, но без фундамента мне пришлось бы в разы тяжелее.
Суббота
Тред про развитие команды
Кажется, что единственное что мы можем предложить команде - менторинг.
Но если ты знаешь как устроена вся система в разных частях и все ещё умеешь программировать, то и посоветовать все ещё чего-то можно :)
Самое очевидное - вы можете ревьюить архитектурные решения (если конечно хорошо в этом разбираетесь). Какие-то вещи просто работают похоже в разных системах.
Из недавнего: разбирались с циркулярной зависимостью на бэкенде. Подход к решению глобально ничем не отличается от того как мы это делаем в андроиде или любой другой области.
Ещё я подписался на популярные рассылки по языкам, которые мы используем, просматриваю одним глазом на предмет того, не подвернётся ли что-то нужное нам.
Отправить мидла на конференцию - тоже развитие
Отправить его на конференцию Podlodka - вдвойне :)
Что касается синьоров, то по моему убеждению он должен уже сам уметь себя развивать вглубь и тут уже и правда будет больше менторинга/коучинга, плюс со стороны обычно видно перекосы в какую-то сторону и можно подобрать задачки так чтобы он немного рос вширь.