Зимой 2012-го коллега предложил мне, С++ программисту с пятилетним стажем, написать первое приложение под Android. Ещё через год я начал руководить небольшой командой мобильных разработчиков, и с тех пор размеры моих команд стабильно росли. Но в прошлом году, после 2 лет руководства отделом мобильной разработки, я снова сдул пыль с любимой IDE.



Давайте расскажу, как было на той стороне, почему я вернулся в разработчики в возрасте 30+ (спойлер) и не жалею об этом.

Путь в Android-разработчики

Android, который был в то время диковинкой в моём провинциальном городе, казался мне очередной забавной “игрушкой”, поиграв в которую, можно было безболезненно её бросить и вернуться к привычному Qt. Так все и закрутилось: знакомый подкинул идею простого приложения для учёта доходов и расходов, мы стали пилить его в свободное время, а через полгода MVP было готово к публикации.


У нашего Money Keeper был довольно примитивный дизайн, но достаточно продуманный UX: доход или расход записывался в один клик — тап по иконке категории сразу открывал окно ввода суммы.

Я очень хорошо помню, как увидел статистику по скачиваниям: первым человеком, который загрузил моё приложение, был некто из Египта. И этот некто не удалил приложение на той же неделе, а продолжал им пользоваться!

Понемногу, по несколько десятков скачиваний в день, аудитория росла, рос рейтинг, появились первые положительные отзывы. Сказать, что это окрыляло — значит преуменьшить. Я отвечал на отзывы в маркете, планировал дальнейшую разработку на основе пожеланий пользователей, просто потому что моё приложение нужно пользователям, они благодарят и ставят пятёрки. А вся наша реклама заключалась в единственном посте на 4pda.

И ещё поражало, насколько сильно мобильная разработка отличается от разработки встраиваемых систем и desktop-приложений, которой я занимался до этого. Путь приложения до пользователя и его фидбека обратно очень короток. Аудитория огромна, и всё, что ты делаешь, ты должен делать как минимум хорошо, иначе приложение не будет никому нужно, и все труды можно будет выбросить.

Как я стал тимлидом, «потому_что_ну_кто-то_же_должен»

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

От идеи “заморозить” бесплатное приложение ради платного мы отказались, потому что не хотели подводить благодарное сообщество пользователей, у которого мы всё это время черпали энергию и идеи для развития. Поэтому решили взять на небольшую зарплату двух ребят, которые были далеки от разработки, и горели тем, чтобы в неё ворваться. Было решено провести их по моему пути, но с существенным отличием: я должен был научить их передвигаться и ориентироваться в мире зелёного робота и показать им все известные мне кочки и ямы на этой дороге.


Я не боялся браться за сложные задачи)

Я хотел, чтобы другие люди разделили мой восторг от разработки, да и две пары рук были нам явно не лишними. Я ездил к ним домой, объяснял, учил, советовал, помогал. Ставил задачи и проверял их выполнение. Так я незаметно для себя стал небольшим, но менеджером.

Приложение, правда, пришлось закрыть… Я пошел в стартап, потом ещё в один, потом пришёл в продуктовую разработку в крупный бизнес. Везде, где не хватало человека на роль лида, был примерно похожий сценарий: “Ты разобрался с предметной областью, подружился с командой, не против руководящей работы, и у тебя даже есть такой опыт? Давай попробуем, чтобы ты ставил задачи другим людям. Хотя бы в этом спринте…”

Но был ещё один немаловажный аспект: я думал о будущем — и оно казалось туманным. Очень давно мне на глаза попалась статья про средний возраст разработчиков. В ней говорилось, что «пик карьеры» разработчика приходится на 27 лет. Я стал замечать похожие статьи — и невольно задался вопросом: что буду делать “я-разработчик”, например, в 32 года, когда придет “молодая шпана, что сотрёт нас с лица Земли”? Не лучше ли потихоньку протаптывать дорогу в менеджеры и решить для себя “проблему 30 лет”?

Мои принципы как тимлида

К тому времени, как я забросил C++ и с головой ушёл в Android, я уже поработал с разными руководителями и точно знал, каким лидером хочу быть. И позже в совершенно различных по составу командах: продуктовых (состоящих из аналитиков, дизайнеров, разработчиков, тестировщиков) и командах разработчиков — я старался не отходить от своих принципов.

Нужно работать с теми, кто есть

Студент с горящими глазами, которого направляют в нужное русло, через какое-то время может начать приносить проекту больше пользы, чем “рок-звезда”.

На одном из проектов я решил, что пришло время отойти от привычной всем коллегам связки MVP+Dagger+RxJava и попробовать в продакшене те средства, которые Google советует использовать для создания современных мобильных приложений. Мы планировали реализовать рекомендуемую архитектуру с использованием только Jetpack и Kotlin c Coroutines.

