ermolnik — GDE, Digital Nomad, mobile team lead – Telegram
ermolnik — GDE, Digital Nomad, mobile team lead
752 subscribers
201 photos
34 videos
2 files
190 links
Канал о мобильной разработке, управлении командами и путешествиях by @ermolnik
Download Telegram
Всем привет, на этот раз из Вьетнама :)
🔥6
Канальчик постепенно меняется

Я создал его 4 года, чтобы тренироваться писать структурированные тексты, но за все время практически этого не делал :)

Сначала использовал его как хранилище сохраненок прикольных статей, но за это время появилось куча каналов, которые подходили к этому более системно и собрали бОльшую аудиторию. Сейчас конкурировать с Broadcast, Mobile developer и Good reads смысла уже нет, поэтому хочу вернуться к тому, для чего я этот канал создавал — делиться своими мыслями, впечатлениями и тд

За время существования канала я немного профессионально вырос, отошел от разработки руками и больше перешел в people/tech management. Ударился в digital nomad и хочу начать этим делиться :)

В следующих постах я расскажу парочку историй про то, как я попутешествовал и адаптировался к работе в Египте, Дубае, Армении и Вьетнаме :)
👍6
И так, про Дубай я уже немного писал, поэтому в этот раз расскажу про месяц в Армении :)

В Армении я был с 25 октября и до момента пока там не стало холодно и в осенних вещах стало не комфортно находиться

Приехав туда в конце октября, я рассчитывал что основной наплыв понаехавших начнет понемногу рассасываться, но какой же это было ошибкой! Ереван был просто второй Москвой: встретить в Дубае русскую речь — было чем-то удивительным и мы сразу шли знакомиться с этими людьми, в Ереване практически все говорили по русски и это было одновременно и плюсом и минусом

Про жилье: думаю, все знают, что из-за сложившейся ситуации цены в Армении улетели просто в космос: за аренду скромной однушки в начале мы отдавали по 8т.р. в день. В сравнении, в Дубае за 4-7 мы снимали огромную двушку с видом на залив. Как в такой ситуации жили местные, с обычными, не IT зарплатами — я не могу представить, люди рассказывали истории, как их арендная плата могла просто в моменте вырасти в 3-5 раз и им приходилось съезжать с арендных квартир

Про питание: питаться в кафешках это был отдельный квест — все заведения в центре были заняты просто 24/7. Приходишь в 9, 12, 15, 19, 22 — везде полная посадка. Но, следует отметить, что еда в Армении превосходная — такого вкусного мяса я до этого нигде не ел!

Так же следует отметить гостеприимство: практически в любом заведении при повторном посещении, нас чем-то угощали, при чем стоимость этих ништяков часто превышала суммарный счет. Всегда считал это байками и преувеличениями, но теперь убедился сам :)

Кто меня знает, знают, что я немного заморочен на кальянах. Так вот, в центре Еревана я был абсолютно во всех кальянных 😂 . Есть мой личный рейтинг кальянных в Ереване, рекламой, конечно, заниматься не буду, но за советом можете заходить в комменты :)

Про безопасность: скажу честно, в Москве компания армян всегда вызывала если не опасение, то настороженность, точно. В Армении за месяц ни разу не было этого чувства, все было прекрасно.

Про передвижение: в Армении есть два основных агрегатора gg (местный) и Яндекс такси. Не смотря на то, что Яндекс это все тот же российский Яндекс, категории авто немного отличаются — в бизнесе к вам чаще всего приедет 40-вая Камри, про свеженький Е-класс, BMW 3/5 серии можно забыть. Эконом это отдельная история: по факту это немного кот в мешке — может приехать та же Камри, а может приехать BMW/Mercedes 90-ых годов и вероятность того, что вы доедете от пункта А до пункта Б не всегда равна 100%, машина может просто по дороге заглохнуть и придется вызывать другое такси :)

В целом Ереван, оставил исключительно положительные эмоции и я, однозначно, советую его посетить и сам, скорее всего, еще не раз туда вернусь :)
🔥5
И так, как я стал Тим лидом, важным таким, в очочках :)

