Привет. Вот уже полгода с хвостиком я Head of Backend в компании Scalable Solutions, руковожу разработкой бэкенда, который связывает в одно целое большое количество подсистем внутри трейдинговой платформы и обеспечивает коммуникацию между брокерами и миллионами пользователей. Хочу рассказать про свой путь в разработке и управлении разработкой – как дошел до глобального финтеха, чему учился (и до сих пор учусь), что меня мотивировало на разных этапах, какого стиля руководства придерживаюсь сейчас и почему. Надеюсь, кому-то будет интересно, а возможно, даже полезно.
В качестве вступления я решил выбрать эту картинку. Увидев ее впервые году так в 2012 или 2013 я сразу понял, что хочу стать правильным руководителем.
Из колхозной молодежи панковал (зачеркнуто) программировал один лишь я
Большую часть своей жизни я провел в небольшом селе на юге России. Впервые с программированием столкнулся на уроках физики: у нас были БКшки, на которых можно было писать на Basic простенькие программы и даже игры. Потом были трехмесячные курсы от службы занятости по Delphi, на которых я начал постигать удивительный мир разработки софта. Правда, после этих курсов я мог не очень много: клепать формочки и писать немного логики.
В селе достать какую-нибудь литературу было крайне тяжело – интернета не было, книг по разработке в библиотеке не водилось. В ближайших городах также особо достать ничего не получалось. Была у меня электронная библиотека (не помню, откуда я её вообще взял), там были книги/статьи по Линуксу и языку C. Так вот и изучал потихоньку. Линукс вообще меня очень влек к себе, и когда я наконец-то нашел диск с ним, я был просто счастлив – винда исчезла с моего домашнего компьютера бесследно.
Году так в 2007 я узнал, что такое Qt, и нашел отличный форум, посвященный этой библиотеке. Как любой уважающий себя разработчик, я начал писать свои супер-пупер текстовый редактор и файловый менеджер. Кстати, второй даже сейчас можно запустить, правда, качество кода там ужасное. Самое классное, что к написанию ФМ подключился один разработчик с форума. Он показал мне, что такое git, как разрабатывать совместно, и вообще, научил меня куче всяких премудростей.
На заметку. Ищите наставника, это самый быстрый способ научиться.
В дальнейшем я был наставником для большого количества людей, возвращал свой долг, распространяя знания.
Работать я начал специалистом службы автоматизации и технического обеспечения в Отделе соц. защиты. Звучит внушительно, но на деле обычный эникей – принеси-подай, сгоняй к бухгалтерам, у них опять винда не грузится. Но в свободное время на том же Delphi, а позднее на C++Builder (а еще позднее Qt), я упрощал жизнь себе и коллегам: автоматизировал рутину, формировал всякие выборки для отчетов. Тогда же написал первую многопользовательскую программу, которая брала данные из FoxPro’шных баз, сливала их в Postgres и предоставляла удобный интерфейс для выборок информации.
Ко всему прочему, у меня была возможность наблюдать за управлением нашего отдела. Заведующая была примером хорошего руководителя.
А еще руководитель должен быть внимательным – подмечать все, что происходит, и реагировать, когда это необходимо. И самое главное, руководитель должен быть примером для своих подчиненных.
На хрен, брошу всё хозяйство и уеду в город я
В 2010 я закончил заочно институт и решил, что пора ехать в большой город, начинать работать по профессии. Откликнулся на несколько вакансий, выполнил тестовое задание и меня взяли.
Я переехал в большой город и наконец-то получил доступ к книгам. Ох… Есть в Питере такое место – ДК им. Крупской – там находится книжная ярмарка, и есть несколько точек, где продается техническая литература. Я туда периодически наведывался и уходил каждый раз с двумя большими авоськами книг. Поездка в метро на работу/с работы давала как минимум 2 часа в день на чтение, и в Крупу я ездил раз в несколько месяцев за пополнением моей библиотеки. Читал я всё – от книг по языкам программирования и алгоритмам, до книг по менеджменту и подходам к разработке. Прочитал всего Дядюшку Боба, Кента Бека и еще кучу других авторов. Всё-таки книги – это одна из самых важных вещей для самообучения.
Мне посчастливилось встретить примеры как плохих, так и хороших руководителей. Огромным сюрпризом было для меня, когда после нескольких месяцев работы я встретился в коридоре с Генеральным (которого я видел только мельком пару раз), и он сказал мне «Здравствуй, Костя. Как твои дела?». Было очень удивительно и приятно, что Генеральный знает по имени меня, простого разработчика.
Примером плохого руководителя был мой непосредственный начальник. Вот несколько вещей, которые я усвоил благодаря ему:
Необходимо обязательно следить за тем, что делает твой подчиненный. Даже если это заказная утилита от другого отдела, руководитель должен оценить проделанную работу и дать обратную связь.
Необходимо регулярно проводить 1-1 встречи, так как сотрудник, у которого нет обратной связи от руководителя, может решить, что он не особо и нужен.
Необходимо быть рядом со своей командой, а не сидеть отгородившись в отдельном кабинете.
К сожалению, через пару лет я понял, что учиться мне разработке в компании не у кого, и решил уйти. Но меня оставили еще на год повышением з/п и тем, что дали в руководство отдел. Тут я впервые узнал, что такое собеседования и управление разработчиками. Их было 3 под моим началом. Сейчас, оглядываясь, я понимаю, что занимался микроменеджментом, не давая своим работникам особой свободы. Несмотря на всё, это был хороший опыт.
В следующей компании мне повезло встретиться с разработчиками, которые были и умнее, и опытнее меня. А еще они знали много вещей за пределами моей области знаний, что помогло мне расширить эту область. Я узнал, что такое python, как разрабатывается web. Но так же я в очередной раз увидел, что такое плохой руководитель, и познал, какой отвратительный код могут писать твои коллеги, и как с этим можно бороться или мириться. Я впервые увидел функцию на 2К строк, в которой была куча макросов, каждый из которых разворачивался еще на N сотен строк.
Проработал я там ровно год и свалил. Причем нас тогда несколько человек ушло – надоело заниматься чем-то непонятным.
Однажды мне предложили работу в стартапе, с переездом на юг, и после совещания с супругой мы переехали. Стартап на деле оказался галерой со всеми вытекающими: я был мастером на все руки – бэк, фронт, архитектура, ci/cd, управление джунами и куча всего остального. У меня получилось выстроить более-менее хорошую архитектуру (которая сохранилась там и по сей день) и обучить несколько джунов, но года через 3 я понял, что пора уходить.
Ушел я в зарубежную компанию, и это был очень интересный опыт. Во-первых, мне пришлось в короткие сроки выучить английский язык, так как вся коммуникация велась на нем. У меня за плечами был только школьный базис, причем ужасного качества (учился я все-таки в сельской школе). Помогли месячные онлайн-курсы и приложение Anki, как способ пополнения словарного запаса. А так же фильмы и книги в оригинале. Во-вторых, был переход на Go, который я до этого только пару раз использовал в качестве хобби. К счастью, если ты знаешь C++, то другие языки выучить проблемы большой не составляет, а тем более такой простой язык как Go.
С течением времени я понял, что хочу развиваться в менеджмент. Меня привлекало управление и архитектура, а не написание кода. К сожалению, все мои попытки расширить свою зону ответственности не встречали одобрения начальства, и я решил уйти, хоть это было и очень тяжелым решением – мне работа в компании нравилась.
Чему я научился в этой компании:
Если под твоим началом работают сильные специалисты, ты не можешь просто так навязывать свое решение, ты должен его обосновать. Наш руководитель это классно делал, и мы в большинстве случаев принимали его решение. Пару раз мы его переубеждали, и он соглашался с нашим мнением, из чего можно вывести следующий пункт.
Ты должен уметь признавать свои ошибки.
Нам всё нипочём, через левое плечо плюнем и пойдём через туман
В июне 2021 года я перешел в Scalable Solutions на должность разработчика, но сразу оговорил с Head’ом, что я хочу развиваться в сторону TeamLead’а. Собственно, этим развитием я и стал заниматься сразу же, как пришел – брал на себя дополнительные задачи, делал ревью всех МРов, которые мне попадались, участвовал во всех обсуждениях и аккумулировал всю доступную информацию, до которой мог дотянуться. Почти сразу же Head позвал меня на участие в технических интервью. Поначалу я брал на себя часть вопросов по БД, но уже через несколько собесов я сам стал их проводить, а Head только слушал и принимал финальное решение. К слову о собеседованиях, они у нас довольно сложные (до финала доходит 3-7% кандидатов), так как в команду мы набираем только senior специалистов.
Помимо собеседований, я стал брать на себя менеджерские задачи, чтобы разгрузить от них Head’а. Я делал декомпозицию и эстимейт поступающих задач, а также делился своим мнением по поводу их реализации. Подписался на все каналы в Слаке, которые были доступны, и впитывал в себя всю поступающую информацию. В общем, старался как мог.
TeamLead’ом я так и не стал.
В декабре наш Head покинул компанию, и мне предложили занять эту должность. Я согласился. Я понимал, что будет тяжело, но не знал тогда, что настолько. Толком не зная всей системы и структуры компании, я получил в управление целый отдел с 10 senior разработчиками. А еще получил несколько продуктовых задач, которые необходимо было сдать в течение месяца.
Я боялся, что команда меня не примет, но, к моей огромной радости, мне сразу же после назначения написали несколько коллег и сказали, что помогут мне со всем этим справиться. Большое им спасибо, мы справились и сдали проекты в срок.
Прошло уже 7 месяцев, как я принял эту должность. Не сказал бы, что у меня все получается, но я работаю над этим. Я взял в команду еще несколько человек, провел реорганизацию – разбил команду на несколько и назначил в каждой тимлида. Теперь учусь делегировать работу тимлидам, а сам только контролировать процесс и заниматься верхнеуровневыми задачами. Под моим началом уже около 20 человек и мы все еще набираем разработчиков.
Когда меня спрашивают, что меня мотивирует, у меня сразу возникает только один ответ – моя команда. Я рад работать в команде с высококлассными специалистами. Мне есть, у кого учиться, и есть, кому передать мой опыт.
Вот краткий перечень того, с какими сложностями и челленджами я столкнулся в Scalable и на должности Head’а:
Стиль кода. Мой подход всегда был очень жестким, когда дело касалось стиля кода (привет, С++). Я считал, что все должны писать одинаковый код, дабы его было легче поддерживать. Даже минимальные отклонения не допускались, всё выносилось в style-guide и проверялось на ревью. Тут же я пришел в команду, где, во-первых, не было style-guide, во-вторых, был легаси, а в-третьих, было много профессионалов, которые писали как кто привык. Даже Go с его простотой позволяет писать код по-разному. Пришлось мне привыкнуть. Конечно, при помощи дипломатии я сгладил некоторые моменты, которые сильно бесили, но в остальном я теперь сдержанно отношусь к чужому коду и призываю своих коллег делать так же.
Легаси архитектура. Сколько фэйспалмы не бей, а приходится разбираться в том, что досталось по наследству, и стараться это не сломать. К счастью, предыдущий Head проделал большую работу с переводом сервисов на gRPC и приведением их к общему виду, но все равно еще есть места, где приходится работать аккуратно, чтобы минимизировать риск поломать какой-либо из сервисов.
Конфликты. Если раньше я мог спокойно взять попкорн и смотреть на конфликты моих коллег, то теперь мне приходится их разруливать, чтобы никто не был обижен, и это не сказалось на работоспособности всей команды. К счастью, конфликты достаточно редки.
Я теперь не пишу код. Вообще. Я думал, это будет тяжело, но, как оказалось, мои задачи так же интересны, если не более. Иногда все-таки я расчехляю IDE и что-то делаю, если задача срочная, а все заняты. Но это бывает редко.
Приходится очень часто переключать контекст. Разработчику легко – получил задачу и работаешь над ней. Тут же приходится работать над несколькими задачами одновременно, при чем тебя могут интерапнуть в любой момент, и ты должен быстро переключить контекст, чтобы ответить.
Раньше я читал все письма и сообщения, как только они приходили. Сейчас их стало так много, что разгребать их получается только ночью или на следующее утро. Поначалу это было тяжело, иконка с количеством непрочитанных сообщений сводила с ума. Потом привык.
Несколько моментов, которых я придерживаюсь как руководитель:
Моя самая главная задача – облегчить работу команды. Я должен сделать все возможное, чтобы каждый член команды мог заниматься своей работой.
Мне необходимо делать так, чтобы каждый разработчик считал себя частью всей команды.
Текучка недопустима – я должен делать всё, чтобы у разработчика и мысли не было искать другую работу. Отобрать паспорт или приковать к рабочему месту я не могу, приходится искать другие пути.
Нельзя держать сотрудника на однотипных задачах, необходимо разнообразие.
Необходимо проводить регулярные 1-1 встречи, чтобы видеть состояние работника и понять вовремя, как ему можно помочь.
Если есть конфликтный вопрос, часто обе стороны по-своему правы, и нельзя склонить чашу весов на чью-либо сторону. Руководитель должен поставить точку, выбрав один из вариантов или предложив свой.
Спасибо тем, кто прочитал эту статью до конца. Если материал понравился, напишу в следующей статье, как мы проводим найм и онбординг в нашей команде. А еще я хочу сказать огромное спасибо всем, кто помогал мне на этом пути: советом, примером (в том числе негативным), да и просто поддержкой.
Ну и куда же без книг, конечно
Вот небольшой список, который я могу порекомендовать коллегам по цеху.
С. Макконнелл – «Совершенный код»
А. Александреску – «Стандарты программирования на C++»
Г. Саттер – все книги
Кент Бек – все книги
Р. Мартин (ака Дядюшка Боб) – все книги
Ф. Брукс – «Мифический человеко-месяц»
М. Фаулер – «Рефакторинг: улучшение проекта существующего кода», «Шаблоны корпоративных приложений», «UML. Основы. Краткое руководство по унифицированноме языку моделирования»
Дж. Ханк Рейнвотер – «Как пасти котов»
Г. Кеннеди – «Договориться можно обо всем»
Э. Хант, Д. Томас – «Программист-прагматик. Путь от подмастерья к мастеру»
С. Кови – «7 навыков высокоэффективных людей»
Т. ДеМарко – «Deadline. Роман об управлении проектами»
Еще по теме:
Тестирование финтех бэкенда: как мы дошли до 20 тыс. тест-кейсов
Как устроен криптотрейдинг, с какими рисками нужно считаться, и в чем был прав Марк Твен