Все опытные разработчики и начальство крутили пальцем у виска и говорили, что с командой из двух джунов, которые ни разу не использовали ничего из выбранного мною стека, мы завалим проект и ответственность будет лично на мне. Но те самые два джуна были в восторге от того, что будут работать с тем, о чем разработчики ОС Android написали в блоге буквально вчера.


Да, конечно, мы словили кучу детских болезней альфа-версий библиотек на старте...

Но ребята рьяно работали, лезли в исходники и штудировали issues на Github, профилировали по ночам, — и в итоге мы получили:

• чистый, стабильный и простой в поддержке код,
• успешный продукт в продакшене,
• и кучу бесценного опыта.

На другом проекте в команду пришёл очень крутой разработчик, который сразу не сдружился со всем коллективом, но задачи пилил отлично. Ребята контактировали с ним через боль, слёзы и начальство, а кто-то даже говорил, что лучше бы вместо него взяли любого джуна, но в итоге я свёл живое общение между ними к необходимому минимуму, и всё стало спокойно.

С “рок-звездами” тоже надо работать, как бы сложно это иногда ни было

Естественно, бывают люди, которые сознательно не выполняют свою работу: кто-то думает, что попал к “начальнику, который будет делать всё за меня”, кто-то просто не может или не хочет работать. Если разговоры и время не помогают, с такими нужно не бояться расстаться.

Работаю не с подчинёнными, а с людьми

У каждого свои обстоятельства, потребности, темперамент и настроение. Однажды перед сдачей сложного спринта девушка-тестировщик, от которой все ждали результата финального тестирования продукта, пришла на работу злой из-за скандала с мужем, который не нашёл чистые носки. Дедлайн, уже не первый день напряжённого тестирования, а тут ещё и это. Настроения работать у неё не было совсем. В этой ситуации можно было давить, требовать и угрожать. Но я попытался её понять и перераспределить ресурс других тестировщиков так, чтобы прикрыть образовавшуюся брешь. Через полдня она остыла и мы успешно вложились в сроки.


Кто перед отпуском не сидел в рабочее время на посторонних сайтах, пусть первый бросит в меня монитор)

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

В сложной ситуации никто не пойдёт вперед, если я не поведу

В одной новой для меня команде DevOps пару месяцев “динамил” меня с развёртыванием CI, да и разработчики откровенно саботировали его внедрение, не соглашаясь с доводами о его полезности. Не то, чтобы они были ленивыми ретроградами, просто, как мне казалось, не работали в той среде, где CI правильно приготовили.

Обнявшись с гуглом, я сидел вечерами и ковырял настройки. Постепенно в процесс втянулись и DevOps, и разработчики. В итоге, у нас получилось настроить CI и необходимую обвязку для сборки и дистрибуции приложений, которая быстро и незаметно для меня стала стандартом для разных команд в компании.

Закрываю ли я дыры в организации процессов личным вмешательством и микро-менеджементом? Возможно. Но, как мне кажется, в такой патовой ситуации есть две крайности: “закручивать гайки”, всё больше отдаляясь от коллектива и превращаясь в “начальника”, или попытаться помочь человеку, когда ему сложно, даже выполнив его работу, становясь “своим”. А “своих” в беде не бросают.

Нужно развиваться самому и развивать всех в команде

Типичное рабочее место руководителя

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

Доходило до того, что вновь принимаемым разработчикам запрещали писать на Kotlin, потому что ведущие программисты его не знали и не находили времени (не хотели найти?) его учить. Решались эти проблемы довольно просто: я проводил tech talk-и, митапы и курсы по интересным для всей команды темам. Разработчикам проще и интереснее неделю поразбираться в какой-то технологии на pet-project и рассказать о ней остальным, чем вслепую втаскивать её на продакшен.

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

Нельзя далеко отрываться от проблем разработки

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

Были случаи, когда менеджеры искренне удивлялись тому, что нельзя опубликовать приложение для iOS на предновогодней неделе, потому что ревьюеры из Apple ушли на какие-то каникулы. Дизайнеры иногда не понимают проблем Android-разработчиков с вёрсткой на разные экраны. Бэкендерам, до этого не работавшим с мобильными клиентами, приходится объяснять, что не нужно отдавать вместо JSON ошибку в виде HTML-страницы.

И если при разработке системы или её части “просмотреть” такие моменты, последствия для сроков могут быть весьма плачевными.


Ох, сколько хорошего можно добиться, просто взяв на себя технические решения. А уж если и задачи распределять дадут — можно и горы свернуть!

Получалось ли у меня руководить?

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