Дело было в 2018 году и, проработав 3 года на одном месте, я решил сменить работу.
На тот момент я 1.5 года писал на С прошивки для контроллеров, 1.5 года писал Java enterprise приложение на стеке 2005 рода и по вечерам десятками клепал мобильные приложения для получения денег с рекламы :)
Походил по собесам и собрал пачку предложений:
1. х4 от текущей зп, древний легаси Enterprise на Java 5
2. х3 зп, приложение топ-1 в своей категории, нужно под аб красить кнопки в андроид приложении
3. х2 зп, писать под android, iOS, rn, прошивки на С и вообще хрен пойми что :)
4. х1.2-1.5 зп, галеры разной степени мутности
5. В Яндексы, авито я даже скрининг не прошел, меня даже Джуном не были готовы взять :)

Что бы вы выбрали?

Я выбрал третий вариант, написал заявление, отработал две недели и, вот он, первый рабочий день :)
Чтобы устроиться нужно было съездить объездить пол Москвы — Отдел кадров в одном месте, пропуск в другом, мед комиссия в третьем, оборудование в четвертом
В общем ладно, устроился, выдали мне мой рабочий инструмент — просто монстр, i5, 8gb RAM, 1tb hdd, от момента включения компа до запуска студии с эмулятором обычно проходил час :)

Комп запущен, идем к команде узнавать, где проект, где трекер задач, что вообще нужно делать?
И узнаем, что местный vpn 90% времени не дает собирать проект, трекера задач пока нет, а сам проект представляет из себя приложение на React native из 5 экранов, которое из-за обновлений RN пока не запускается. На его разработку потрачено примерно 4 месяца :)

Понимая что всем немного пофиг, и свое дикое нежелание писать на RN, за выходные я переписываю это приложение на Натив и еще за пару недель мы с командой доводим его до состояния MVP «ну хоть что-то».
Стейкхолдер, первый раз увидя прогресс по продукту, согласует расширение финансирования

Потом в отделе возникает еще одна идея продукта, опять же за выходные на коленке я делаю что-то похожее на приложение и… снова на это приложение дают бюджет на разработку. Здесь следует сказать, что на тот момент все, что я умел, это делать какие-то прототипы в максимально сжатые сроки — и, так уж совпало, компании в тот момент это было и нужно :)
Разумеется, эти прототипы были ужасного качества, были детские Баги, приложение могло крашиться и я думал, что меня вот-вот уволят

Но после очередного расширения финансирования, я пошел к своему Лиду и говорю «хочу быть лидом андроид команды». Честно, на тот момент думал, что за такую наглость меня в этот же день уволят 😂
Но в итоге меня сделали лидом андроид команды и тут же предложили набрать iOS команду и стать ее руководителем тоже

Вот так, за 3 месяца из Джуна я превратился в head of mobile
🔥5👍4🤔1
Вот теперь я Тим лид команды из 3 андроид разработчиков и мне нужно собрать такую же iOS команду. И если по андроиду у меня были посредственные, но достаточные знания, то по iOS все было значительно хуже :)
Но я уже согласился, отступать нельзя!

Передо мной возникли следующие вопросы: Как их вообще набирать? Что писать в профиле кандидата на подбор? Что спрашивать на собесе?

Разумеется первые собесы были просто «топ 10 вопросов iOS на собеседовании» из первого запроса в Гугле. В чем отличие классов от структур, разница между value/reference type, как реализованы структуры данных. Не смотря на примитивность подхода, но я сходу не смог никого найти — люди с 2-3 годами опыта не могли ответить на базовые вопросы.

Сейчас такие вопросы обычно дают на скрининге, чтобы отсеять совсем слабых кандидатов, лет 5-6 назад много где можно было получить синьорскую лычку за ответы на них 😂

В общем, провел 10 собесов, наняли одного стажера, без коммерческого опыта :)

Решил попробовать поменять структуру собеса и в итоге давал простую задачку — из готовой апишки вывести на экран список формата image, noscript, subnoscript, date. На это давалось минут 40 и 20 минут обсуждали решение

И этот вариант тоже практически провалился: из 5 кандидатов, только один сделал более менее рабочее решение, остальные городили дикие велосипеды: вместо списка просто создавали 10 переменных «per1, per2, per3…» и выводили отдельными вьюшками на экран

