Много лет руковожу программистами, при этом продолжая писать код, придумывать архитектуру, управлять проектами и т.д. Короче, я как все, только ещё хожу на совещания.
Рядом много других команд программистов, и у них тоже есть свои начальники. И вот странное дело - сильно они разные получаются.
Примерно половина начальников - прям уух, настоящие технические лидеры, знают почти всё примерно обо всём, могут подсказать выход из любой затруднительной ситуации - причём, и технической, и человеческой, покажут где посмотреть пример аналогичной решённой задачи, помнят, кто из ребят уже делал подобное, какие были подводные камни, как лучше не делать.
Вторая половина, ну это... Возьмите любой эпитет из предыдущего абзаца и добавьте НЕ.
Исходные условия у всех одинаковые - каждый когда-то был хорошим программистом, потом "выдвинулся" (все - по своей воле), ну и руководил, как мог.
Почему такая разница?
Подумал, понаблюдал, сравнил - оказалось, всё чертовски просто. Когда руководишь командой программистов, надо постоянно вникать в их задачи.
Половина начальников обычно эту возможность игнорируют. Именно Возможность - руководить умными, толковыми, амбициозными программистами, инженерами, дизайнерами и т.д. - это возможность, а не обязанность. Руководители исполняют роль координаторов и погонщиков (shaper по Белбину) – распределяют задачи, контролируют срок и бюджет, ну или какие там ещё у них параметры есть.
А в суть задачи не вникают. Проблем, возникающих в процессе выполнения, не знают. Способы решения, которые программист попробовал, не видели. Что в итоге сработало – не интересуются.
Задача для такого начальника остаётся чёрным ящиком. Сделали – и хорошо. Вовремя сделали – прекрасно. Но никакого прироста знаний у начальника не случилось. Программист – да, прокачался (если задача содержала в себе хоть что-то для него новое). Но полученные знания, отточенные навыки и освоенные технологии остались при нём.
А ведь там просто кладезь информации, особенно если задачи разнородные. И главное – затраты на погружение чертовски малы. Надо потратить 5-10 минут в начале, опционально - пару-тройку итераций в середине, и столько же в конце. Программист сам с радостью всё расскажет, если спросить – с чего начал, куда копал, где зашёл в тупик, у кого спрашивал, что посоветовали, что попробовал, как сработало, чего нового узнал.
Конечно, начальник получит знаний меньше, чем программист. Но в бесконечное количество раз больше, чем получал до этого, контролируя лишь сроки и бюджеты.
Я эту теорию проверял на нескольких начальниках, в т.ч. на себе самом. Работает всегда.
Да, были и обратные примеры – когда начальник ни в какую не хотел вникать. Не знаю, где он теперь. Его заменил скрипт.
Для примера. Я сам на прошлой неделе решал две большие задачи - проблемы с себестоимостью решал и производственное планирование программировал. Что ещё узнал, благодаря участию в задачах команды?
Чем учёт в НКО отличается от обычного. Что такое ФСБУ 6 и как оно запускается. Как работает выгрузка из Бухгалтерии в ERP и да, там есть детские ошибки. Как изнутри устроен механизм расчёта цен в транспортной логистике Раруса (да, там тоже есть ошибки). Как в ЖКХ распределяется оплата по начислениям. Удивительно, но в соседнем отделе "пишут компоненты интеграции", скопировав пример с "Hello World" внутри. Для отражения подарков сотрудникам есть специальный инструмент, и там начисляется НДФЛ. Как устроено разузлование спецификаций в ERP (увы, чуть хуже, чем хотелось бы). Как устроена система прав доступа на регистры в ERP. Как за несколько минут ускорить работу 1С на сервере в 2.5 раза, если там был плохой админ. Как в ERP отследить, из какого плана продаж создан план производства, а потом заказ.
Ещё кучу времени помогал продавцам и руководителям проектов. Но это к делу не относится.
Ну и, конечно, личное программирование помогает. Его не стоит бросать никогда. Только личное программирование делает знания и навыки глубокими, тут уж не отвертеться - придётся садиться и погружаться.
А широту можно получить почти на халяву.
