Привет, Хабр!
Меня зовут Владимир. Я отвечаю за мобильную разработку в Vivid Money.
Vivid Money — это финтех-стартап для европейского рынка с большим набором функционала — платежи и переводы, мультивалютность, финансовая аналитика, совместное пользование счетами, инвестиции и многое другое. Ближайшими конкурентами можно считать Revolut и N26.
Нам удалось сделать и успешно запустить мобильное финтех приложение за год. За этот год я собрал идеи, которые формировались у меня в голове около 4 лет, пока я был лидом на других проектах. В этой статье эти идеи собраны в виде советов software engineering manager’ам/лидам, которые стартуют долгосрочные и масштабные проекты с нуля.
Чуть больше года назад я пришёл на проект в роли лида Android-команды. Передо мной стояла амбициозная и интересная задача — выбрать технологии, собрать команду, настроить процессы и, самое главное, сделать всё это хорошо. Хорошо — растяжимое понятие, но для меня это качественный продукт с продуктовой и технической точки зрения.
Начинать проект с нуля — задача настолько интересная и захватывающая, насколько непонятная и сложная. Сперва не знаешь, за что хвататься, потом дел становится так много, что весь процесс работы похож на тушение пожаров.
Чтобы такого не происходило, необходимо прежде всего чётко определить приоритеты активностей.
На мой взгляд, основные активности лида можно расположить в следующем порядке:
В этой части статьи я остановлюсь только на первом пункте.
Дисклеймер:
В статье собраны мои размышления и выводы, основанные на моём опыте работы в больших и долгосрочных проектах. Какие-то из советов могут показаться избитыми, но, как показала практика, даже в крупных компаниях и проектах не все из них применяются.
Для меня этот пункт стоит на первом месте, так как от “качества” людей зависит дальнейшая работа команды.
У нас был очень амбициозный срок для запуска банка — 1 год. За это время было необходимо качественно сделать огромный объём функционала. Времени на несамостоятельных, плохо обучаемых сотрудников просто не было. Отсюда вытекает следующий совет:
Помимо того, что слабый разработчик напрямую влияет на качество кода и количество багов в продукте, на него невозможно делегировать, так как не будет полного доверия и потребуется постоянный контроль. Поэтому возникнут сложности в быстрорастущем проекте.
Зачастую собеседование разработчика в России сводится к вопросам по языку/фреймворку. На самом деле, софт-скиллы играют не менее важную роль, при этом их труднее наработать. Плюс ко всему, человек, имеющий схожий майндсет, имеет больше шансов вписаться в команду.
Для себя мы выделили следующие софт-скиллы:
И, естественно, базовые неконфликтность и умение общаться с людьми.
Например, мы задаём вопрос кандидату: “Почему уходишь со старого места работы и какие у тебя критерии выбора нового места работы?”. Сам ответ не настолько важен, как важен системный подход — мы ждём, что кандидат отдаёт себе отчёт, что его не устраивает, что он смог до этого дойти логическим путём и разложить всё по полочкам в своей голове.
Примерами подобных вопросов, которые помогают нам понять майндсет и принципы кандидата, могут быть: “Как выглядит твоя идеальная команда?” или “Как выглядит идеальный процесс разработки?”.
Собеседование нужно воспринимать как механизм, который можно улучшить и оптимизировать. Или как программу, которую можно отрефакторить.
Приведу примеры оптимизаций, которые мы делали.
Пример 1
На собеседование каждого кандидата уходит примерно по 1.5 часа времени двоих разработчиков. Чтобы оптимизировать это время и не тратить его на заведомо слабых кандидатов, мы ввели скрининг. Скрининг — это несколько простых, закрытых вопросов, на которые есть заготовленные ответы. Рекрутеры сами задают эти вопросы кандидату, на что у них уходит около 10-15 минут.
Немного цифр:
Из 100 кандидатов после скрининга отсеивается примерно треть, то есть около 30. Рекрутер тратит на каждый скрининг примерно 15 минут, то есть примерно 8 часов чистого времени на 30 отсеянных кандидатов. При классическом собеседовании на этих же 30 кандидатов мы бы потратили время около 60 человеко-часов в самом оптимистичном сценарии.
Пример 2
Цель собеседования — отобрать максимально релевантного кандидата. Мы проанализировали и выявили критичные для проекта hard-скиллы и навыки с учетом стека выбранных технологий, что позволило нам убрать часть нерелевантных вопросов и сократило время собеседования.
Например, мы убрали вопросы, связанные с частями Android SDK, которые не используются у нас на проекте — ContentProvider, JobScheduler и т. д. Ответы на эти вопросы не дадут нам понимания, вольётся ли он в разработку регулярных фич проекта, в которых эти части SDK используются очень редко.
Пример 3
Изначально техническое собеседование проходило в два раздельных этапа — теоретические вопросы и практические задачи. Это сильно увеличивало время прохождения всех этапов собеседования для кандидата, и много соискателей терялось, так как IT-рынок очень конкурентный — хорошим разработчикам быстро делают офферы.
Чтобы оптимизировать воронку, мы схлопнули собеседование в 1 этап — убрали неинформативные вопросы и решение алгоритмических задач. Про неинформативные вопросы я писал в предыдущем пункте. А вот алгоритмические задачи мы заменили практическими задачами по фреймворку. Они также проверяют умение писать код и одновременно знание SDK.
В итоге, осталось одно техническое собеседование на 1.5 часа, но оно стало максимально отточенным по содержанию.
Самым важным критерием выбора разработчика оказалось “понимание”. Чтобы человек не просто умел давать определения и академические знания, а демонстрировал понимание устройства того или иного фреймворка. Разработчик без этого понимания, сталкиваясь с проблемами, не сможет найти решение самостоятельно или решит задачу недостаточно оптимально. Поэтому все вопросы собеседования мы сделали открытыми, чтобы кандидат не выдавал заученные термины, а рассуждал на ту или иную тему. А мы следим за его знаниями по теме и ходом его логики.
Например, мы задаём открытый вопрос: “Как сделать в Android детектор ANR (Application Not Responding)?”. Этот вопрос проверяет знание работы потоков в Android, но позволяет избежать прямого вопроса про Looper и Handler. Также он позволяет лаконично перейти на тему с многопоточностью.
При быстром росте команды собеседований становится настолько много, что это занимает весь день, и не остаётся времени на остальные активности. Поэтому функцию собеседований полезно частично делегировать на команду.
Это не просто снимает нагрузку с лида, но ещё и включает разработчика в выбор своего потенциального коллеги, что его дополнительно мотивирует.
Плюс к этому, кандидат знакомится с командой и составляет для себя более целостное впечатление.
При найме всегда надо помнить про баланс людей по компетенциям в команде. Слишком много синьор-разработчиков может привести к тому, что они будут придумывать новые решения, но разработчики не будут делать фичи. Но на старте проекта, когда закладывается техническая база на годы вперёд, это необходимо. Мало того, для написания обычного кода фич, синьор будет стоить неоправданно дорого. Слишком много джуниоров, в свою очередь, ухудшит кодовую базу и, как следствие, потопит проект в долгосрочной перспективе. Однако, толковые джуниоры быстро вырастают в миддлов и становятся гораздо более лояльными к компании и команде, чем миддлы с рынка. На мой взгляд, для каждого проекта и конкретной ситуации этот баланс разный, поэтому не буду приводить конкретных процентных соотношений.
Зачастую для ускорения разработки команды разбавляют подрядчиками. Тут тоже очень важен баланс, так как большое количество подрядчиков также может ухудшить код в проекте. У подрядчиков редко можно встретить мотивацию и заинтересованность в проекте как у штатных сотрудников.
Ну и наконец, не нужно бояться увольнять людей из команды. Человек, не подходящий команде по принципам и духу или по техническим скиллам, принесёт в долгосрочной перспективе гораздо больший вред, чем пользу от сиюминутного написания кода.
Уволить — звучит легко, а вот как это сделать максимально безболезненно для сотрудника и команды? Тут работает принцип: “Не важно, что ты сделаешь, а важно как”. Если сделать все заранее — обговорить ожидания от роли, вовремя дать фидбек о работе, не дожидаясь окончания испытательного срока, и аргументировать свои замечания — это не станет неожиданностью для сотрудника.
Также важно публично дать команде понять, почему сотрудник был уволен. Иначе можно посеять страх в команде и испортить командную атмосферу.
Процесс найма состоит из 2х этапов — собеседование и онбординг новичка.
Онбординг должен приносить пользу не только новичку, но и проекту.
Новые люди после погружения в проект могут незамыленным взглядом увидеть проблемные участки и дать свежих идей. Поэтому мы выработали правило — осознанно выслушивать и анализировать их мнения и рекомендации по улучшению подходов и кодовой базы. Часть из этих рекомендаций успешно внедрились в проект.
Например, после прихода одного из членов Android-команды мы полностью пересмотрели подход к хранению данных в in-memory cache.
В заключение хочу сказать, что наша мобильная команда выросла до 26 человек почти за полтора года. Все разработчики хорошо справляются с задачами, и никто не ушёл из команды по собственному желанию. Мы успешно выпустили продукт и прошли испытание удалённой работой без потерь в качестве и скорости разработки.
Надеюсь, собранные в этой статье советы будут полезны и вам.
В следующих частях я расскажу про наши подходы к выбору технологического стека и настройке командного взаимодействия.
Меня зовут Владимир. Я отвечаю за мобильную разработку в Vivid Money.
Vivid Money — это финтех-стартап для европейского рынка с большим набором функционала — платежи и переводы, мультивалютность, финансовая аналитика, совместное пользование счетами, инвестиции и многое другое. Ближайшими конкурентами можно считать Revolut и N26.
Нам удалось сделать и успешно запустить мобильное финтех приложение за год. За этот год я собрал идеи, которые формировались у меня в голове около 4 лет, пока я был лидом на других проектах. В этой статье эти идеи собраны в виде советов software engineering manager’ам/лидам, которые стартуют долгосрочные и масштабные проекты с нуля.
Введение
Чуть больше года назад я пришёл на проект в роли лида Android-команды. Передо мной стояла амбициозная и интересная задача — выбрать технологии, собрать команду, настроить процессы и, самое главное, сделать всё это хорошо. Хорошо — растяжимое понятие, но для меня это качественный продукт с продуктовой и технической точки зрения.
Начинать проект с нуля — задача настолько интересная и захватывающая, насколько непонятная и сложная. Сперва не знаешь, за что хвататься, потом дел становится так много, что весь процесс работы похож на тушение пожаров.
Чтобы такого не происходило, необходимо прежде всего чётко определить приоритеты активностей.
На мой взгляд, основные активности лида можно расположить в следующем порядке:
- Выстраивание процесса найма;
- Выбор технологического стека;
- Настройка командного взаимодействия;
- Построение процесса разработки и тестирования.
В этой части статьи я остановлюсь только на первом пункте.
Дисклеймер:
В статье собраны мои размышления и выводы, основанные на моём опыте работы в больших и долгосрочных проектах. Какие-то из советов могут показаться избитыми, но, как показала практика, даже в крупных компаниях и проектах не все из них применяются.
Выстраивание найма
Для меня этот пункт стоит на первом месте, так как от “качества” людей зависит дальнейшая работа команды.
У нас был очень амбициозный срок для запуска банка — 1 год. За это время было необходимо качественно сделать огромный объём функционала. Времени на несамостоятельных, плохо обучаемых сотрудников просто не было. Отсюда вытекает следующий совет:
Совет №1. Помнить про важность найма.
Помимо того, что слабый разработчик напрямую влияет на качество кода и количество багов в продукте, на него невозможно делегировать, так как не будет полного доверия и потребуется постоянный контроль. Поэтому возникнут сложности в быстрорастущем проекте.
Совет №2. Проверять на собеседовании не только hard-скиллы, но и soft.
Зачастую собеседование разработчика в России сводится к вопросам по языку/фреймворку. На самом деле, софт-скиллы играют не менее важную роль, при этом их труднее наработать. Плюс ко всему, человек, имеющий схожий майндсет, имеет больше шансов вписаться в команду.
Для себя мы выделили следующие софт-скиллы:
- Системность мышления;
- Аккуратность и здоровый перфекционизм;
- Полагание на опыт, а не на советы; подвергание сомнению непроверенных фактов.
И, естественно, базовые неконфликтность и умение общаться с людьми.
Например, мы задаём вопрос кандидату: “Почему уходишь со старого места работы и какие у тебя критерии выбора нового места работы?”. Сам ответ не настолько важен, как важен системный подход — мы ждём, что кандидат отдаёт себе отчёт, что его не устраивает, что он смог до этого дойти логическим путём и разложить всё по полочкам в своей голове.
Примерами подобных вопросов, которые помогают нам понять майндсет и принципы кандидата, могут быть: “Как выглядит твоя идеальная команда?” или “Как выглядит идеальный процесс разработки?”.
Совет №3. Оптимизировать собеседование.
Собеседование нужно воспринимать как механизм, который можно улучшить и оптимизировать. Или как программу, которую можно отрефакторить.
Приведу примеры оптимизаций, которые мы делали.
Пример 1
На собеседование каждого кандидата уходит примерно по 1.5 часа времени двоих разработчиков. Чтобы оптимизировать это время и не тратить его на заведомо слабых кандидатов, мы ввели скрининг. Скрининг — это несколько простых, закрытых вопросов, на которые есть заготовленные ответы. Рекрутеры сами задают эти вопросы кандидату, на что у них уходит около 10-15 минут.
Немного цифр:
Из 100 кандидатов после скрининга отсеивается примерно треть, то есть около 30. Рекрутер тратит на каждый скрининг примерно 15 минут, то есть примерно 8 часов чистого времени на 30 отсеянных кандидатов. При классическом собеседовании на этих же 30 кандидатов мы бы потратили время около 60 человеко-часов в самом оптимистичном сценарии.
Пример 2
Цель собеседования — отобрать максимально релевантного кандидата. Мы проанализировали и выявили критичные для проекта hard-скиллы и навыки с учетом стека выбранных технологий, что позволило нам убрать часть нерелевантных вопросов и сократило время собеседования.
Например, мы убрали вопросы, связанные с частями Android SDK, которые не используются у нас на проекте — ContentProvider, JobScheduler и т. д. Ответы на эти вопросы не дадут нам понимания, вольётся ли он в разработку регулярных фич проекта, в которых эти части SDK используются очень редко.
Пример 3
Изначально техническое собеседование проходило в два раздельных этапа — теоретические вопросы и практические задачи. Это сильно увеличивало время прохождения всех этапов собеседования для кандидата, и много соискателей терялось, так как IT-рынок очень конкурентный — хорошим разработчикам быстро делают офферы.
Чтобы оптимизировать воронку, мы схлопнули собеседование в 1 этап — убрали неинформативные вопросы и решение алгоритмических задач. Про неинформативные вопросы я писал в предыдущем пункте. А вот алгоритмические задачи мы заменили практическими задачами по фреймворку. Они также проверяют умение писать код и одновременно знание SDK.
В итоге, осталось одно техническое собеседование на 1.5 часа, но оно стало максимально отточенным по содержанию.
Совет №4. “Понимание важнее знания”.
Самым важным критерием выбора разработчика оказалось “понимание”. Чтобы человек не просто умел давать определения и академические знания, а демонстрировал понимание устройства того или иного фреймворка. Разработчик без этого понимания, сталкиваясь с проблемами, не сможет найти решение самостоятельно или решит задачу недостаточно оптимально. Поэтому все вопросы собеседования мы сделали открытыми, чтобы кандидат не выдавал заученные термины, а рассуждал на ту или иную тему. А мы следим за его знаниями по теме и ходом его логики.
Например, мы задаём открытый вопрос: “Как сделать в Android детектор ANR (Application Not Responding)?”. Этот вопрос проверяет знание работы потоков в Android, но позволяет избежать прямого вопроса про Looper и Handler. Также он позволяет лаконично перейти на тему с многопоточностью.
Совет №5. Распределить функцию собеседований.
При быстром росте команды собеседований становится настолько много, что это занимает весь день, и не остаётся времени на остальные активности. Поэтому функцию собеседований полезно частично делегировать на команду.
Это не просто снимает нагрузку с лида, но ещё и включает разработчика в выбор своего потенциального коллеги, что его дополнительно мотивирует.
Плюс к этому, кандидат знакомится с командой и составляет для себя более целостное впечатление.
Совет №6. Сбалансировать команду по составу.
При найме всегда надо помнить про баланс людей по компетенциям в команде. Слишком много синьор-разработчиков может привести к тому, что они будут придумывать новые решения, но разработчики не будут делать фичи. Но на старте проекта, когда закладывается техническая база на годы вперёд, это необходимо. Мало того, для написания обычного кода фич, синьор будет стоить неоправданно дорого. Слишком много джуниоров, в свою очередь, ухудшит кодовую базу и, как следствие, потопит проект в долгосрочной перспективе. Однако, толковые джуниоры быстро вырастают в миддлов и становятся гораздо более лояльными к компании и команде, чем миддлы с рынка. На мой взгляд, для каждого проекта и конкретной ситуации этот баланс разный, поэтому не буду приводить конкретных процентных соотношений.
Зачастую для ускорения разработки команды разбавляют подрядчиками. Тут тоже очень важен баланс, так как большое количество подрядчиков также может ухудшить код в проекте. У подрядчиков редко можно встретить мотивацию и заинтересованность в проекте как у штатных сотрудников.
Совет №7. Не бояться увольнять.
Ну и наконец, не нужно бояться увольнять людей из команды. Человек, не подходящий команде по принципам и духу или по техническим скиллам, принесёт в долгосрочной перспективе гораздо больший вред, чем пользу от сиюминутного написания кода.
Уволить — звучит легко, а вот как это сделать максимально безболезненно для сотрудника и команды? Тут работает принцип: “Не важно, что ты сделаешь, а важно как”. Если сделать все заранее — обговорить ожидания от роли, вовремя дать фидбек о работе, не дожидаясь окончания испытательного срока, и аргументировать свои замечания — это не станет неожиданностью для сотрудника.
Также важно публично дать команде понять, почему сотрудник был уволен. Иначе можно посеять страх в команде и испортить командную атмосферу.
Совет №8. Собирать фидбек с новопришедших сотрудников.
Процесс найма состоит из 2х этапов — собеседование и онбординг новичка.
Онбординг должен приносить пользу не только новичку, но и проекту.
Новые люди после погружения в проект могут незамыленным взглядом увидеть проблемные участки и дать свежих идей. Поэтому мы выработали правило — осознанно выслушивать и анализировать их мнения и рекомендации по улучшению подходов и кодовой базы. Часть из этих рекомендаций успешно внедрились в проект.
Например, после прихода одного из членов Android-команды мы полностью пересмотрели подход к хранению данных в in-memory cache.
Итоги
В заключение хочу сказать, что наша мобильная команда выросла до 26 человек почти за полтора года. Все разработчики хорошо справляются с задачами, и никто не ушёл из команды по собственному желанию. Мы успешно выпустили продукт и прошли испытание удалённой работой без потерь в качестве и скорости разработки.
Надеюсь, собранные в этой статье советы будут полезны и вам.
В следующих частях я расскажу про наши подходы к выбору технологического стека и настройке командного взаимодействия.