Финально, мы наняли одного стажера и одного senior разработчика. Не смотря на то, что как проводить собес я не знал — наняли мы довольно неплохих ребят и, таким образом, моя команда стала уже 3 android и 2 iOS разработчика

С этой командой мы приступили к разработке приложения для увеличения оплодотворяемости коров 🐮
🤯5😁1
Сегодня хотел бы поговорить про фазовые переходы у руководителей :)

Что я подразумеваю под этим термином? У разработчиков есть более менее очерченные границы — intern, junior, middle, senior, примерно состоявшиеся ожидания от каждой из ролей. У руководителей чаще всего такой градации нет, а ожидания сильно размыты и отличаются от компании к компании

Но есть кое что общее: подходы к управлению командами исходя из количества подчиненных и их компетенции. Верхнеуровнево, думаю, всем очевидно, что подход к управлению 3 джунами будет сильно отличаться от управления 15 мидлами-синьорами. Мне в силу неопытности и быстрого карьерного роста это было не понятно, это было реально больно!

Почему? Мой опыт в менеджменте начался с управления командой из двух джунов и стажера. На этом этапе был тотальный микроменеджмент и, наверное, это был верный подход в той ситуации. Я буквально все делал сам и делегировал только самые простые и рутинные задачки. Разумеется, с этого я начинал гореть, но это не ощущалось, пока команда была маленькой. Я успевал перформить за нескольких человек и на этом фоне мне доверили расширение команды.
Когда команда стала больше 5 разработчиков — решать рабочие задачи за 8-часовой рабочий день я успевать перестал. Тут должна быть история как я мастерски овладел навыком делегирования и все пошло как по маслу, но делегирование на команде Джунов работает так себе. На деле я овладел навыком работы по 12 часов 😂

Это был первый фазовый переход, с которым я не справился.

Давайте попробуем добавить интерактива в мои монологи:
У вас есть команда из 6 джуно-мидлов, задачи в принципе решаются, но код после них нерасширяемый, изменения вносить невозможно, а количество багов растет быстрее количества фичей. Чтобы вы сделали на моем месте?
🔥3👍1
Продолжаем историю про бурный рост команды

В предыдущем посте было предположение, что чтобы наладить работу в команде я отправил их в Android academy)
Предположение хорошее, и, наверное, нужно было так и поступить и это позволило бы проще достичь результата, но тогда я почему-то об этом не подумал

В той ситуации мне очень помогли общие тех синки, на которых ребята делали свои доклады в стиле академии — есть какая-то тема, которую один человек разбирает и готовит презу, остальные смотрят, впитывают и задают вопросы. У нас был общий беклог проблем в проекте, которые мы последовательно разбирали. Подход довольно интересный и решает сразу довольно много проблем.
1. Пробелы знаний в команде закрываются сами по себе, Лиду не нужно прокачивать всех отдельно, ставить ИПР и следить за результатом их выполнения
2. Инженеры учатся более структурировано выражать свои мысли и презентовать их остальной части команды
3. Команда сама выявляет проблемы в проекте и сплочается для их решения

Эта штука проработала у нас около 12 спринтов, потом все низковисящие проблемы были решены, более сложные проблемы команда не могла быстро проработать и они остались заметенными под ковер до момента, пока в команду не пришли инженеры значительно выше уровнем и не решили их
🔥2👏1
Поговорим про следующий фазовый переход

Команда 6 Джуно-мидлов подросли в уже настоящих мидлов, которые были способы самостоятельно решать задачи с достаточным уровнем качества.

В чем была проблема в этот момент? Команда способна была решать задачи самостоятельно, но эти задачи надо было сформулировать, перевести с бизнесового языка на язык разработки. На тот момент этой задачей занимался я: поболтать с продактом, бизнесом, узнать что хотят, подсветить чего не хватает, верхнеуровнево расписать что нужно и тд. Сделать это на команду 3 Android + 3 iOS особой проблемы не составляло.

Но команда снова начала расширяться, стало 5 Android + 5 iOS . Управлять 10 разработчиками уже довольно проблематично и вообще с точки зрения коммуникации общаться с 10 людьми уже довольно непростая и выматывающая задача

