В ряде проектов я оказался в плохо определенной роли в левом верхнем углу организационной схемы, где никто не подчинялся мне напрямую, но с широкой ответственностью за технические аспекты проекта. В тех случаях, когда у меня была команда для управления, я не очень хорошо справлялся, как в том, что не давал достаточно четких указаний на низком уровне, так и в недостаточно эффективном делегировании, а также в том, что я не удерживал людей от их обязательств. Мне удобнее выполнять практическую техническую работу, но я считаю, что это недостаточно масштабируется. Теперь я руковожу дизайном, просматриваю обзоры и даю много советов и поддерживаю руководителям команд, а часто и младшим разработчикам. Это продолжается уже около 4 лет, в целом у меня почти 15-летний опыт, я завершаю один проект и нахожусь на начальной стадии второго, и я хочу более четко определить, что я делаю.
Есть ли название для такой роли (технический архитектор?) и ресурсы для дальнейшего развития в ней? В качестве альтернативы, это просто знак, что мне следует либо сосредоточиться на развитии лучших навыков лидерства, либо на более специализированной роли, где я мог бы иметь большее влияние как личный вклад?
Действительно, термин в разработке программного обеспечения будет «технический руководитель» или «архитектор», может быть, «технический архитектор», если проект более разнообразен и имеет разных архитекторов. Поскольку названия не регулируются, это может быть что-то близкое к ним.
Я обнаружил, что это не столько роль социальных навыков, сколько управление. В менеджменте вам нужны навыки межличностного общения, чтобы продавать людям то , чем они на самом деле не хотят заниматься . Для технического архитектора это намного проще, потому что вам нужно продавать то, что они хотят делать. Ваши предложения должны облегчить их работу , если вы делаете свою работу правильно и ее нетрудно продать.
Так что да, полезно прочитать несколько книг о людях и управлении проектами, просто чтобы знать, что вы упускаете. Просто чтобы знать, на что другие действуют.
Лично мне очень нравится Peopleware , хотя он уже довольно старый.
Что более важно, так это ваши технические знания. Ваши программисты будут уважать вас за ваши технические знания. Так что вам нужно держать это в курсе. Даже на технологии, которые вы не используете, потому что вы должны знать, почему вы не используете эту технологию вместо этого.
Думаю, мне не нужно говорить вам, что делать в этом отношении. Книги, конференции, группы пользователей, хобби-проекты.
Одним из важных аспектов является то, что чем больше вы играете вспомогательную роль в обучении и планировании, тем больше вы теряете контакт с людьми, выполняющими реальную работу. Время от времени бросайте все свои книги и планы, отменяйте встречи и пачкайте ботинки. Возьмите билет и реализуйте его. Это важно, потому что вы столкнетесь с проблемами из первых рук и таким образом примете лучшие решения для своих программистов. Я видел слишком много архитекторов башни из слоновой кости, которые настаивают на том, чтобы делать это одним способом, в то время как компилятор настаивает на том, что это неправильно. Держите контакт с корнями и знайте, о чем вы говорите в деталях. Если ваши люди увидят, что вы можете делать то, что онидолжны сделать, гораздо легче убедить их сделать это также. Если ваше решение имеет 100% покрытие кода и отлично работает, его легко продать. Если вашему решению уже 5 лет и оно не поддерживается, людям будет трудно уважать ваше руководство. Практиковать то, что вы проповедуете.
Итак, вкратце:
Официального пути к этой работе или продвижения по ней нет. Вам нужно будет найти баланс между этими двумя.
Многие компании имеют технический и управленческий направления , и их названия определяются на местном уровне. Архитектор , технический руководитель и ведущий разработчик используются для руководства по техническому направлению.
Обычно в технической роли у вас есть растущий объем контроля над технической областью и любой повседневной деятельностью сотрудников в поддержку этой технологии. У вас не будет «ответственности за персонал» или прямых подчиненных. Ваша команда отчитывается перед начальником или коллегами.
Возможно, вы будете наставником своей команды. Ожидается, что вы будете тренировать их, поскольку коучинг направлен на достижение конкретной рабочей цели, а наставничество больше ориентировано на карьеру. Очевидно, что есть много серых зон, но общая тема заключается в том, что ваши взаимодействия основаны на том, что вы фокусируетесь на технологиях. (Многие люди могут использовать термины «коучинг» и «наставничество» по-разному, но здесь полезно провести различие. :-))
Независимо от того, решите ли вы перейти на управленческий путь или дальше по техническому, вашим следующим шагом будет приобретение навыков управления людьми. Так почему бы не сделать это и решить, как вы идете?
новичок