Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Привет, Хабр. Сегодня хотим поделиться с вами интервью с руководителем команды разработки одного из новых продуктов ABBYY. Мы поговорили с ним про найм, принципы построения команды, развитие разработчиков, систему грейдов и другие околопроцессные вещи, которые так или иначе затрагивают всех разработчиков и тимлидов мира. Ну или почти всех.
Лиза: Лёша, привет! Расскажи, пожалуйста, как ты попал в компанию ABBYY, как давно там работаешь?
Алексей: Всем привет! Я попал в компанию в 2008 году, будучи студентом четвёртого курса. И, по сути, человеком, которым сейчас являюсь, стал благодаря этой компании. Проработал примерно 7 лет, потом ушёл в свой стартап, но сейчас вернулся обратно, потому что в ABBYY классно.
Лиза: Расскажи немного про свой путь: кем ты начинал и кем ушёл в стартап?
Алексей: Я пришёл в ABBYY стажёром, попал в группу разработки под Linux. Мы занимались портированием движка распознавания. Довольно весёлое начало карьеры, сразу сталкиваешься с очень большим количество граблей, проходишься по ним и закаляешься.
Потом меня позвали в тимлиды в Lingvo. Я выпустил одну полноценную десктопную версию, потом ещё одну версию LingvoLive (веб-сервис и нишевая соцсеть). И после этого с позиции тимлида ушёл сооснователем в стартап. А сейчас вернулся в ABBYY и руковожу разработкой в одном из новых продуктов.
Лиза: Насколько у вас просто с общением в компании? Чтобы зайти к CTO или руководителю, надо записываться?
Алексей: Я могу спокойно зайти к CTO, если он свободен, обсудить с ним текущие вопросы. Но обычно я иду к своему руководителю.
Лиза: Ты работал и в крупной компании, и был в стартапе, где, очевидно, никакой иерархии нет, все друг другу братья. Скажи с высоты своего опыта: ABBYY ближе к красному или бирюзе?
Алексей: На мой взгляд, в ABBYY сохраняется уникальная атмосфера. Это действительно большая компания, у нас есть много разработчиков и есть хорошая иерархия. При этом нет никаких коммуникационных барьеров. Да, может, стажёры и не ходят к CTO, но им просто и не надо. Абсолютно спокойные взаимоотношения между всеми уровнями руководителей и разработчиков по линейке разработки. С этой точки зрения атмосфера не сильно отличается от стартапа. Дистанция от одного до другого не очень большая. С учётом того, что в ABBYY получается совмещать простоту коммуникации с эффективностью управления – это вообще фантастика, на мой взгляд.
Лиза: Получается, что у вас жёсткая иерархия: есть руководители, есть сотрудники? Нет, какого-то «мы не руководители, мы лидеры мнений», people-managers?
Борис: Дело в том, что у нас в Додо достаточно плоская структура, формально мой руководитель – это CTO. При этом есть leadership-team, куда входит product owner, который отвечает за продукт, а также технический лидер.
Технический лидер в Додо – человек, который не имеет непосредственных менеджерских функций, но следит за качеством продукта, помогает, обучает, советует; человек, который отвечает за людей, за развитие, атмосферу, процессы. Он — глаза и руки CTO, потому что при плоской структуре каждый из сотни разработчиков не может лично прийти к CTO.
А у вас за людей, развитие и технику отвечают одни и те же люди, или это два направления?
Алексей: У нас своеобразная структура, её можно назвать сильной матрицей. Так называются системы управления проектами, когда у вас довольно жёсткая иерархия линейного менеджмента, а проектные и продуктовые команды собираются уже из функциональных ветвей. Сила такой системы в том, что все команды собираются на достаточно продолжительное время. По сути один продукт – это одна продуктовая команда.
Довольно распространена история, когда помимо тимлида в команде есть техлид, который берёт на себя часть, связанную с техническими частями разработки, а тимлид разгружается и может уже спокойно заниматься непосредственным управлением командой. Например, у меня не такая высокая линейная нагрузка, поэтому дополнительного техлида нет, и я совмещаю функции руководства разработкой и руководства командой разработки.
Лиза: А как у вас это происходит, есть какие-то one-to-one и какие техники вы используете?
Алексей: Стандартный набор для линейного руководства – это регулярный one-to-one. Каждые две недели я встречаюсь со своими подчинёнными, примерно раз в месяц стараюсь встречаться через одного, а раз в две недели встречаюсь со своим руководителем. Это простой способ снятия текущей ситуации в команде. Он даёт понимание, что происходит и что мы можем сделать для того, чтобы как-то реагировать на проблемы или наоборот поощрять достижения. Ещё есть командные ретроспективы. Стараемся раз-два в месяц организовываться небольшими группами, предметно обсуждать, что как идёт, какие у нас есть проблемы и выбирать пути их решения.
Лиза: А есть какой-нибудь development-план, ИПР, какая-то штука по развитию человека по софтам, по хардам?
Алексей: Для каждого человека это определяет его линейный руководитель. А так у нас есть две составляющие. Одна – это глобальная система развития разработчиков в ABBYY. Схема такая: у разработчиков есть ранги и понятные требования, понятные способы оценки для перехода и повышения этого ранга, для оценки соответствия человека определённому уровню и возможностей финансового роста в компании. Как классические грейды.
Дальше задача линейного руководителя – следить за развитием своих ребят, чтобы они росли, развивались. Например, у меня тимлиды на днях закупали лицензии на онлайн-курсы. Все такие истории на линейных руководителях. Ну и я тоже забочусь о том, чтобы мои лиды смогли рано или поздно подменить меня на моем месте.
Лиза: А сколько у вас человек в разработке всего и в твоей команде в частности?
Алексей: В моей команде 14 человек, я 15-ый. И у меня две группы разработки. Обычно в группах разработки от 3 до 7-10 человек. А всего разработчиков в компании несколько сотен.
Лиза: Практически как у нас. У нас примерно 120 разработчиков, а всего больше 300 человек в команде. Можешь ли ты рассказать, по каким критериям вы смотрите соответствие человека грейдам, есть какие-то технические параметры, соответствие культурным ценностям или софты человека?
Алексей: Я не знаю людей, которые по софт скиллам не вписываются в те устоявшиеся критерии компании, которые есть. Мы и подбор ведём таким образом, чтобы люди хорошо вписывались в команду и им было у нас интересно. Дальше оценка софт скиллов отдана на откуп линейным руководителям. Его одобрение в большинстве случаев является решающим при оценке на грейд. А дальше сама оценка на грейд идёт исключительно по хардам, оцениваются те результаты работы, которые сотрудник продемонстрировал в течение работы в компании за конкретный период. Оценивается код, который он написал, задачи, которые он решал. Происходит независимая анонимная оценка экспертами и выносится решение. Достаточно стандартная история в IT, насколько я понимаю. Сложно придумать что-то отличающееся от этого.
Лиза: Мы обратили внимание, что все компании проходят примерно одинаковый путь. Когда компания поменьше, все приходят и говорят: у нас полнейший agile, делаем, что хотим. Чем взрослее компания, тем всё это сложнее становится. Без структуры уже невозможно эффективно делать разработку и управлять процессами.
Алексей: Без структуры действительно невозможно управлять, потому что, если грейдов нет, то как мы будем оценивать, достоин ли человек того, чтобы мы ему повысили зарплату.
Лиза: А с 2008 года это как-то поменялось?
Алексей: С 2008 года эта схема функционирует.
Борис: Что поменялось за твою бытность?
Алексей: За мою бытность поменялась схема организации отделов. Когда я приходил и уходил, была система, что есть технологический департамент, в котором собран весь R&D. Под R&D понимается именно исследования в сфере OCR, Capture, NLP. И были продуктовые департаменты, внутри которых уже непосредственно делались продукты. Каждый продуктовый департамент был независимым подразделением со своим директором продукта, который отвечал за всё.
У директора продукта были руководитель разработки и руководитель ОТК (отдел технического контроля). Эти позиции полностью дублировались во всех продуктовых департаментах.
Когда я снова пришёл в ABBYY, эта структура поменялась. Вся разработка – это единый механизм и деление на продукты идёт по матричной схеме. Это единственное изменение, которое произошло с организационной точки зрения.
Лиза: Сейчас резко поменяю тему, не могу удержаться и не спросить, как у вас выглядит найм? Какие этапы проходят соискатели? Недавно Борис опубликовал статью о собеседовании в Додо с описанием этапов, вдруг кому пригодится, кто захочет к нам прийти. А как это устроено у вас?
Алексей: Если оставить за рамками первичный HR-скрининг и созвон, то у нас соискатель проходит три технических интервью. Это интервью с руководителем, который набирает команду, затем с руководителем разработки и с CTO. В большинстве случаев первые два этапа объединяются в один, потому что тимлид, к которому в команду идёт человек, и руководитель разработки направления (мы его называем Development Manager) обычно проводят собеседование совместно. Таким образом количество этапов сокращается до двух.
Когда я повторно пришёл в ABBYY, у меня была проблема с наймом фронтенд-разработчиков. Потому что с момента, когда HR связывался с кандидатом, до момента интервью с CTO, проходил месяц. А для фронтенд-найма, из-за большого дефицита кадров, это было просто недопустимо. Толковые фронтендеры, выйдя на рынок, находят себе работу буквально за неделю.
Мы провели оптимизацию: договорились с CTO, что предоставляем ему полный отчёт о том, как проходило интервью. В итоге убрали ещё один этап, и сейчас есть исключительная ветка фронтендеров, когда мы действительно с одного собеседования принимаем решение – нанимать или нет. На самом собеседовании мы проводим довольно глубокую оценку технических и софт скиллов. Наловчились за полтора часа вытаскивать из человека всю нужную нам информацию.
Борис: Какие софт скиллы у меня должны быть, чтобы попасть в ABBYY? Или не должны быть?
Лиза: У нас есть рубрика «Сханти Бориса». Предлагаю поиграть и задать ему вопрос, как на реальном интервью, чтобы проверить, подходит ли Борис по софтам для ABBYY.
Алексей: Давайте попробуем. Скипнем стандартное приветствие и сразу перейдём к делу. Борис, что для тебя в работе главное?
Борис: Чтобы вставая утром на работу, ты делал это с радостью, а не с отвращением.
Алексей: Что тебе для этого нужно? Я поясню. Вставать на работу с радостью можно, работая и охранником. А что именно тебе приносит радость на работе?
Борис: Меня физический труд в общем-то манит. Если бы там платили сравнимо с разработкой, я, может, пошёл бы куда-нибудь сантехником, я неплохо умею, помогаю родителям с этим. Но касательно IT – сильная команда, в которой можно расти, интересные задачи и поменьше политики.
Алексей: А куда бы ты хотел расти?
Борис: Я бы хотел расти в технике, потому что в IT, чтобы оставаться на том уровне, ты должен быть в сильной команде. Технологии меняются, особенно во фронте. А я фулл-стек. Во фронтенд кто-то каждый день приносит новый фреймворк. И хотел бы расти в менеджменте людей: хочу научиться с самыми противными и неприятными людьми находить общий язык.
Алексей: Ты говоришь, что тебе было бы интересно расти в технической части и что технологии стремительно меняются, особенно во фронте. А как ты вообще относишься к этим нововведениям во фронтенде?
Борис: Спокойно. Это вопрос не человека и не команды, а адаптации новой технологии в компании. Хорошая компания не должна оставаться на старых технологиях только потому, что все её умеют. Новые технологии часто приносят что-то хорошее, что улучшает качество кода, разработку, работу приложения.
Нужно уметь на уровне компании отделять хорошие технологии от просто того же самого, но с другой стороны. И это должны делать ребята, которые будут этим пользоваться. Хорошая практика – это некие технические встречи, на которых тот, кто принёс, должен защитить перед такими же разработчиками идею этой новой технологии. Мне это очень импонирует. Сейчас у нас такого нет, но я бы хотел такую штуку сделать. Принёс новый фреймворк – давай, расскажи и убеди, что он лучше старого.
Алексей: Убедить, что новый фреймворк лучше старого – это несложно. Внедрение нового фреймворка – это технологический риск, скорее всего, он, решая одни проблемы, с большой вероятностью вызывает другие. Вопрос в том, на что бы ты стал смотреть при выборе нового фреймворка? Как ты примешь решение, что это годно для запуска в продакшн, а это пусть ещё подождет полгодика?
Борис: Исходя из того, что сам фреймворк нам нужен, он что-то полезное приносит, я бы посмотрел на звёздочки на Гитхабе: сколько народу скачало, какие есть баги, что о нём пишут на StackOverflow, все пытаются какие-то проблемы решить или спрашивают про функциональность? В целом, по отзывам можно составить впечатление и понять, что с этим делать.
У нас была похожая история, я рассказывал на FrontendConf про Electron. Мы его выбрали достаточно быстро, без достаточного исследования, а потом оказалось, что несмотря на кучу звёздочек и скачиваний, у него миллион проблем и тысяча багов. Реальный кейс, когда количество звёздочек и скачиваний не коррелирует с качеством кода.
Алексей: Ревью кода: на что ты смотришь обычно?
Борис: Есть общие правила, которые у нас приняты. Это касается, скорее, стиля, названия переменных, как мы пишем функции. А дальше надо посмотреть код: как человек реализовал задачу, всё равно надо в неё погружаться. Ревью – это не только про качество кода, это про шеринг знаний. Я посмотрел его код, как он решал задачу, я понимаю, что он вообще делал примерно. Если он завтра уволится, я должен смочь это подхватить.
Алексей: Расскажи про свои Definition of Done.
Борис: Если говорить про мои лично, то обязательно: код компилируется, тесты проходят. Это частая история, что код компилится, а тесты забыли поправить. И тогда я прогоняю тесты руками. В принципе такие Definition of Done и у команды – в плане того, что коммитить в общей ветке или выкладывать какие-то публично. Плюс у нас в Додо есть такое: когда задача завершена, она раскатана на тестовых пиццериях и работает.
Алексей: А при этом соответствие макетам проверяете?
Борис: До коммита в общей ветке приходит дизайнер и делает design-review.
Алексей: Что тебе не нравится на текущем месте работы, почему ты уходишь?
Борис: Я сюда приходил попробовать, и это не секрет. У меня было два оффера. Я стоял перед тем же выбором, что и большинство людей, которые приходят ко мне на собеседования в Додо. Для меня решающим фактором стал человек, который собеседует. Я понял, что с ним смогу работать безотносительно компании и задач. Мне кажется, химия, которая возникает на собеседовании, лучшая штука. Человека лучше ничего не убедит, чем приятное собеседование.
Сейчас у нас меняется структура компании, мы растём, становимся более иерархичными. Эта история про leadership-team возникла, потому что мы выросли и управлять по-старому становится тяжело. Это может стать причиной ухода не только для меня, поэтому мы стараемся над этим работать.
Алексей: Всё, я задал коротко типовые вопросы, которые обычно спрашиваю на собеседовании у людей.
Лиза: Борис прошёл к вам?
Алексей: По софт скиллам — абсолютно. Возвращаясь к вопросу Бориса о том, какие софт скиллы важны для людей – это отношение к работе и к коду, понимание того, что такое код-ревью, как и зачем делается, это отношение к текущей работе. Единственный кейс, когда мы отказывали кандидату на основе софт скиллов — это когда человек пришёл и поливал грязью текущего работодателя. Было довольно неприятно даже слушать, хотя всё преподносилось в весёлой манере.
Лиза: Лёша, мы позвали тебя, потому что птичка принесла на хвосте, что в ABBYY есть распредёленные команды, и вы знаете, как работать удалённо. Расскажи, много ли у вас работает сотрудников на удалёнке, есть ли у тебя команда на удалёнке?
Алексей: Наверное, надо начать с того, что у компании офисы в 13 странах мира. Очень большое количество коммуникаций происходит онлайн. Например, тот продукт, который мы делаем, его идеолог, вдохновитель и драйвер перманентно живет в Штатах. У нас с ним примерно по 4 совещания в неделю, поэтому я его вижу только в Zoom. Это что касается глобально компании.
Что касается нашей команды, у нас примерно 30% команды в штатном режиме работает на удалёнке (это ещё до самоизоляции и карантина). Из тех, кого мы нанимали за последнее время, 80% людей – удалёнщики, к сожалению. Поясню почему. С одной стороны, с удалённой разработкой никаких проблем нет, мы отлично, на мой взгляд, выстроили процессы коммуникации. Разработка не зависит от того, сидит человек в офисе или нет. «К сожалению» – потому что намного комфортнее прийти к сотруднику и пообщаться с ним, чисто по-человечески это приятно. Живое общение приятнее, чем общение по Skype. Сейчас этого нет, поэтому я говорю «к сожалению».
Треть команды в ABBYY – это удалёнка, и с этим не возникает никаких проблем. Чтобы люди вписывались в коллектив, мы им при трудоустройстве делаем командировки из других регионов России в головной офис в Москве, они приезжают, проводят здесь неделю. Потом периодически это повторяем: то есть примерно на неделю человек приезжает, общается с командой. Это полезный момент для адаптации. И процессы ровно такие же, как мы выстроили внутри команды, транслируются наружу для удалённых сотрудников и всё работает.
Лиза: Есть разница между процессами в удалённой команде и физически находящейся в одном месте?
Алексей: С учётом того, что в команде есть сотрудники, которые работают в офисе, и те, кто работает удалённо, мы не делали никаких различий в процессах. То есть планирование – общий митинг, на котором собирается вся команда, стендап – общий митинг, на которой собирается вся команда, часть в офисе – перед телевизором, часть подключается по удалёнке. Даже те, кто работает в офисе, периодически подключаются по удалёнке, потому что у нас в целом такое отношение, что периодически можно работать из дома.
Сейчас мы все перешли на удалённую работу и никак не поменяли наши процессы. Всё как было, ровно так и делаем. Единственно, что не встречаемся в кабинетах и переговорках, всё перевели в Zoom.
Лиза: У вас не опенспейс?
Алексей: У нас есть разные способы размещения ребят. Есть люди, которые сидят в кубиклах – такая классическая ABBYY-шная посадка, примерно 2,6 квадратных метров личного пространства. Три стены вокруг тебя, и ты видишь только человека, который может сидеть в кубикле напротив тебя.
Есть варианты, когда работают в кабинете, он рассчитан на 6-9 человек. Внутри кабинета – опенспейс. Мы командами сидим именно в таких. Это максимально комфортная история, когда соотношение свободы и общения с шумом в помещении оптимальное.
Очень много страданий из-за опенспейса. Я в своих стартапах посидел в опенспейсах на 50 человек. Нет, я не готов сажать своих ребят в такую обстановку.
Лиза: А есть ли разница между мотивацией у людей, которые работают удалённо, и которые приходят в офис? Замечал ли ты такое?
Алексей: Я бы разделил ситуацию, когда человек осознанно выбирает удалённую работу, и текущую, когда мы все вынужденно оказываемся на удалёнке. В первом случае это выбор человека, его осознанное решение, и он сам должен рассчитывать свои силы и самостоятельно вести себя так, чтобы не выгореть. Сейчас, когда мы перевели команды на удалёнку, я, проводя one-to-one, регулярно общаюсь с ребятами и спрашиваю, насколько комфортно они себя чувствуют.
В целом большинство из них отмечают, что работа из дома сильно не отличается. За счёт того что мы держали рабочий ритм, и у нас были выстроены рабочие процессы, когда мы работали все в офисе, этот рабочий ритм переносится и на сейчас. Дальше, когда у тебя есть рабочий ритм, ты выдерживаешь work-life balance. Наличие такого опыта работы в офисе очень хорошо помогает и дома выдерживать этот ритм.
Оглавление
- Давайте знакомиться
- Про сильную матрицу и атмосферу
- Про развитие разработчиков и устройство команд
- Про найм. Рубрика «Сханти Бориса»
- Про распределёнку, удалёнку и опенспейс
Сегодня с нами беседовали:
Алексей Штукатуров — Development Manager в одном из новых продуктов ABBYY.
Елизавета Швец — лидер направления IT brand в Додо.
Борис Гулай — senior-developer в Додо.
Лиза: Лёша, привет! Расскажи, пожалуйста, как ты попал в компанию ABBYY, как давно там работаешь?
Алексей: Всем привет! Я попал в компанию в 2008 году, будучи студентом четвёртого курса. И, по сути, человеком, которым сейчас являюсь, стал благодаря этой компании. Проработал примерно 7 лет, потом ушёл в свой стартап, но сейчас вернулся обратно, потому что в ABBYY классно.
Лиза: Расскажи немного про свой путь: кем ты начинал и кем ушёл в стартап?
Алексей: Я пришёл в ABBYY стажёром, попал в группу разработки под Linux. Мы занимались портированием движка распознавания. Довольно весёлое начало карьеры, сразу сталкиваешься с очень большим количество граблей, проходишься по ним и закаляешься.
Потом меня позвали в тимлиды в Lingvo. Я выпустил одну полноценную десктопную версию, потом ещё одну версию LingvoLive (веб-сервис и нишевая соцсеть). И после этого с позиции тимлида ушёл сооснователем в стартап. А сейчас вернулся в ABBYY и руковожу разработкой в одном из новых продуктов.
Про сильную матрицу и атмосферу
Лиза: Насколько у вас просто с общением в компании? Чтобы зайти к CTO или руководителю, надо записываться?
Алексей: Я могу спокойно зайти к CTO, если он свободен, обсудить с ним текущие вопросы. Но обычно я иду к своему руководителю.
Лиза: Ты работал и в крупной компании, и был в стартапе, где, очевидно, никакой иерархии нет, все друг другу братья. Скажи с высоты своего опыта: ABBYY ближе к красному или бирюзе?
Алексей: На мой взгляд, в ABBYY сохраняется уникальная атмосфера. Это действительно большая компания, у нас есть много разработчиков и есть хорошая иерархия. При этом нет никаких коммуникационных барьеров. Да, может, стажёры и не ходят к CTO, но им просто и не надо. Абсолютно спокойные взаимоотношения между всеми уровнями руководителей и разработчиков по линейке разработки. С этой точки зрения атмосфера не сильно отличается от стартапа. Дистанция от одного до другого не очень большая. С учётом того, что в ABBYY получается совмещать простоту коммуникации с эффективностью управления – это вообще фантастика, на мой взгляд.
Лиза: Получается, что у вас жёсткая иерархия: есть руководители, есть сотрудники? Нет, какого-то «мы не руководители, мы лидеры мнений», people-managers?
Борис: Дело в том, что у нас в Додо достаточно плоская структура, формально мой руководитель – это CTO. При этом есть leadership-team, куда входит product owner, который отвечает за продукт, а также технический лидер.
Технический лидер в Додо – человек, который не имеет непосредственных менеджерских функций, но следит за качеством продукта, помогает, обучает, советует; человек, который отвечает за людей, за развитие, атмосферу, процессы. Он — глаза и руки CTO, потому что при плоской структуре каждый из сотни разработчиков не может лично прийти к CTO.
А у вас за людей, развитие и технику отвечают одни и те же люди, или это два направления?
Алексей: У нас своеобразная структура, её можно назвать сильной матрицей. Так называются системы управления проектами, когда у вас довольно жёсткая иерархия линейного менеджмента, а проектные и продуктовые команды собираются уже из функциональных ветвей. Сила такой системы в том, что все команды собираются на достаточно продолжительное время. По сути один продукт – это одна продуктовая команда.
Довольно распространена история, когда помимо тимлида в команде есть техлид, который берёт на себя часть, связанную с техническими частями разработки, а тимлид разгружается и может уже спокойно заниматься непосредственным управлением командой. Например, у меня не такая высокая линейная нагрузка, поэтому дополнительного техлида нет, и я совмещаю функции руководства разработкой и руководства командой разработки.
Лиза: А как у вас это происходит, есть какие-то one-to-one и какие техники вы используете?
Алексей: Стандартный набор для линейного руководства – это регулярный one-to-one. Каждые две недели я встречаюсь со своими подчинёнными, примерно раз в месяц стараюсь встречаться через одного, а раз в две недели встречаюсь со своим руководителем. Это простой способ снятия текущей ситуации в команде. Он даёт понимание, что происходит и что мы можем сделать для того, чтобы как-то реагировать на проблемы или наоборот поощрять достижения. Ещё есть командные ретроспективы. Стараемся раз-два в месяц организовываться небольшими группами, предметно обсуждать, что как идёт, какие у нас есть проблемы и выбирать пути их решения.
Про развитие разработчиков и устройство команд
Лиза: А есть какой-нибудь development-план, ИПР, какая-то штука по развитию человека по софтам, по хардам?
Алексей: Для каждого человека это определяет его линейный руководитель. А так у нас есть две составляющие. Одна – это глобальная система развития разработчиков в ABBYY. Схема такая: у разработчиков есть ранги и понятные требования, понятные способы оценки для перехода и повышения этого ранга, для оценки соответствия человека определённому уровню и возможностей финансового роста в компании. Как классические грейды.
Дальше задача линейного руководителя – следить за развитием своих ребят, чтобы они росли, развивались. Например, у меня тимлиды на днях закупали лицензии на онлайн-курсы. Все такие истории на линейных руководителях. Ну и я тоже забочусь о том, чтобы мои лиды смогли рано или поздно подменить меня на моем месте.
Лиза: А сколько у вас человек в разработке всего и в твоей команде в частности?
Алексей: В моей команде 14 человек, я 15-ый. И у меня две группы разработки. Обычно в группах разработки от 3 до 7-10 человек. А всего разработчиков в компании несколько сотен.
Лиза: Практически как у нас. У нас примерно 120 разработчиков, а всего больше 300 человек в команде. Можешь ли ты рассказать, по каким критериям вы смотрите соответствие человека грейдам, есть какие-то технические параметры, соответствие культурным ценностям или софты человека?
Алексей: Я не знаю людей, которые по софт скиллам не вписываются в те устоявшиеся критерии компании, которые есть. Мы и подбор ведём таким образом, чтобы люди хорошо вписывались в команду и им было у нас интересно. Дальше оценка софт скиллов отдана на откуп линейным руководителям. Его одобрение в большинстве случаев является решающим при оценке на грейд. А дальше сама оценка на грейд идёт исключительно по хардам, оцениваются те результаты работы, которые сотрудник продемонстрировал в течение работы в компании за конкретный период. Оценивается код, который он написал, задачи, которые он решал. Происходит независимая анонимная оценка экспертами и выносится решение. Достаточно стандартная история в IT, насколько я понимаю. Сложно придумать что-то отличающееся от этого.
Лиза: Мы обратили внимание, что все компании проходят примерно одинаковый путь. Когда компания поменьше, все приходят и говорят: у нас полнейший agile, делаем, что хотим. Чем взрослее компания, тем всё это сложнее становится. Без структуры уже невозможно эффективно делать разработку и управлять процессами.
Алексей: Без структуры действительно невозможно управлять, потому что, если грейдов нет, то как мы будем оценивать, достоин ли человек того, чтобы мы ему повысили зарплату.
Лиза: А с 2008 года это как-то поменялось?
Алексей: С 2008 года эта схема функционирует.
Борис: Что поменялось за твою бытность?
Алексей: За мою бытность поменялась схема организации отделов. Когда я приходил и уходил, была система, что есть технологический департамент, в котором собран весь R&D. Под R&D понимается именно исследования в сфере OCR, Capture, NLP. И были продуктовые департаменты, внутри которых уже непосредственно делались продукты. Каждый продуктовый департамент был независимым подразделением со своим директором продукта, который отвечал за всё.
У директора продукта были руководитель разработки и руководитель ОТК (отдел технического контроля). Эти позиции полностью дублировались во всех продуктовых департаментах.
Когда я снова пришёл в ABBYY, эта структура поменялась. Вся разработка – это единый механизм и деление на продукты идёт по матричной схеме. Это единственное изменение, которое произошло с организационной точки зрения.
Про найм. Рубрика «Сханти Бориса»
Лиза: Сейчас резко поменяю тему, не могу удержаться и не спросить, как у вас выглядит найм? Какие этапы проходят соискатели? Недавно Борис опубликовал статью о собеседовании в Додо с описанием этапов, вдруг кому пригодится, кто захочет к нам прийти. А как это устроено у вас?
Алексей: Если оставить за рамками первичный HR-скрининг и созвон, то у нас соискатель проходит три технических интервью. Это интервью с руководителем, который набирает команду, затем с руководителем разработки и с CTO. В большинстве случаев первые два этапа объединяются в один, потому что тимлид, к которому в команду идёт человек, и руководитель разработки направления (мы его называем Development Manager) обычно проводят собеседование совместно. Таким образом количество этапов сокращается до двух.
Когда я повторно пришёл в ABBYY, у меня была проблема с наймом фронтенд-разработчиков. Потому что с момента, когда HR связывался с кандидатом, до момента интервью с CTO, проходил месяц. А для фронтенд-найма, из-за большого дефицита кадров, это было просто недопустимо. Толковые фронтендеры, выйдя на рынок, находят себе работу буквально за неделю.
Мы провели оптимизацию: договорились с CTO, что предоставляем ему полный отчёт о том, как проходило интервью. В итоге убрали ещё один этап, и сейчас есть исключительная ветка фронтендеров, когда мы действительно с одного собеседования принимаем решение – нанимать или нет. На самом собеседовании мы проводим довольно глубокую оценку технических и софт скиллов. Наловчились за полтора часа вытаскивать из человека всю нужную нам информацию.
Борис: Какие софт скиллы у меня должны быть, чтобы попасть в ABBYY? Или не должны быть?
Лиза: У нас есть рубрика «Сханти Бориса». Предлагаю поиграть и задать ему вопрос, как на реальном интервью, чтобы проверить, подходит ли Борис по софтам для ABBYY.
Алексей: Давайте попробуем. Скипнем стандартное приветствие и сразу перейдём к делу. Борис, что для тебя в работе главное?
Борис: Чтобы вставая утром на работу, ты делал это с радостью, а не с отвращением.
Алексей: Что тебе для этого нужно? Я поясню. Вставать на работу с радостью можно, работая и охранником. А что именно тебе приносит радость на работе?
Борис: Меня физический труд в общем-то манит. Если бы там платили сравнимо с разработкой, я, может, пошёл бы куда-нибудь сантехником, я неплохо умею, помогаю родителям с этим. Но касательно IT – сильная команда, в которой можно расти, интересные задачи и поменьше политики.
Алексей: А куда бы ты хотел расти?
Борис: Я бы хотел расти в технике, потому что в IT, чтобы оставаться на том уровне, ты должен быть в сильной команде. Технологии меняются, особенно во фронте. А я фулл-стек. Во фронтенд кто-то каждый день приносит новый фреймворк. И хотел бы расти в менеджменте людей: хочу научиться с самыми противными и неприятными людьми находить общий язык.
Алексей: Ты говоришь, что тебе было бы интересно расти в технической части и что технологии стремительно меняются, особенно во фронте. А как ты вообще относишься к этим нововведениям во фронтенде?
Борис: Спокойно. Это вопрос не человека и не команды, а адаптации новой технологии в компании. Хорошая компания не должна оставаться на старых технологиях только потому, что все её умеют. Новые технологии часто приносят что-то хорошее, что улучшает качество кода, разработку, работу приложения.
Нужно уметь на уровне компании отделять хорошие технологии от просто того же самого, но с другой стороны. И это должны делать ребята, которые будут этим пользоваться. Хорошая практика – это некие технические встречи, на которых тот, кто принёс, должен защитить перед такими же разработчиками идею этой новой технологии. Мне это очень импонирует. Сейчас у нас такого нет, но я бы хотел такую штуку сделать. Принёс новый фреймворк – давай, расскажи и убеди, что он лучше старого.
Алексей: Убедить, что новый фреймворк лучше старого – это несложно. Внедрение нового фреймворка – это технологический риск, скорее всего, он, решая одни проблемы, с большой вероятностью вызывает другие. Вопрос в том, на что бы ты стал смотреть при выборе нового фреймворка? Как ты примешь решение, что это годно для запуска в продакшн, а это пусть ещё подождет полгодика?
Борис: Исходя из того, что сам фреймворк нам нужен, он что-то полезное приносит, я бы посмотрел на звёздочки на Гитхабе: сколько народу скачало, какие есть баги, что о нём пишут на StackOverflow, все пытаются какие-то проблемы решить или спрашивают про функциональность? В целом, по отзывам можно составить впечатление и понять, что с этим делать.
У нас была похожая история, я рассказывал на FrontendConf про Electron. Мы его выбрали достаточно быстро, без достаточного исследования, а потом оказалось, что несмотря на кучу звёздочек и скачиваний, у него миллион проблем и тысяча багов. Реальный кейс, когда количество звёздочек и скачиваний не коррелирует с качеством кода.
Алексей: Ревью кода: на что ты смотришь обычно?
Борис: Есть общие правила, которые у нас приняты. Это касается, скорее, стиля, названия переменных, как мы пишем функции. А дальше надо посмотреть код: как человек реализовал задачу, всё равно надо в неё погружаться. Ревью – это не только про качество кода, это про шеринг знаний. Я посмотрел его код, как он решал задачу, я понимаю, что он вообще делал примерно. Если он завтра уволится, я должен смочь это подхватить.
Алексей: Расскажи про свои Definition of Done.
Борис: Если говорить про мои лично, то обязательно: код компилируется, тесты проходят. Это частая история, что код компилится, а тесты забыли поправить. И тогда я прогоняю тесты руками. В принципе такие Definition of Done и у команды – в плане того, что коммитить в общей ветке или выкладывать какие-то публично. Плюс у нас в Додо есть такое: когда задача завершена, она раскатана на тестовых пиццериях и работает.
Алексей: А при этом соответствие макетам проверяете?
Борис: До коммита в общей ветке приходит дизайнер и делает design-review.
Алексей: Что тебе не нравится на текущем месте работы, почему ты уходишь?
Борис: Я сюда приходил попробовать, и это не секрет. У меня было два оффера. Я стоял перед тем же выбором, что и большинство людей, которые приходят ко мне на собеседования в Додо. Для меня решающим фактором стал человек, который собеседует. Я понял, что с ним смогу работать безотносительно компании и задач. Мне кажется, химия, которая возникает на собеседовании, лучшая штука. Человека лучше ничего не убедит, чем приятное собеседование.
Сейчас у нас меняется структура компании, мы растём, становимся более иерархичными. Эта история про leadership-team возникла, потому что мы выросли и управлять по-старому становится тяжело. Это может стать причиной ухода не только для меня, поэтому мы стараемся над этим работать.
Алексей: Всё, я задал коротко типовые вопросы, которые обычно спрашиваю на собеседовании у людей.
Лиза: Борис прошёл к вам?
Алексей: По софт скиллам — абсолютно. Возвращаясь к вопросу Бориса о том, какие софт скиллы важны для людей – это отношение к работе и к коду, понимание того, что такое код-ревью, как и зачем делается, это отношение к текущей работе. Единственный кейс, когда мы отказывали кандидату на основе софт скиллов — это когда человек пришёл и поливал грязью текущего работодателя. Было довольно неприятно даже слушать, хотя всё преподносилось в весёлой манере.
Про распределёнку, удалёнку и опенспейс
Disclaimer: мы записывали этот разговор до карантина и тотальной удалёнки. Сейчас многие стали уметь распределённо и удалённо, ниже мы описываем, как было в ABBYY до того, как это стало мировой необходимостью.
Лиза: Лёша, мы позвали тебя, потому что птичка принесла на хвосте, что в ABBYY есть распредёленные команды, и вы знаете, как работать удалённо. Расскажи, много ли у вас работает сотрудников на удалёнке, есть ли у тебя команда на удалёнке?
Алексей: Наверное, надо начать с того, что у компании офисы в 13 странах мира. Очень большое количество коммуникаций происходит онлайн. Например, тот продукт, который мы делаем, его идеолог, вдохновитель и драйвер перманентно живет в Штатах. У нас с ним примерно по 4 совещания в неделю, поэтому я его вижу только в Zoom. Это что касается глобально компании.
Что касается нашей команды, у нас примерно 30% команды в штатном режиме работает на удалёнке (это ещё до самоизоляции и карантина). Из тех, кого мы нанимали за последнее время, 80% людей – удалёнщики, к сожалению. Поясню почему. С одной стороны, с удалённой разработкой никаких проблем нет, мы отлично, на мой взгляд, выстроили процессы коммуникации. Разработка не зависит от того, сидит человек в офисе или нет. «К сожалению» – потому что намного комфортнее прийти к сотруднику и пообщаться с ним, чисто по-человечески это приятно. Живое общение приятнее, чем общение по Skype. Сейчас этого нет, поэтому я говорю «к сожалению».
Треть команды в ABBYY – это удалёнка, и с этим не возникает никаких проблем. Чтобы люди вписывались в коллектив, мы им при трудоустройстве делаем командировки из других регионов России в головной офис в Москве, они приезжают, проводят здесь неделю. Потом периодически это повторяем: то есть примерно на неделю человек приезжает, общается с командой. Это полезный момент для адаптации. И процессы ровно такие же, как мы выстроили внутри команды, транслируются наружу для удалённых сотрудников и всё работает.
Лиза: Есть разница между процессами в удалённой команде и физически находящейся в одном месте?
Алексей: С учётом того, что в команде есть сотрудники, которые работают в офисе, и те, кто работает удалённо, мы не делали никаких различий в процессах. То есть планирование – общий митинг, на котором собирается вся команда, стендап – общий митинг, на которой собирается вся команда, часть в офисе – перед телевизором, часть подключается по удалёнке. Даже те, кто работает в офисе, периодически подключаются по удалёнке, потому что у нас в целом такое отношение, что периодически можно работать из дома.
Сейчас мы все перешли на удалённую работу и никак не поменяли наши процессы. Всё как было, ровно так и делаем. Единственно, что не встречаемся в кабинетах и переговорках, всё перевели в Zoom.
Лиза: У вас не опенспейс?
Алексей: У нас есть разные способы размещения ребят. Есть люди, которые сидят в кубиклах – такая классическая ABBYY-шная посадка, примерно 2,6 квадратных метров личного пространства. Три стены вокруг тебя, и ты видишь только человека, который может сидеть в кубикле напротив тебя.
Есть варианты, когда работают в кабинете, он рассчитан на 6-9 человек. Внутри кабинета – опенспейс. Мы командами сидим именно в таких. Это максимально комфортная история, когда соотношение свободы и общения с шумом в помещении оптимальное.
Очень много страданий из-за опенспейса. Я в своих стартапах посидел в опенспейсах на 50 человек. Нет, я не готов сажать своих ребят в такую обстановку.
Лиза: А есть ли разница между мотивацией у людей, которые работают удалённо, и которые приходят в офис? Замечал ли ты такое?
Алексей: Я бы разделил ситуацию, когда человек осознанно выбирает удалённую работу, и текущую, когда мы все вынужденно оказываемся на удалёнке. В первом случае это выбор человека, его осознанное решение, и он сам должен рассчитывать свои силы и самостоятельно вести себя так, чтобы не выгореть. Сейчас, когда мы перевели команды на удалёнку, я, проводя one-to-one, регулярно общаюсь с ребятами и спрашиваю, насколько комфортно они себя чувствуют.
В целом большинство из них отмечают, что работа из дома сильно не отличается. За счёт того что мы держали рабочий ритм, и у нас были выстроены рабочие процессы, когда мы работали все в офисе, этот рабочий ритм переносится и на сейчас. Дальше, когда у тебя есть рабочий ритм, ты выдерживаешь work-life balance. Наличие такого опыта работы в офисе очень хорошо помогает и дома выдерживать этот ритм.
Подкаст «Ничего такого». Эта статья — расшифровка одного из выпусков нашего подкаста. Нам стало интересно как выглядит культура, строятся команды и процессы в разных технологических компаниях вроде Miro, Яндекса, Amazon, Microsoft, Едадила. Поэтому мы встретились с ребятами оттуда и поболтали на эти темы.
Полную версию выпуска с ABBYY можно послушать:
- SoundCloud
- Apple Podcasts
- Google Podcasts
- Яндекс.Музыка
- Spotify
- VK
- Или скачать в нашем канале в Telegram.