Я стал факапить проработки задач, проработка ухудшилась, требования начали расходиться их никто не мог засинхронить и возросло количество переделок одних и тех же задач. Команда самоорганизоваться и решить эту проблему не могла

По традиции вопрос к аудитории — что будем делать со сложившейся ситуацией?
Заработался и не добил финальную часть как я стал Тим лидом :)

В предыдущем посте в коментах накинули правильные идеи как управлять командой 10 человек — найти мини лидов, внедрить фича лидство и так далее. Классные и правильные советы, которые звучат довольно просто, но реализовать их, бывает, непросто

Хорошо, когда в команде есть проактивные инженеры, они сами изучают как сделать лучше, как организовать процессы эффективнее, их нужно только синхронизировать — организовать митинги обмена опытом, расставить ограничения и процесс закрутится сам

Плохо, когда проактивных инженеров меньше, чем есть ответственности, которую тебе нужно распределить

Для работы в таких условиях хорошо подходит создание документации, регламентов, чек листов и тд. Но тут возникает очень тонкая грань что руководитель становится борцом за все хорошее, против всего плохого :)
Регламенты описывают идеальные сценарии, которых чаще всего не бывает в реальном мире и тут приходится индивидуально работать с каждым, корректировать, решать повседневные проблемы. Очень важно не скатиться в микроменеджмент, не убить всю мотивацию экспериментировать и ошибаться.
Ретроспективно, тогда мне это не удалось — я организовал процесс, в котором все работало, задачи решались, релизы релизились, но постепенно все заглохло после моего ухода из компании

Чтобы не совершать моих ошибок, хотел бы поделиться несколькими советами:
1. У команды и у мини-лидов должен быть среднесрочный роадмап с четкими целями и сроками их реализации
2. Если команда начинает нарушать сроки, нельзя включаться в процесс и тащить все факапы на себе. Это реально сложно, потому что все проблемы, возникающие перед командой, Лид уже много раз решал, а минилид сталкивается с ними впервые. Нужно именно научить минилида диагностировать эти проблемы(!) и решать их
3. Для того чтобы минилиды справились со свалившейся на них ответственностью, нужно заранее подсвечивать потенциальные проблемы с помощью наводящих вопросов, например:
- Все ли у нас хорошо с активностью «А»?
- Есть ли у команды все необходимое для решения задачи?
- Есть ли какие-то ограничения, которые не позволят реализовать нашу цель?
- справляешься ли ты со своей нагрузкой? Нужно ли что-то пересмотреть
4. Научить минилидов уточнять требования — самая большая проблема разработчиков, что они принимают все требования как аксиому, что приводит к куче переделываний
5. Изучить принцип ситуационного управления. Не буду детально описывать что это и как работает — это легко гуглится)

В следующей статье хочу описать как я стал head of, но буду рад вашим вопросам и разобрать какие-то из ваших кейсов :)
🔥7
Forwarded from commit history
Как я подтягивал английский.

В школе нам преподавали английский на 8 из 10. Моя первая учительница нашла себе англичанина по переписке и уехала к нему жить в Манчестер. В универе как иностранный я выбрал французский, а английский никак не использовал. Когда уже начал работать – английский был нужен на уровне читать тексты и смотреть лекции. Разговорный, который нужен для поиска работы, никак не практиковался, а зря. Собеседования - это стресс, собеседования на английском - двойной стресс. Поэтому параллельно с подготовкой к ним, я начал прокачивать и язык.

Мои принципы прокачки английского
+ цель - хочу спокойно проходить все этапы (алгоритмы, дизайн, behavioral) на английском (британский, американский, разные акценты).
+ хочу при заданном затраченном времени получить максимум результата.
+ не хочу заниматься “3 раза в неделю по часу вечером в течение полугода чтобы отличать все времена perfect между собой”
+ не хочу делать однотипные упражнения

Общая система
Занимался английским 40 минут каждое утро во время завтрака, так привычка английского закрепилась за завтрак. Иногда делал перерыв и потом занимался еще минут 40. На выходных минут по 20-30 чисто слова повторял.

