Annual Open Tech Conference - ISsoft Insights 2021. June 19. Learn more.
×Закрыть

Управление временем для Lead Developers

Привет всем. Я являюсь Lead Developer в одной софтверной компании делающей ПО на заказ (PHP, 2.8 лет опыта). Сейчас в мои обязанности входит:

1. Fulltime написание кода в одном проекте (просто как разработчик)
2. Создание архитектуры, code review, управление командой в другом крупном проекте, (работаю над ним уже год)
3. Управление командой и контроль архитектуры проекта на AWS + nodeJS.
4. Также есть мелкий проект для нашей маркетинговой команды — на который все меньше и меньше остается времени.

И сейчас я понимаю — что мое качество работы падает, так как я занимаюсь менеджментом и написанием кода одновременно. Начинаешь писать код — приходит куча вопросов, либо задач которые нужно решить, распределить между командами. Либо происходит переключение между проектами, потеря концентрации.

Так вот появился вопрос — как вы ребята справляетесь с такой нагрузкой? Конечно — правильное распределение времени и т.п. Но возможно есть тайны о которых я не знаю :)

P.S. Бросать программирование, в пользу менеджмента не хочется — 3 года опыта я считаю малым сроком для себя. Есть еще много вещей, которые хочется познать.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

«Делать самому нужно только то, что другие делать не могут или будут делать ооочень долго». Я обычно руководствуюсь этим принципом при расставлении приоритетов. Если есть шанс, что кто-то в команде может сделать ту же работу за пускай в 2 раза больше времени — делегируем однозначно а потом проверяем.

Еще не плохо научиться говорить «нет» новым задачам. А если руководство оказывает давление — мол кроме тебя некому делать — спокойно просишь озвучить чем тебе больше НЕ заниматься из текущих задач. Обычно вопросы отваливаются самостоятельно.

1. Приоритеты. Не важные таски можно не делать со спокойной совестью.
2. Делегирование. Обучай людей, которые не так загружены, делать часть своей работы и делай их ответственными за нее (пусть разработчики ревьювят друг друга, часть управляющих функций, таких как логанье времени и прочее написание отчетов, если есть, мелкий внутренний проект — на джунов).
3. Работа сессиями. Работай над таском не отвлекаясь как минимум час, затем переключайся на другой, попив чаю. Дергают — уходи в митинг рум или на другой этаж. Часть времени — для работы в одиночку, часть — для работы в команде.

— Скажите, как вы всё успеваете? В чем ваш секрет?
— Мой секрет прост — я нихрена не успеваю

©

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

Все не так плохо — зато быстро учишься, «год за два». :-)

Сложно давать разумные советы не зная контекста и всех деталей. Один из вариантов:
1) разобраться для себя какие из пунктов 1-4 реально интересны и чем хочется заниматься дальше
2) спланировать набор действий, как избавиться от остальных

Lead Developer
PHP, 2.8 лет опыта
Ам...
Fulltime написание кода
А после еще 3 пункта... непонятно, ночами работаете или по 16 часов?
я занимаюсь менеджментом и написанием кода одновременно.
Lead-позиция это подразумевает.
как вы ребята справляетесь с такой нагрузкой?
Приоритезация, делегирование, прокастинация.
P.S. Бросать программирование, в пользу менеджмента не хочется — 3 года опыта я считаю малым сроком для себя. Есть еще много вещей, которые хочется познать.
Так не бросай. Иди в архитекторы и «гуру», а менеджера пусть нанимают...

1. Никогда не понимал, почему людей удивляет срок работы и полученный опыт? Ведь можно 5 лет сидеть на «полузамершем» проекте, делать небольшие фичи и баг фиксы. А можно за год-два получить опыт в различных областях (базы данных, алгоритмы, методологии).

Далее — опять же, позиция Lead developer мне кажется очень зависит от окружения. Если у вас 10 среднечков, и один из них быстро учится, и начинает руководить другими — то почему нет? Ясное дело, если взять Java Lead из одной компании, и PHP c другой — то это может быть совсем разный уровень.

2. Иногда работаю ночами, до 12-13 часов. Понимаю что вредно/глупо/не нужно и т.п. Но пока что поделать ничего не могу)) Молодой видать.

С последними пунктами согласен. :)

Как же это все похоже на GlobalLogic

Проблема в том, что ты занимаешься кодированием и менеджментом одновременно.

1. может, вы себя накрутили и зря тратите столько личного времени?
сходите в отпуск на 2 недели, в горы, без телефона.
А потом посмотрите, везде ли всё плохо?

2. Может, надо назначить «заместителей» на местах, так сказать, региональные органы управления. Можно назвать их скрам мастерами. Ну и пускай мелкие проблемы берут на себя.

