Як я можу перейти від розробника програмного забезпечення до менеджера програмного забезпечення або керівника команди? [зачинено]


42

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

Моє головне питання: який тип речей або можливостей я повинен шукати, що допоможе мені перейти в кар’єрі до більш управлінської ролі, а не до кодування. Як я вже говорив, я люблю кодувати, проте ще більше хотілося б мати можливість проектувати речі на високому рівні та організовувати команду таким чином, щоб це було зроблено, і слідкувати за їх прогресом, допомагаючи при цьому з технічними рішення тут і там. Такі речі справді роблять мене щасливим, на відміну від простого сидіння за столом, що кодує цілий день.

Очевидно, одна з моїх головних мрій - створити якесь програмне забезпечення самостійно, яке згодом підірветься та зробить його великим, а потім починаю наймати команду і робити все це самостійно, але я відчуваю, що шанси на те, що це стане, набагато гірші ніж просто змінити свій кар’єрний шлях, щоб дістатися туди, куди хочу піти. Я відчуваю, що можу отримати таке ж задоволення, роблячи це не роботодавцем, а роботодавцем. Незважаючи на те, що раніше я не відчував цього, я відчуваю, що це було головним чином тому, що я не роблю того, чого я ПОСТОЖЕНО хочу зробити.

Якісь поради, вказівки чи речі, які слід пам’ятати? Хто-небудь, хто зробив саме це, і якщо так, то як ви це зробили?


Який тип освіти ви маєте? Як довго ви були на своєму нинішньому становищі?
Томас Оуенс

Маю бакалаврат з інформатики. Я був на своєму нинішньому становищі близько року.

1
@slandau Я прямо зауважу, що ви не хочете вступити на роль прем'єр-міністра. при цьому це може бути очевидним напрямком; ваш опис та прагнення відрізняються від ролі прем'єр-міністра, і я не вірю, що роль прем'єр-міністра буде те, що ви нарешті шукаєте.
Аарон Маківер

1
@AaronMcIver Це залежить від місця роботи. Деякі прем’єр-міністри є діловими, деякі прем'єр-міністра мають більш технічний характер. В деяких місцях "інженер-менеджер" може бути більш поширеною назвою, а в інших - просто "інженером програмного забезпечення".
Томас Оуенс

2
Ну, по-перше, відмовтеся від своєї душі ... :-)
Пол Томблін

Відповіді:


41

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

Тим часом я просто продовжив навчання з питань управління проектами.

Перше, що я рекомендував би - стати хорошим комунікатором та переговорником. Дізнайтеся, як вести важливі розмови. Навіть як розробник, є рішення, які повинні бути прийняті з колегами, клієнтами та користувачами. Іноді доводиться вести важкі розмови та домовлятися, що приносить користь усім. Це непроста мета, але книга, яка важко розмовляє: як обговорити, що найбільше має значення, - це те, що я рекомендував би висвітлити цю проблему. Є й інші, на кшталт « Помилка минулого» та «Як дістатись до»: Переговорна угода, не надаючи цього, також буде корисною. Вони актуальні незалежно від того, в якій посаді ви знаходитесь.

Що стосується технічної сторони, розуміння життєвого циклу розробки програмного забезпечення є важливим для провідних та керуючих командами програм. Позиції лідерства, ймовірно, означають, що ви пов'язані з розробкою вимог, архітектурою програмного забезпечення, розробкою, впровадженням, тестуванням та забезпеченням якості та завданнями обслуговування. Хоча ви не можете бути експертом з усіх цих питань, керівник або керівник повинен хоча б розуміти їх усі. Як розробник, ви, ймовірно, виконуєте більшу частину роботи з проектування, впровадження та технічного обслуговування, проводячи також деякі тестування. Я дуже рекомендую такі книги, як вимоги до програмного забезпечення (і це супутник, докладніше про вимоги до програмного забезпечення ), архітектура програмного забезпечення на практиці (хоча мій університет перейшов наАрхітектура програмних систем: робота зі зацікавленими сторонами з використанням точок зору та перспектив після того, як я пройшов курс архітектури, і мені це рекомендували), а також метрики та моделі в інженерії якості програмного забезпечення .