• Улучшались отношения в коллективе. Если до меня были скандалы с выяснением отношений у начальства, то со мной — максимум мелкие перепалки.
• В целом, мы укладывались в спринты. Даже в невыполнимые. А если и не укладывались, то не настолько, чтобы заказчик был в гневе. Естественно, это заслуга команды. Но, вероятно, немного и моя. Я всегда старался учесть все риски и провести планирование задач с их учётом.
• Мы постоянно рефакторили и улучшали продукт и процессы разработки, технический долг снижался.
• Разработчики росли в ранге и зарплатно.
• Моё непосредственное руководство тоже было довольно.

Хорошо, а насчёт минусов руководящей работы?

Для меня они такие:

• Чем больше ты менеджер, тем меньше разработчик. Как бы ты ни старался уследить за тонкостями технической части проекта, они ускользают от тебя с каждым днём всё дальше. И чем больше команда и активнее разработка, тем быстрее. Постепенно объем получаемой новой информации об Android и iOS свёлся к чтению release notes новых версий операционных систем да паре статей на Хабре в месяц.
• Появляется куча нетехнических проблем. Работа с людьми — это отдельное умение, которое ещё нужно прокачать. На первых порах сильно тревожит то, что в общении с людьми нет универсальной “правильной” манеры. С каждым человеком нужно находить свой общий язык.
• Больше ответственности. Намного больше. Теперь приходится отвечать не только за свои задачи, но и за команду и продукт в целом. Когда кто-то в команде что-то зафакапил, то это и моя забота.
• Другой ритм работы и круг общения. Бесконечные совещания и созвоны с заказчиком, ПМом и всей командой вместе и по отдельности. Когда я был разработчиком, на встречи уходило 2-3 часа в неделю. У меня-менеджера в некоторые дни — до 70-80% времени!

Обратно в разработчики!

Как бы ни нравилось тебе на каком-то месте, когда-то придётся оттуда уходить. И в определённый момент я начал поиск нового места работы. Предсказуемо, мне хотелось устроиться в ещё более крупный бизнес, чтобы продолжить развитие.

Шло очередное Skype-собеседование: 10 собеседующих, 2 часа, требования — знание технической части уровня Senior Developer и умение руководить людьми. И через 2 часа я понял, что в управлении людьми я не знаю почти ничего. По крайней мере, не знаю теорию, и основываюсь только на своих принципах и наработанном опыте.

Выглядело это примерно так:

— Как повысить мотивацию сотрудников?

— Я повышал так и вот так.

— А вот это пробовали?

— Да, пробовал. Тут получалось, вот такие были сложности.

— А какие вообще есть способы повышения мотивации?

— …

— Хорошо, какие отличия есть у scrum и kanban?

— У нас были вот такие.

— А как это отражается на доске?

— …

Ну и так далее. Теорию я провалил. Реализация у меня как-то получалась, но объяснить базовые принципы, почему так или иначе надо было делать – нет. После собеседования я понял, что достиг своего потолка в любительской лиге управления и что дальше сидеть на двух стульях не получится. Чтобы развиваться, нужно было решить, куда я хочу идти.


Это моя текущая команда на выезде для удаленщиков. Как минимум еще один человек в ней прошел тот же путь: сходил в тимлиды и осознанно вернулся в разработчики.

Первый путь — в менеджеры. Всё-таки прочитать те самые правильные книги. Начать смотреть видео и посещать конференции по управлению, планированию и мотивации. В профессиональной лиге управленцев свои правила и своя специфика.

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

Ну и третий, компромиссный, вариант — всё же “подтянуть” теорию и пытаться и дальше быть “посередине”, зависнув “в любителях” ещё на несколько лет.

И тут я вспомнил, с чего всё начиналось. С ощущения, что ты меняешь мир, делаешь что-то полезное для других. Даже если ты покрасил кнопку в зелёный цвет, и она стала чуть приятнее для тысяч пользователей. Даже если исправил опечатку. А если уж запилил давно ожидаемую пользователями фичу, и тебя благодарят за неё в комментариях — это просто взрыв эмоций и хорошее настроение на пару дней!

Испытывал ли я настолько сильные ощущения от работы менеджером? Пожалуй, нет. Даже когда тебя хвалят заказчики, команда и руководители. А когда ожидаемую фичу хвалят пользователи, то это, конечно, заслуга прежде всего того, кто её подготавливал, пилил, тестировал и выводил. И совсем немного — моя как менеджера.

Поэтому я нашёл приятное место для работы, пишу код и пока ни о чём не жалею.
Есть ли жизнь в разработчиках в 32? Есть!

P.S.

Что мне как разработчику дал опыт руководящей работы?

1. Теперь я лучше понимаю бизнес и ПМа, даже без слов. Часто знаю, какой вопрос они хотят мне задать.
2. Более грамотно планирую время и задачи с учётом рисков.
3. Контраст. Посмотрев, как там на другой стороне, я понял, что мне нравится на этой.