Как стать автором
Поиск
Написать публикацию
Обновить

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

Время на прочтение9 мин
Количество просмотров24K
Всего голосов 49: ↑47 и ↓2+60
Комментарии52

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

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

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

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

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

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


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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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


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

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


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

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


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


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


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

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

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