Набор упражнений
1. Словарный запас.
Взял топ 1000 частотных слов, пролистал и все что не знаю закинул в анки карты и повторял. Потом взял топ 3к слов.

2. Умение говорить, умение писать и грамматика. Взял кучу вопросов к behavioral , накидал ответы через голосовой ввод -> закинул в Grammarly , чтобы проверить ошибки -> темы, в которых ошибаюсь прочитал в Murphy и поделал упражнения.

3. Слушание. Смотрел выступления на ютубе или daily dictation и устраивал себе диктант. Либо пересказывал своими словами и опять в пайплайн грамматики.

4. Умение говорить. Нашел преподов на italki из стран с высоким уровнем английского, но низкими доходами: Кения, Филлипины, ЮАР, Нигеия, Малайзия. С ними устраивал мок-собеседования либо общение с неожиданными вопросами от них и разбором.

5. Читал фоном книги на англ, сериалы. Но это я обучением не считаю, это потребление контента.

Проверка себя.
Тест через приложение English score для оценки грамматики, слов, аудирования. Моки собеседований и реальные собеседования для оценки разговорного английского. Особенно, когда звонят на мобильный телефон и там связь плохая.


Пост прям по верхам написал, потом подробнее разберу второй пункт с упражнениями и что конкретно делал. В комментариях, прошу поделиться, кто как качает мышцу английского.
🔥12👍41
Как я запромоутился до head of

Под head of все понимают разное, в некоторых команиях руководитель Android+iOS небольшой команды — уже head of, но я под этим подразумеваю момент, когда у Лида появляются другие Лиды в подчинении

И так, как я им стал? Команда, которую я собрал уже начала хорошо перформить, но на тот момент об этом знала команда, я и мой Лид. Пришло время поработать над visibility результатов команды внутри компании.

Как это можно сделать? Обычно в компаниях есть общие tech demo, у нас такого не было и мест, где показать какая у тебя Крутая команда особо не было. Значит надо взять все в свои руки и создать условия самому!
На тот момент команда строилась по схеме McKinsey. Была матричная структура с платформенными и продуктовыми командами и в планах было построение дополнительной абстракции в виде платформенных стримов. Например, у вас есть в компании 20 мобильных команд, все команды никак не взаимодействуют между собой, знания не шарятся, наработки не переиспользуются — нужно создать что-то что будет это делать. Так как это была огромная неповоротливая корпорация очень долго от слов к делу не переходило
Ну и я взял все в свои руки, создал эту сущность и нагло стал владельцем этого процесса :)

Эта сообщества назывались гильдии, руководителем такой мобильной гильдии я и стал. Это должно было позволить пиарить свою команду, общаться с топами и продвигать изменения на более высоком уровне

Что сработало?
1. Команды начали узнавать друг о друге
2. Команды смогли проще решать технические проблемы
3. Появилась возможность подсвечивать глобальные проблемы и проектировать варианты их решения
4. Появилась возможность строить технические процессы на более высоком уровне — общая дизайн система, общий артифактори, общие правила и бейзлайны
5. О команде узнало большее количество людей и под мои проекты стало проще выделение ресурсов — практически в один момент моя команда выросла с 10 до 20 разработчиков

Что не сработало?
1. Моя роль была формальной, никакой официальной лычки «батя мобилки» у меня не было. Это не позволяло с ноги заходить в команды и диктовать свои правила. Все драйвилось на личном авторитете, продвигалось, но все шло очень медленно. Вывод — любая инициатива без полномочий работает плохо или не работает вовсе
2. Так как лычки не было, финально чтобы что-то реализовать мне приходилось убеждать разрабов, их лидов, продактов, топов уровня CTO/VP. Учесть интересы всех просто не возможно и в итоге все это сводилось к тому, чтобы убедить VP что-то сделать, а он уже своим авторитетом все продавливал. Но проблема была в том, что человеку уровня VP это нафиг не нужно. Вывод — если на уровне культуры и процессов компании это не заложено, то можно на этом сильно задолбаться и сгореть :)
12🔥2👍1
Итогов не будет, с Новым годом всех 😎
👍8🎉7