Из разработчика в менеджеры и обратно

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



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

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


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

    image

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

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

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

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

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


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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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


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

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

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

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

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


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

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

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

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

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


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

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

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


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

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

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


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

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

    Выглядело это примерно так:
    — Как повысить мотивацию сотрудников?

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

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

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

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

    — …

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

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

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

    — …

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

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

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

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

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

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

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

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

    P.S.

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

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

    Комментарии 52

      +3
      Интересно было читать! Хорошо написано. В общем, спасибо за статью.
        +5
        В целом, мы укладывались в спринты. Даже в невыполнимые.

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

          Один раз у нас во всех крупных отечественных СМИ вышел инфоповод, что к определённой дате (понедельнику) мы добавим в мобильное приложение определённый функционал. Тестовый бекенд был готов в пятницу в 14 часов. Продуктовый бекенд — в обед воскресенья. Доков по АПИ не было от слова совсем. Я попросил команду выйти в выходные поправить оставшееся и потестировать. И никто не отказался. И дело тут, как мне кажется, в том, что каждый был мотивирован и нацелен на результат.

          И да, ребятам заплатили за эти часы по двойной ставке, а следующий спринт мы начали с долгой раскачки)
            +2
            Иногда бывают случаи, когда просто нужно вложиться в сроки, какими бы упоротыми они не были. И задача лида — организовать это.

            Нужно кому и зачем? Инфоповод в СМИ не повод выжигать людей и устраивать бессмысленные подвиги и кранчи. Задача лида — объяснить это тем кто сверху и прекратить это как можно раньше, чтобы потом не вошло в привычку.


            а следующий спринт мы начали с долгой раскачки

            А вообще знаете, есть жизнь и вне аджайла, спринтов и прочей "бизнесориентированности".

              +5
              Задача лида — объяснить это тем кто сверху и прекратить это как можно раньше, чтобы потом не вошло в привычку.


              Полагаете, в разработке всё время игра в одни ворота, и любой бизнес даст себя прогнуть в 100% случаев?

              Я не говорю, что овертаймы — это хорошо или хотя бы нормально. Я против них, но они, как буквально я и написал, «иногда бывают».
                0
                Да проблемы в общем-то нет, компания явно у клиента запросила утроенный тариф за такую срочность. Уверен, часть команды с удовольствием за тройную ставку отработала бы. Ну либо эти выходные компенсировать всей свободной следующей неделей :)
                  0
                  Да-да! Работал я так в одной конторе всего с месяц где-то. И повис там жёсткий дедлайн перед серьёзным заказчиком. А так как проблема было по моей специализации (я подключился уже ближе к финишу), то пришлось мне вечерком остаться на пару часов, а утром ещё и подъехать к 7 утра, чтобы успеть всё запустить в срок.
                  Ну и когда на следующий день я логично решил отоспаться (хотя бы по причине того, чтобы не словить переутомление) и приехать к обеду — непосредственный руководитель оборвал мне телефон, потребовал написать объяснительную и т.п. После нескольких, довольно резких фраз от меня, он по умолчанию решил эту тему не развивать. Но осадочек у меня уже остался. Я сразу понял что мы просто не сработаемся в таком ключе. Я, конечно, какое-то время ещё поработал там, но уже ни на какие «переработки» и не думал подписываться — «рабочий день закончился? до завтра!»
                    0
                    И, в целом, я с вами полностью согласен. Сам стараюсь вести именно такую политику. Эти запуски в срок как минимум подразумевают срочный фиксинг багов в авральном режиме ПОСЛЕ запуска. А страдать из-за факапов руководства — не вариант.
                  0

                  Я хоть и не бизнес, но далеко не всегда лид может объяснить, что "нельзя грузить людей".
                  Начиная от критической ошибки, которую "необходимо устранить любой ценой", либо для компании будут такие последствия, что всем сотрудникам нужно будет срочно искать новое место работы (ибо старая компания может прекратить существование или оказаться на грани банкротства).
                  Заканчивая срочным инфопоаодои вида "к такой-то конференции необходимо выкатить новую фичу".


                  Задача лида — поддерживать баланс и иметь контакт с бизнесом, чтобы можно было чётко ранжировать задачи — вот с этой бизнес идёт нафиг, а вот с этой — идём к разрабам, возможно вместе с директором и честно говорим "ребята и девчата, нам ОЧЕНЬ нужно это сделать".

                    0
                    Бэкапы не нужны.
                    Даунгрейд не потребуется.
                      0
                      И бекапы тоже не нужны, особенно если директор считает их категорически ненужными, а у тебя уже есть пара интересных Job Offer'ов :)))
                  0
                  А как бы вы отреагировали, если бы кто-то отказался?
                    +2
                    Понял бы его. Он не обязан. Просто в следующий раз не расчитывал бы на него)
                      –3
                      Слил человека короче ) Ох уж эти авторитарные руководители, прикидывающиеся белыми овечками
                +1
                Я стал замечать похожие статьи — и невольно задался вопросом: что буду делать “я-разработчик”, например, в 32 года, когда придет “молодая шпана, что сотрёт нас с лица Земли”?

                У вас уже есть не малый опыт и знания. Что мешает вам совершенствовать свои знания и быть выше уровня «молодой шпаны»?
                  0
                  Да, это так, и сейчас я это осознал. Но когда тебе 25 (условно), и все вокруг кажутся начальниками, успешными стартаперами, чемпионами мира по футболу и еще черти знает кем, я, как и многие, сомневался, а не стоит ли расти ввысь? Сейчас я, кажется, уже перерос эти страхи и более уверенно смотрю в будущее)
                    +2
                    Ребята, честно не понимаю о каких страхах вы говорите… Мне под 40, я и руководил людьми, и сам был и остаюсь разработчиком. Никогда даже мыслей не появлялось типа «о, кому мы нужны после тридцати». Тут надо просто понимать специфику бизнеса: если им нужен «пламенный мотор», то это значит выжимать его будут по полной программе. И тогда вот появляются статьи здесь про выгорание. А если бизнесу нужен опыт, как профессиональный, так и в общении с людьми, то выбор более зрелого разработчика более чем оправдан. Поэтому недостатка в предложениях о работе я лично не испытываю, как и не считаю себя стариком в разработке. Разработка продукта это ведь не только код и «новейшие технологии по капотом», тут опыт разный очень даже приветствуется.
                  +5

                  Мне кажется, что мантра про 27 лет это про "вайтишников", которые просто за рублем потянулись после универа. И их как раз и хватает лет на 5, отсюда и эта цифра.
                  В среде тех же плюсовиков и сишников я почти ни разу не слышал эту мантру.

                    0

                    А что за мантра? Я из "плюсовиков и сишников"

                    +3
                    Переход из разработчика в менеджера действительно уныл. Вместо интересных ежедневных задач ты получаешь нудную тягомотину человеческих отношений. Это не то, чего я хотел, когда шел в программисты!

                    В то же время можно приложить усилия и остаться на верхнем краю технического стека: тимлид, техлид, команда в 3-5 человек. Интересные технические задачи всё ещё есть, а недостатков управления большой командой ещё нет.
                      +4
                      Соглашусь. Для меня самая интересная работа (из руководителей) у архитектора или техлида: и к разработке близко, и можно определять вектор развития команды и продукта.
                        0
                        Архитектора?
                        Того, кто еще больше должен общаться с людьми со всех сторон? :)
                        От разработчиков до генеральных директоров )
                      0
                      Интересно написано. Спасибо за статью
                        +1
                        Типичное рабочее место руководителя

                        А зачем там топор?

                          +1

                          зарубить фичу? :)

                          +5
                          В ней говорилось, что «пик карьеры» разработчика приходится на 27 лет
                          Есть ли жизнь в разработчиках в 32? Есть!

                          Вот вроде бы продолжительность жизни увеличилась со времён средневековья, а люди сами себя хоронят раньше времени и загоняют в какие-то смешные рамки: "успеть всё до 30", "в 32 меня сотрёт с лица земли молодая шпана". Ох… Кто вообще сказал, что после 30 нельзя быть разработчиком или вообще кем-то быть? Что, после 30 мозг отключается или стремительно деградирует? Нет. Разработчиком быть несолидно, нужно непременно стать менеджером, а то люди не поймут? Глупость же. Можно привести множество примеров выдающихся инженеров, разработчиков, учёных, которым далеко за 30, которые занимаются любимым делом всю жизнь и не стремятся стать "правильным менеджерами из высшей лиги, которые знают как уложиться в спринт". Можно быть кем угодно и заниматься тем, что тебе нравится практически в любом возрасте если здоровье позволяет, нет больше никаких преград кроме собственных и общественных предрассудков.

                            0
                            Можно привести множество примеров выдающихся инженеров, разработчиков, учёных, которым далеко за 30, которые занимаются любимым делом всю жизнь


                            «Заниматься любимым делом всю жизнь» и «получать сносный доход всю жизнь» — это пересекающиеся множества действий. Но сильно далекие от совпадений.
                            0
                            Прямо моя история практически, пришел я к тому же. Немного с другими проблемами я сталкивался, но очень похоже. Аж ностальгия проплыла читая текст, спасибо :)
                              0
                              А сколько из всех проектов в которых ты был лидом вообще выплыло? Нет ощущения что все эти приложения бесполезны и закрываются сразу после сдачи?
                                +1
                                Нет, такого ощущения нет. Проектов, в которых я работал, закрыто два. Но это были стартапы, так что не очень обидно. Крупные проекты, в которых я когда-то работал, все на плаву, я слежу за ними)
                                  0
                                  Как ты думаешь, была ли ошибка бизнеса в том что стартапы закрылись, и если бы у разработчиков было больше власти, могли ли они выплыть?
                                    0
                                    Трудно сказать. Но развивать бизнес с нуля до стабильности и прибыльности — это как покорить очень сложную вершину со своей командой. Далеко не всем удаётся)
                                +1
                                С возвращением!
                                Имею схожий опыт — добрался до (программирующего между совещаниями) директора департамента ИТ, всё осточертело, вернулся в чистые разрабы.
                                Хотя привычки/навыки руководить пригождаются — иногда приходится «подруливать» коллегами, чтобы разрешить некоторые ситуации.
                                Считайте, что хорошо прокачали софт-скиллы :)
                                  0
                                  Спасибо! Надеюсь, что это действительно так)
                                    0
                                    Интересно, а насколько была крупная компания, где удалось стать программирующим (!) директором ИТ?
                                    Вообще с точки зрения собеседующего это довольно неловкая ситуация — собеседовать бывших директоров или начальников отделов, например, на позицию тимлида. То ли правда люди камбечат, то ли из-за различия фактических обязанностей на позициях такое случается…
                                      0
                                      Было небольшое ООО с относительно независимыми дочками, был там начальником отдела. Потом это ООО решило укрупниться, собрав дочек, внезапно для себя стал директором ДИТ.

                                      Не, на тимлида больше не собесился. Один раз намекнули, что «возможно, придётся порулить стажёрами» (или я неправильно понял), сбежал с готового оффера аки невеста из-под венца.
                                      Не интраверт и социопат, но просто устал, видимо.
                                    0
                                    жизнь в разработчиках есть и в 44, а потом пришлось продолжать жизнь в охранниках девопсах, сменив отрасль и стек по естественным причинам.
                                    чем больше опыта и чем он разнообразнее, тем проще найти себе занятие.
                                      +1
                                      Есть ли жизнь в разработчиках в 32?
                                      Это скорее индивидуально вопрос решается, в общем однозначно ответить не получится. Моё скромное мнение, не надо тратить много сил и времени на изучение всего и вся, лучше попытаться достичь совершенства в небольшой сфере, но именно совершенства, а не просто знания. Достижение высокого результата в работе приносит моральное удовлетворение и материальное конечно тоже.
                                        0
                                        Поддерживаю. Тоже считаю, что лучше углубиться в одном, чем распыляться во многом.
                                        0
                                        Первый путь — в менеджеры…

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

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


                                        Как вам вариант менять область раз в полтора-два года поочерёдно? Условно полтора года разработчик / полтора года менеджер.
                                        По своему опыту нормальный такой баланс, если не гнаться за рублём/карьерой. Т.е. не успеваешь выгорить, всегда есть развитие, смена деятельности для мозга — это полезно, увеличивается широта взглядов, по жизни легче общаться сразными людьми и т.д.

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

                                        погружаться в разработку, по возможности наверстав упущенное

                                        Не понимаю страха чего-то там упустить. На желаемую позицию узнаёшь стек технологий, за пару недель (месяц) прокачиваешь. И потом ещё есть месяц кредита доверия для погружения в проект.
                                          0

                                          А каким образом "прокачиваешь"? В нерабочее время?

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


                                            Каким тогда должен быть менеджер проекта? Если даже тимлид отходит от разработки и понимает насколько много ответственности, как важна коммуникация. Что делать техническими скиллами? Насколько нужны?
                                              +1
                                              По моему личному опыту, чем больше вовлечённость всех участников команды во все процессы, тем лучше. Если разработчики думают о бизнес-метриках, а бизнес имеет в виду, что с выходом FaceID может потребоваться время на рефакторинг приложения перед релизом, договориться несложно. Хуже, если каждый видит узкий сектор работы перед собой и не знает, что творится вокруг него.

                                              Поэтому, отвечая на Ваши вопросы, могу сказать: чем больше знаний и скиллов у менеджеров, тем лучше.
                                                0
                                                По моему личному опыту, чем больше вовлечённость всех участников команды во все процессы, тем лучше. Если разработчики думают о бизнес-метриках, а бизнес имеет в виду, что с выходом FaceID может потребоваться время на рефакторинг приложения перед релизом, договориться несложно. Хуже, если каждый видит узкий сектор работы перед собой и не знает, что творится вокруг него.


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

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


                                                Больше понятно, а насколько глубоких? Ведь сложно стать специалистов в нескольких областях, вы сами признали что прийдя в менеджмент нужно учить управление. Мне интересно просто как оно происходит наоборот — пришел менеджер в IT допустим
                                              0
                                              Автор прав на 100%. Я думал я один такой… Сам прошел точно такой же путь от разработчика (android-приложение, desktop-приложения и даже издал пару книг по разработке и отладке) к менеджеру проектов (сначала региональная компания, потом федеральная, потом крупная ИТ-компания имеющая 800 филиалов по стране) и… то же решил вернуться в разработчики. Когда руководишь людьми, то это совсем другая область, совсем другой круг общения и самое главное, ты упускаешь возможность делать полезное и красивое самому. Однако могу сказать, что я получил ценный опыт и теперь я прекрасно понимаю специфику бизнеса и знаю что и как следует делать для достижения результата.
                                              А автору хочу пожелать удачи!
                                                0
                                                Спасибо! Действительно, у нас очень похожие истории)
                                                  0
                                                  ты упускаешь возможность делать полезное и красивое самому.


                                                  Сейчас обидно стало ) Как будто менеджеры проектов не делают полезное и красивое. Бухгалтера тоже не делают тогда. И вообще мало кто делает. Хотя желание вернуться и делать так чтобы то что без вас не крутилось — начало крутиться (цитата), мне вполне понятно. Просто каждому своё.
                                                    0
                                                    Просто каждому своё


                                                    Ну да, как в поговорке «Мы пахали, я и трактор».
                                                      0
                                                      Трактор без механизатора сам не пашет.

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

                                                      Или вы сторонник теории что все вокруг государство, все организации, бизнес, любые команды — имеют руководителей, и они просто паразитируют ничего не делая? Серьезно?
                                                  0
                                                  Я так из проектировщиков в монтажники переквалифицировался, а потом через 7 месяцев обратно аж вприпрыжку прибежал проектировать. По ту сторону проекта мне очень понравилось ))

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

                                                  Самое читаемое