[management] Наглядная иллюстрация для начинающих разработчиков, мечтающих вырасти в настоящих менеджеров

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

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

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

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

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

У меня в свое время стереотипный план карьерного развития выглядел приблизительно так: сперва ты растешь как программист (младший программист, программист, ведущий программист), затем возглавляешь группу (сейчас это называется "тим-лид"), затем управляешь лабораторией в отделе, затем отделом... Ну и далее, до главного инженера (в КБСП, где я начинал работать такая должность была), замдиректора или даже директора, если сильно уж захочется и представится возможность.

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

А вот на RSDN-е давеча нашлось хорошее описание типичной ситуации, с которой приходится сталкиваться менеджеру программистов:

На моём уровне — собираю статистику по команде. Кто сколько items закрыл, средний размер item, как быстро закрывается в среднем каждым из членов команды и т.д и т.п. ... Поднимается вопрос, что имярек делает всё в N раз медленнее других, требует много внимания, снижает среднюю продуктивность команды, не прогрессирует последние M месяцев. Идёшь к владельцу продукта, показываешь статистику, даёшь конкретные примеры того, как он тебя отвлекает от твоих очень важных дел на всякую мелочь, предлагаешь перевести его куда-то в другую команду, где не требуется самостоятельно искать решения, если есть куда переводить и просишь разрешения на найм другого. При этом подумай о том, есть ли способ исправить ситуацию перед тем, как это делать. Потому, что владелец продукта может задать вопрос, а можно ли это как-то исправить, ибо замена работника — удовольствие дорогое. Ну, или как вариант, обнаружь, что имярек ничем от других по производительности не отличается и это просто субъективное ощущение. Если субъективное и только у тебя (посоветуйся с лидами и теми разрабами, с которыми у тебя полностью доверительные отношения — т.е. теми, кто тебе доверяет настолько, чтобы обсуждать деликатные вопросы открыто), то забей на эти ощущения и пусть работает. Если у всех — то это уже мораль команды и к владельцу идёшь уже с именно с акцентом на это.

У нас было два показательных случая с onshore FTE.

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

Второй случай — человек вообще не коммитит нифига, ссылаясь на занятость на внедрении нашего продукта у клиента. На внедрении мне сказали, что и там он нихрена не делает. Сбор статистики, разговор с владельцем продукта, performance plan, перевод в другие команды. Расстанутся ли с ним по итогу или он возьмётся за ум и станет звездой в другой команде — это лично мне не так уж важно.

Т.е. скучный учет и контроль.

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