Как я могу перейти от разработчика программного обеспечения к менеджеру программного обеспечения или руководителю группы? [закрыто]

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

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

Очевидно, одна из моих главных мечтаний - создать какое-то программное обеспечение самостоятельно, которое в конечном итоге взорвется и сделает его большим, а затем начнет нанимать команду и делать все самому, но я чувствую, что шансы на это намного хуже чем просто немного изменить карьеру, чтобы попасть туда, куда я хочу. Я чувствую, что могу получить такое же удовлетворение, делая это для работодателя, а не для себя. Несмотря на то, что раньше я этого не чувствовал, я чувствую, что это было главным образом потому, что я не делаю то, что Я НАСТОЯЩИМ хочу сделать.

Любые советы, указатели или вещи, которые нужно иметь в виду? Кто-нибудь, кто сделал это, и если да, то как ты это сделал?

Переход от роли разработки программного обеспечения к управленческой или руководящей роли - это то, что требует времени. Я специализировался в разработке программного обеспечения, уделяя особое внимание процессу разработки программного обеспечения, и специализировался в управлении бизнесом и коммуникации. Даже с этим академическим опытом в том, как управлять проектами в области программного обеспечения, как набирать и нанимать, как руководить командами и как общаться с группами в устной и письменной форме, я обнаружил, что большинство управленческих и руководящих ролей, особенно в отрасли, которую я хотел чтобы работать в, требуется 5+ лет опыта в разработке программного обеспечения (у меня было 2, включая кооперативы и стажировки).

В то же время я просто продолжил учебу по темам управления проектами.

Первое, что я бы порекомендовал, это стать хорошим коммуникатором и переговорщиком. Узнайте, как вести разговор, который имеет значение. Даже как разработчик, есть решения, которые должны быть приняты с коллегами, клиентами и пользователями. Иногда вам приходится вести трудные разговоры и достигать соглашения, которое приносит пользу всем. Это непростая цель, но я бы порекомендовал эту книгу, которая называется « Трудные беседы: как обсудить, что важнее всего» . Есть и другие, такие как « Прошлое нет» и « Да»: переговоры по соглашению без сдачи , которые также будут полезны. Они актуальны независимо от того, в какой позиции вы находитесь.

С технической точки зрения, понимание жизненного цикла разработки программного обеспечения важно для руководства и управления командами разработчиков программного обеспечения. Лидерские должности, вероятно, означают, что вы участвуете в разработке требований, архитектуре систем программного обеспечения, проектировании, внедрении, тестировании и обеспечении качества, а также в задачах обслуживания. Хотя вы не можете быть экспертом во всем этом, менеджер или лидер должен по крайней мере понять их все. Как разработчик, вы, вероятно, выполняете большую часть своей работы в области проектирования, реализации и обслуживания, а также проводите некоторое тестирование. Я бы очень рекомендовал такие книги, как « Требования к программному обеспечению» (и его компаньон, « Подробнее о требованиях к программному обеспечению» ), « Архитектура программного обеспечения на практике» (хотя мой университет перешел наАрхитектура программных систем: работа с заинтересованными сторонами, использующими точки зрения и перспективы после того, как я прошел курс по архитектуре, и мне это было рекомендовано), а также Метрики и модели в разработке качества программного обеспечения .

С точки зрения управления проектами вы можете узнать о моделях процессов и методологиях. Существуют гибкие методы, такие как Scrum и Extreme Programming, и методы, основанные на планах, такие как Waterfall и Spiral. Существуют также методологические основы, такие как CMMI и Процесс персонального программного обеспечения / Процесс группового программного обеспечения. Те, которые имеют отношение к вам, зависят от того, где вы работаете, с точки зрения отрасли и компании. Существует множество книг по различным методологиям и структурам, но я очень рекомендую Rapid Development: Taming Wild Software Schedules для общего управления разработкой программного обеспечения и процессом разработки программного обеспечения.