З точки зору управління проектами, ви можете дізнатися про моделі та методики процесів. Існують спритні методи, такі як Scrum і Extreme програмування та керовані планами методи, такі як Водоспад і Спіраль. Існують також методичні рамки, такі як CMMI та Process Personal Process Process / Team Software Process. Ті, які стосуються вас, залежать від місця роботи, з точки зору галузі та компанії. Існує ряд книг з різних методологій та рамок, але я б дуже рекомендував швидкий розвиток: приборкання диких програм програм для загального управління програмним забезпеченням та інженерного процесу.

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


1
Так, але як ти насправді робиш перехід від старшого інженера-програміста до менеджера? Я маю на увазі, припустивши, що мені здається, що я знаю всі речі, які ви перераховували вище, що я зараз роблю, щоб довести, що можу це зробити, враховуючи, що я не маю офіційного досвіду рольових менеджерів і лише відчуваю, що я справді знаю всі ці речі? Як можна зробити цей крок?
trusktr

19

Ці інші відповіді чудові, але я заробляю 0,02 долара. Я перейшов від молодшого розробника в моїй теперішній компанії через звання до старшого розробника, а потім керівника команди та тепер архітектора. Минуло кілька років. Щоразу, коли мені дали підвищення по службі, це було тому, що я вже робив аспекти роботи, і менеджмент просто визнавав це і давав мені відповідне звання. Тому моя порада - не чекати, коли вам скажуть, що ви технічний керівник чи менеджер. Просто почніть брати на себе відповідальність, яку мають люди в цих ролях. Через кілька місяців або рік ви побачите, що ви в основному виконуєте роботу, на яку орієнтуєтесь, і можете вказати на це керівництву, якщо вони цього не помітили.


2
Мене звільнили за те, що я робив саме те, що ви сказали в одній компанії (а той керівник, який мене звільнив пізніше, також покинув компанію). Це було не дуже добре. Здавалося, що завжди була боротьба за те, щоб потрапити на вищі позиції в компанії, дуже конкурентоспроможна та егоцентрична. Набагато краще бути в компанії, де коли люди беруть на себе ініціативу, щоб спробувати виконати більші речі, ніж раніше, вони отримують підтримку, заохочення та напрямок від тих, хто вже вищий.
trusktr

9

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

Просто хотів додати кілька порад / пропозицій:

  1. Не чекайте, коли хтось змусить вас повести; просто почніть це робити. Я не маю на увазі, що йде проти вашого теперішнього начальника, але натомість проявляйте ініціативу, щоб допомогти йому. Якщо ваш начальник щось подібний до мого, він, як правило, перевантажений занадто великою кількістю завдань / нарад на своїй тарілці. Якщо він побачить, що ви надаєте напрямок там, де у нього може не вистачити часу, він, швидше за все, буде радий делегувати вам певну відповідальність з управління. З часом, якщо ви зробите це правильно, ваш начальник буде делегувати вам все більше і більше (менше за нього турбуватися), і він, швидше за все, підтримає вас у прийнятті на себе більшої відповідальності в точці, коли ви є офіційним керівником.
  2. Майте на увазі, що побудова команди та лідерство стосується більше соціології, ніж технології (з однієї з популярних методичних методичних книг, можливо Брукса). В якості ведучої, ви ставите перед собою завдання зрозуміти людей та їх поведінку, що дуже відрізняється від розуміння того, як працюють комп'ютери. Без цього усвідомлення хороші інженери роблять одні з найгірших команд, оскільки вони не здійснюють цей розумовий перехід і розуміють, що ви не можете керувати людьми так само, як ви керуєте машинами. Насправді єдиний підхід, який, здається, працює - це не контролювати людей взагалі, а давати їм вказівки. Читайте, читайте і продовжуйте читати книги / статті / блоги про лідерство. Я можу порекомендувати одну із книг - Management 3.0

... і зараз я збираюся переглянути посилання, які розмістив Томас



Це погана порада, яка дозволяє припустити, що хтось робить щось, що їх начальник не просив їх робити, більшість начальників нахмурилися на людей, які роблять те, про що не просили.
професор програмування

Я відповів на це запитання 5 років тому, коли був розробником. Повертаючись до цього, я отримую його для читання з точки зору менеджера. @Bonner - ти маєш рацію. там є різні менеджери з різними стилями. Деякі з вас нахмуряться, якщо ви зробите щось, про що не говорили. У такому випадку моя рада вам біжить від цього менеджера. З того часу, як я став ведучим, все, що я робив, - це навчити своїх хлопців самостійно мислити і робити мене змінним. Я прошу кожного балансувати між вузьким фокусом його власних завдань, але також поглянути на себе і побачити більш широку картину.
DXM

