Как стать автором
Обновить

Руководство разработкой: beginner's survival guide

Время на прочтение 14 мин
Количество просмотров 22K
Всего голосов 59: ↑55 и ↓4 +51
Комментарии 24

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

Как оно должно выглядеть

Всегда подозревал что управление тесно связано с темными силами.

Особенно для людей слабо заточенных под управленческий процесс.
Ведь управление это такой же навык как IT. Так какой смысл брать хорошего айтишника и ставить его на управление?

Почему не взять управленца, и не привить ему навыки айти?

Почему не взять джуниора, у которого уже есть базовые айти навыки, и не взрастить из него управленца?

А пока ответа на эти вопросы бизнес не дает, и делает страшные вещи по типу "извлечь самого лучшего копателя на поле, из самой глубокой ямки, дать ему золотую лопату и заставить контролировать чтобы другие копали лучше", ваша статья будет очень помогать всем "копателям с золотой лопатой" не сойти с ума. Спасибо.

Почему не взять управленца, и не привить ему навыки айти?

Потому что привить среднему управленцу айтишные навыки на мой взгляд и по моему опыту всё-таки сложнее чем привить среднему айтишнику навыки управленческие.


Почему не взять джуниора, у которого уже есть базовые айти навыки, и не взрастить из него управленца?

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

> Почему не взять джуниора, у которого уже есть базовые айти навыки, и не взрастить из него управленца?

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

Многие компании так и делают, E5 в Facebook и Google как раз когда можно начинать идти в управленца. Не джун - но понимает как вещи работают вокруг

Наташа, спасибо Вам за текст.

Почти 5 лет назад я окончил "президентскую программу подготовки управленческих кадров", это что-то вроде курсов для тех, у кого УЖЕ есть управленческий опыт.

Главный вывод, который я сделал тогда - это "я не хочу руководить", после чего съехал обратно в разработку.

Бытует мнение, что в разработке хороший руководитель может занять место любого "выбывшего бойца" и показать, как надо. У меня сейчас обратная ситуация: я не хочу коллективной разработки, боюсь допускать кого-то в проект и "пилю" сам.

Привет! Спасибо за классный материал. Сам побывал пару лет руководителем и остались двойственные ощущения. 🥲

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

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

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

А для тех, кто все-таки не хочет расставаться с «лопаткой», есть замечательная позиция «техлид». Это тебе дают самую большую золотую лопату, ты выгребаешь самые сложные большие ямы и решаешь, как и чем вы будете копать новый участок.

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

Техлид, в моем понимании, это как раз эксперт без команды, но с решающим словом с т. з. реализации.

Да я понял мысль, но вот ситуация, ты - тимлид, который забыл, как включать компьютер. Вот у вас новая задача и два твоих сеньора спорят, как стоит её решать. Как принимать решение, если ты стал тумбочкой?

Сам в такой ситуации не был (не так уж долго был на руководящей позиции), но в рулетке кейсов на podlodka team lead crew это обсуждали и сошлись, что норм в таких случаях искать помощи из-вне, как на уровне компании, так и позвать внешнего консультанта.

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

Думаю, все зависит от числа подчиненных.

Если ты тимлид команды из 3-4 человек и пилите один продукт, тут вообще не вижу причин и самому код писать (важно только не брать критовые части себе).

А вот когда человек уже 10-15, то, кажется, в большинстве случаев у тебя не будет достаточного погружения во все контексты, чтобы эффективно принимать технические решения.

Да, тут согласен.
Я имею ввиду больше про просто, например, читать книги, статьи, релизы новых инструментов, чтобы быть в контексте, что происходит в индустрии.
А не просто сидеть и руководить.

🤝

Я бы сказал что если у тебя 10 или уж тем более 15 подчиненённых, то это уже и не совсем тимлид. Многовато это для команды. И тут уже на мой взгляд 100% нужен не айтишник, а управленец.

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

Да, согласен.

Я имел ввиду просто «держать руку на пульсе» скорее.

Основная задача руководителя — убирать все препятствия на пути достижения цели. Система может работать очень эффективно, если устранить всё, что мешает ей это делать: убрать все точки сопротивления, шероховатости и нестыковки.

На мой взгляд, главная задача руководителя - выстраивать процессы.

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

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

Классный материал! Подтверждающий мысль, что человек с головой в принципе справиться и с управляющей позицией.
Единственное, мало сказано про ключевое отличие руководителя - при переходе от управления кодом к управлению людьми - самое драматичное, что человек - не управляем по своей сути. Код написал, не понравилось - переписал, ошибка - исправил. Код стерпит. И сделает ровно так, как ты ему сказал. Человек нет. У него есть свободная воля, а еще он может обижаться, а еще мы (как человеки) часто боимся, что он обидится - начинаются игры и т.д.
И мастерство руководителя включает в себя - важную компетенцию управлять неуправляемыми. Через включенность, синергии, поддержку, единство целей и т.д.

часто боимся, что он обидится - начинаются игры — очень верно подмечено.
Я тоже сначала боялась, что люди обидятся и начинала игры, это всегда приводило к плохому. А потом с помощью других людей обнаружила существование навыка «новая коммуникация».
С помощью этого навыка можно увидеть в себе этот страх, открыто поговорить с человеком и всё прояснить. Жизнь упрощает невероятно.
У нас в ТГ есть группа, где мы как раз прокачиваем этот навык t.me/sozdateli_now
Включенность, синергия, поддержка и единство целей — это то, что можно развивать осознанно.

15 лет был руководителем в ИТ (начинал с 10 подчиненных, закончил на 300). Вернулся в разработку. Рад)

брать на себя ответственность,

На мой взгляд - это ключевой момент в вашей статье, а про него ни слова не сказано.

Совершенно непонятно, в каком видет несет ответственность руководитель и чем это отличается от исполнителя.

Еще момент: когда руководитель "руководит снаружи", как показано на вашей схеме, за что он несет ответственность? За неверную инструкцию? Это классический формализм, в Италии по такому принципу да же забастовки устраивают, когда делают свою работу исключительно в рамках инструкций.

для руководителя обязательны. Это управление временем,

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

Хорошая структура. Спасибо за статью. А что посоветуете читать?

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