Если вы хотите продолжить свое образование, вы можете взглянуть больше на путь технического менеджмента, чем на курс управления бизнесом. Если вы хотели получить должность технического менеджера, посмотрите на программы разработки программного обеспечения, управления разработкой программного обеспечения и управления проектированием. Для большей части управления бизнесом вы можете рассмотреть программы MBA, управление бизнесом или некоторые программы инженерного менеджмента, которые имеют сильный экономический или финансовый компонент.

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

Я не буду пытаться дать полный ответ, поскольку Томас Оуэнс уже перечислил несколько действительно хороших советов (+1 к этому).

Просто хотел добавить несколько советов / предложений:

1. Не ждите, пока кто-нибудь заставит вас вести; просто начни делать это. Я не имею в виду, идет против вашего нынешнего босса, но вместо этого взять инициативу, чтобы помочь ему. Если ваш босс похож на меня, он обычно перегружен слишком большим количеством задач / встреч на своей тарелке. Если он увидит, что вы указываете направление, в котором у него может не хватить времени, чтобы поспеть, он, скорее всего, будет более чем счастлив передать вам некоторые управленческие обязанности. Со временем, если вы сделаете это правильно, ваш босс будет делегировать вам все больше и больше (меньше беспокоиться о нем), и он, скорее всего, поддержит вас в принятии большей ответственности до такой степени, что вы будете официальным лидером.
2. Помните, что командообразование и лидерство больше связаны с социологией, чем с технологиями (из одной из популярных книг по методологии программного обеспечения, может быть, Брукс). Как цель, ваша цель состоит в том, чтобы понять людей и их поведение, что сильно отличается от понимания работы компьютеров. Без этой реализации хорошие инженеры становятся одними из худших командных лидеров, потому что они не делают этого умственного переключения и понимают, что вы не можете управлять людьми так же, как вы управляете машинами. Фактически, единственный подход, который, кажется, работает, состоит не в том, чтобы вообще контролировать людей, а в том, чтобы дать им направление. Читайте, читайте и продолжайте читать книги / статьи / блоги о лидерстве. Одна книга, которую я мог бы рекомендовать, является Управлением 3.0

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

Лично у меня нет желания покидать свою текущую должность в данный момент, но в зависимости от того, где мы находимся в цикле выпуска, я трачу от 10% до почти 100% своего времени на другие задачи, кроме написания кода. Если вы терпеливы и наблюдательны, есть много возможностей, которые вы можете использовать, чтобы сделать что-то кроме «просто кодирования» в вашей текущей позиции. Например:

• Доброволец для наставничества нового члена команды.
• Станьте экспертом по новым инструментам, процессам или технологиям, которые компания планирует внедрить.
• Волонтер для межфункциональных комитетов.
• Обсудите идеи, которые у вас есть.
• Пригласите себя планировать встречи для будущих функций.

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

Если вы хотите перейти на роль управления проектами, тогда совершенно не помешает посещать ночные занятия и работать над получением степени MBA.

Другой вариант - изучить сертификацию Свод знаний по управлению проектами PMBOK . Во многих местах вас не учтут, если у вас не будет нескольких лет реального лидерского опыта или одного из двух пунктов, перечисленных выше.

PMBOK - чрезвычайно сложный тест, и для его прохождения требуется МНОГО изучения. Я также думаю, что у них есть требования к фактическому управлению проектами и опыту руководства, чтобы иметь право пройти тест.

Для меня это звучит так, как будто вы хотите работать над управлением проектами. Большое количество позиций PM в разработке программного обеспечения также требует опыта кодирования.

Я бы искал должности, на которых вы могли бы перейти к обязанностям, которые обеспечат вам управление / лидерство, которое вы желаете. Перемещение вверх по лестнице может выглядеть по-разному в зависимости от того, как все работает там, где вы работаете. Но даже при небольшом опыте кодирования должности PM доступны, если у вас есть какой-либо лидерский опыт и опыт управления.