5

Я особисто не маю бажання залишати своє поточне положення на даний момент, але залежно від того, де ми перебуваємо в циклі випуску, я витрачаю десь від 10% до майже 100% свого часу на завдання, відмінні від кодування. Якщо ви терплячі та спостережливі, є багато можливостей, які ви можете скористатися, щоб зробити щось інше, ніж "просто кодування" у вашому поточному положенні. Наприклад:

  • Доброволець наставник нового члена команди.
  • Стати експертом у галузі нових інструментів, процесів чи технологій, які компанія розглядає.
  • Волонтер для міжфункціональних комітетів.
  • Говоріть про свої ідеї.
  • Запросіть себе на дизайнерські зустрічі для майбутніх функцій.

Нехай ваш менеджер знає, що вас цікавлять подібні можливості, і припускаючи, що ви добре справляєтесь зі своїми поточними обов'язками, він спрямовуватиме можливості до вас, коли вони з’являться. Ініціатива налічує багато. Більшість менеджерів дозволять вам спостерігати, навіть якщо вони не вважають, що ви зараз кваліфіковані.


4

Якщо ви хочете перейти на роль управління проектами, то абсолютно не завадить проводити нічні заняття та працювати над своїм MBA.

Ще одним варіантом було б ознайомитись із сертифікацією Органу управління проектами PMBOK . Багато місць вас не розглядатимуть, якщо у вас не буде декількох років фактичного лідерського досвіду чи одного з двох перерахованих вище пунктів.

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


3
Можливо, це лише я, але я б схилявся до ступеня управління інженерним програмним забезпеченням або ступеня інженерного менеджменту, особливо якщо ви хочете перейти до технічного менеджменту чи лідерства. Я бачив, як інженери отримують ступінь MBA і підштовхуються до ділової програми програмного забезпечення, насправді не керуючи та не ведучи інженерів.
Томас Оуенс

@ThomasOwens, це гарна примітка. Я завжди вагався отримати ступінь MBA, оскільки не був впевнений, що це переведе в більшість технічних місць чи ні.
slandau

Іспит PMP не все так важко.
Моронс

@Morons Я продовжую те, що декілька прем'єр-міністрів розповіли мені про свій досвід, я ніколи цього не приймав. Але тоді, коли я думаю про це, ці двоє людей не були такими яскравими.
maple_shaft

2

Мені це здається так, що ви, можливо, захочете працювати над управлінням проектами. Велика кількість позицій ПМ в рамках розробки програмного забезпечення також вимагає досвіду кодування.

Я б шукав посади, де ви можете перерости в обов'язки, які отримають вам керівництво / керівник, який ви хочете. Рухаючись по сходах, може виглядати по-різному залежно від того, як все працює там, де ти працюєш. Але навіть при меншій кількості досвіду кодування, посади ПМ доступні, якщо у вас є керівництво, досвід управління.


Про це було сказано в первісному запитанні: "... які речі чи можливості мені слід шукати, це допоможе мені просунути свою кар'єру до більш управлінської ролі, а не до ролі кодування ...". @slandau шукає поради, як це зробити.
Thomas Owens

1
Так, я згоден. Чи є у вас поради, як я б почав працювати над цим?
slandau

Так, я випадково натиснув кнопку "пост", перш ніж я мав намір.
Д ..

@D .., я маю певний досвід лідерства, але все це було на сторонніх проектах та проектах, які я робив ще в коледжі ... не впевнений, чи цього достатньо. Є це?
slandau

Швидше за все, ви не хочете орієнтуватися на будь-який професійний досвід, який дає вам це. Можливо, вам буде легше працювати над старшою роллю розробника в деяких місцях. Я б пильно стежив за тим, щоб відкриті позиції робили те, що ви хочете, перегляньте вимоги і скористайтеся будь-якою можливою можливістю, щоб отримати найпоширеніші з них. Більшість місць, де я працював, були невеликими, і мені дозволили акуратно перейти на наступний рівень без особливих зусиль. Подивіться на свою сьогоднішню роботу ... чи можете ви переїхати туди? Можливо, у вас визначений шлях, звідки ви зараз перебуваєте, яким можете скористатися.
Д ..
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.