И сейчас я понимаю — что мое качество работы падает, так как я занимаюсь менеджментом и написанием кода одновременно.
Для начала определитесь с тем, что входит в обязанности Lead Developer, а что — нет. Во многих компаниях любят смешать в кучу обязанности тех-лида и менеджера проекта и все это взвалить на девелопера.
Если хотите играть все роли да еще и на нескольких проектах то единственный способ делать это эффективно это «Диссоциативное расстройство идентичности»
ru.wikipedia.org/...во_идентичности
Вот пример как в одном человеке совмещалось 10 личностей: как раз хватит на агильную команду:
ru.wikipedia.org/...Миллиган,_Билли

эм, а можно дополнительную инфу:
1. размер и состав команд в проектах 2-4
2. Реальное время, затрачиваемое на проект 1 (в неделю)

P.S. Не хотите бросать программирование в пользу менеджмента — бросайте менеджмент в пользу программирования

1. На первом 3, на остальных по 2 человека
2. 25-30 часов, зависит от задач

НУ менеджить команду в 2 человека — не сильно страшно (хотя зависит от ситуации).
Подумай те вот о чем:
1) если будет завал на проекте 1 — сможете ли вы забить на недельку-другую на остальные проекты?
2) Если будет проблема на других проектах — сможете ли вы бросить фичу на первом?

Слишом много для одного человека. Скажи начальству что слишком загружен, не можешь так работать.

Да говорил уже :) Но почему то ничего не меняется. Да и по сути, я не допускаю плохой работы, поэтому вытягиваю за счет личного времени.

Открою вам великую тайну. Если ты жалуешься, но тянешь — то какого фига ты жалуешься?!

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

Конечно. Ведь если косяков нет — значит вы справляетесь.

Самое паршивое, что это тот случай, когда инициатива наказуема. Т.е. вы вытягивали проекты за счет личного времени, если прекратите — сразу станете «плохим» работником.

Зачем косячить? Поставить спокойно проблему перед менеджментом с путями решения, потом уже можно косячить. Отмазка будет — «а я говорил». Кто везет — на том и пашут.

Менеджмент считает что проблем, пока никто не жалуется.
Делал много разных «трудовых подвигов» — не оправдывались никогда.

Мне кажется оптимальным, когда каждый человек занимается одним проектом, даже если там разная деятельность (не только написание кода или программирование, например). Это позволяет достаточно сильно углубиться в проблемы и задачи проекта и быстро с ним работать. Если постоянно переключаться между разными проектами (даже занимаясь только, например, программированием) есть риск поверхностного понимания проекта и как следствие низкое качество исполнения :)

По сути, этот топик — для восстановления душевного равновесия)) Ваш коммент подтверждает что мои мысли верны :)

круто жить в Украине, 3 года формошлепства — и уже лид девелопер с тенденцией бросать програмирование в пользу менеджмента.

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

lol вспомнил некоторых персонажей- содрогнулся. Да иньязы неиссякаямый источник коз прямо таки. Но надо сказать что у 90% наших програмистов английский обосратся и не жить, увы

Есть знакомый менеджер — по образованию коза с иняза.
И че? все довольны, как подчиненные, так и менеджмент, так и клиенты.

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

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

Это все умеют, это природой заложено;)

Напоминает изречение «все мужики пьяницы и бабники».
Кто из упомянутых товарищей коза — для меня загадка.

Не в чувствах дело. А в адекватности постановок задач.

Хорошо, если к «козе» идет пристяжным какой-нибудь senior или lead developer для трансляции ее «хочу» в технические задания.

Плохо, когда «коза» является простой переводческой прокладкой между клиентом и разработчиками

Проблема в том, что «коза» может быть любого пола и образования.

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

А «может быть»... конечно может быть, вопрос в частоте.

Если говорить о тенденциях — то программистам часто собственное эго мозги пережимает. От чего начинают несколько не правильно относится к другим людям, особенно если не понимают специфики их работы (90% программистов не могут быть руководителями в принципе).

90% программистов не могут быть руководителями в принципе
Это совсем другое :)

Но так оно и есть (впрочем, это касается не только программистов)

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

Не все соображения ПМ являются дебилизмом, для того чтобы это понять, надо поработать слегка в данной области, побыть рабом вышестоящего менеджмента/клиентов.

Дебилизмом, имхо, является ответ «я сказал» на вопрос «почему».
Ground workers в особо запущенных случаях голосуют ногами, так что эта болезнь лечится.

Часто в PHP за 3 года можно получить неплохой опыт. У нас большая часть проектов однотипны (средние магазины, различные API для мобильных приложений), поэтому как только человек уже хорошо разобрался с процессом, технологией — его «повышают» в управленцы.

Подписаться на комментарии