Які навички я повинен розвивати, щоб стати лідером розвитку / технічної діяльності? [зачинено]


82

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

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

Як програміст зараз, які кроки я повинен зробити для досягнення цієї мети? Що я повинен надати пріоритет?


Чи є можливості у вашій нинішній компанії перейти до керівництва команди? Без досвіду керівництва команди, мені цікаво, чи занадто багато компаній наймають лише зсередини.
JeffO

@JeffO Я фактично просто змінив роботу. Я не знаю, чи в мене з’явиться можливість - я думаю, що є можливість, але це невеликий стартап, і я думаю, що буде лише один дивідент.
обідне м’ясо317

2
Лише одна навичка: вміння переконати людину, яка може дати цю позицію, дати цю позицію вам.
вихровий вовк

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

Відповіді:


90

Щоб стати технічним керівником, важливим є наступне

  • Можливість наставницького персоналу на будь-якому рівні вищого стажу, від того, хто вийшов з університету протягом 3 місяців, до людини, яка займається програмуванням протягом 30 років

  • Добре знання вашої сфери розвитку. Сюди входять: мови, рамки, утиліти, середовища розробки

  • Добре розуміння систем управління випуском, навичок управління проектами та контролю версій

  • Будьте вбивцею помилок

  • Знати, як проводити своєчасний перегляд коду, на що звернути увагу та як мінімізувати кількість часу, необхідного для його проведення, та зміни, які потрібно внести

  • Будьте в курсі подій у вашій галузі розробки. Наприклад, якби ви не вивчили нові рамки чи технології з .NET 2, ви б сьогодні робили речі досить зворотним шляхом.

  • Як писати одиничні тести та макети, а також змусити своїх розробників писати їх також

  • Знання, що таке шаблони дизайну, і коли їх використовувати

  • Знання того, що таке запах коду, і як пом'якшити їх

  • Постійна інтеграція

  • Можливість планувати проекти та випуски

Залежно від вашої організації та наявності у вас архітекторів, вам, ймовірно, потрібно знати наступне:

  • Можливість складати свої проекти та розбити його на функціональні частини

  • Ретельне розуміння безпеки, включаючи правильний спосіб обробки паролів, розділення систем, захист даних тощо

  • Поняття підприємства, такі як службові шини, черги повідомлень, BizTalk

  • Шаблони дизайну підприємства

  • Архітектури обслуговування / RPC, такі як SOAP та REST

  • Структури ORM, такі як сплячий режим, Entity Framework, доктрина

  • Постійне розгортання

  • Хмара

  • Можливість рекомендувати правильні технології для використання в проекті. Це може бути складно, якщо ваша команда / магазин займається лише .NET, PHP або Java.

  • Створіть програму таким чином, щоб майбутні вдосконалення легко розмістилися

Якщо ви будете менеджером з розвитку, вам також знадобляться:

  • Навички співбесіди та як знайти потрібного персоналу
  • Як вирішити проблеми людей із членами вашої команди
  • Керування бізнес-директивами / цілями та перетворення відповідних директив на інформацію для ваших розробників
  • Можливість оцінювати час для програмістів різних навичок
  • Можливість розподіляти завдання правильним розробникам виходячи з їхніх навичок та вмінь

І нарешті, деякі інші рекомендовані моменти:

  • Дізнайтеся поза межами домену розробки

  • Навчіться говорити " НІ", коли щось неможливо або виходить за межі або не суперечить обмеженням, таким як бюджет або час.

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

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

Незалежно від точної посади, будь-яка старша роль вимагає від вас здатності ефективно спілкуватися. Якщо ви не впевнений оратор, погляньте на те, як робити щось на кшталт Toast Masters (публічні виступи). Дізнайтеся, як встановити та утримати контакт очей. Бути впевнені. Одягайтеся відповідно до позиції. Подавати приклад.


2
Я просто замальовував деякі ідеї, про які міг швидко придумати. Я перегляну та додам більше пізніше. Гарне питання.
Сем

Я можу віднести переваги Toastmasters. Це мені дуже допомогло в кар’єрі. Вміти чітко повідомляти свої думки (особливо технічні думки людям, які не є технічними) - це неоціненний навик володіння.
Джейсон Світт

27

На мій досвід, Lead має трохи менше стосунків із брудною роботою практичного програмування і більше з управлінням. З цією метою я рекомендую наступне

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

  2. Навчіться багатозавдання та керувати часом . Якщо ви зараз добре в цьому, це приємно: розвивайте більше. Як розробник, ви просто переймаєтесь своїм поточним завданням / проектом. Як ведучий, у вас буде

    • Щоб відвідати більше зустрічей, ніж ви дбаєте. Це, мабуть, найбільш задумлива частина керівництва команди
    • Робота над розподілом ресурсів. Якщо вам пощастить, ресурсів буде мало, а проектів багато.
    • Очолюйте архітектуру та дизайн проекту
    • Залежно від розміру та структури організації, надайте безліч звітів, за графіком та вчасно. Подумайте про керівництво як менеджера проектів з низькою орендою.
  3. Підготуйтеся до ефективного делегування . Цей ІМО буде найскладнішим бітом, до якого слід пристосуватися. Як розробник, ви звикли бруднити руки, робити речі. Робити всі сантехніка та дослідження. Це доведеться зупинити або зменшити. Виходять концерти, ви подаєте їх команді. Ви отримаєте частину дії, не стільки, скільки звикли. І ви будете кусати язик, щоб протистояти спокусі, щоб кутові більше діяти для себе.

  4. Зважаючи на більш професійну лінію, розгляньте деякі тренінги, які не тільки підвищать ваші здібності, але й змінять ваш світогляд . Курс краху в управлінні програмним забезпеченням програмного забезпечення не зашкодить. Lean Six Sigma - це також дуже хороша навчальна програма (я можу засвідчити її ефективність), яка допоможе вам подивитися на вирішення проблем з більш логічного ракурсу. Не кажучи вже про те, що на керівній посаді ви готові до ще більш старших ролей, для яких знадобиться менше практичних технічних навичок і більше можливостей управління.

  5. Відточуйте свої спілкування та міжособистісні навички . Ви будете головною точкою вступу до вашої команди із зовнішнього світу. Ваш менеджер чи інший керівник прийде до вас першим. Інші підрозділи / команди вашої організації спочатку з вами взаємодіятимуть з будь-чим, що стосується команди. Ви керуєте найскладнішим і непередбачуваним ресурсом з усіх людей: людьми. Вам потрібно виростити товсту шкіру, навчитися ковтати велику кількість гордості та брати на себе відповідальність за невдачу своєї команди.


2
Чудові відповіді, мені подобається, як ви відзначили всі речі, про які, як розробник, ви взагалі не маєте поняття - зокрема делегацію. На останній роботі я делегував усе, що міг, і все ще мав гору речей, щоб тримати себе зайнятим. Тоді під час (рідкісних) вільних моментів я б робив "нудні" речі - пропоную допомогти виправити незначні помилки, документацію. Треба вести з фронту.
Роклан

2
+1 для того, щоб підкреслити, що "головні" ролі часто передбачають набагато більше управління, ніж технічні навички
Кріаз,

Це видатна відповідь і дійсно відображає суть ролі. Молодці.
Ллойд Мур

14

Те, що Сем не сказав, теж важливе:

  • Як проаналізувати речі та дати іншим розробникам роботу. Частина вашої роботи полягає в тому, щоб на 100% використовувати інших розробників. Написання специфікацій, які є однозначними, дуже важливо.

  • Як створити програму для скелета / прототипу, яку повинні дотримуватися всі інші

  • Як сприяти доброму настрою команди

  • Як відвідувати, їздити та вести зустрічі, як документувати пункти дій

  • Як оцінити, написати проект проекту та оновити план проекту

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

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

І хоча Сем це вже сказав, одна з найважливіших речей - це навчитися говорити "ні" . Ви будете робити це багато . Інший спосіб поглянути на це - сказати « так» , але «тільки якщо ми зможемо отримати більше грошей / часу / ресурсів» - або «це для другого випуску» :)


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

11

Все це - за книгою та хорошими відповідями. Дозвольте мене вразити тебе реальністю.
Вірите чи ні, велику частину часу ви витратите на пояснення менеджерам

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

Для цього вам потрібні навички пояснення технічних речей нетехнічним людям у нетехнічному плані. І це дуже важко. наприклад, розглянути можливість пояснення P = NP до 6-річного віку. На жаль, для цього немає офіційного навчання, і вам доведеться навчатись його самостійно.

Крім того, це позиція, коли політичний ш * т починає вражати вас. Менеджер скаже вам, що ви віддаєте перевагу людині, оскільки він / вона слідкує за процесом, але ви знаєте, що особа не має жодної користі у вашій команді з різних причин, від браку технічних навичок до недоброго члена команди. Тож вам все одно доведеться не тільки працювати з цією людиною, але й давати хороші оцінки цій людині. Навпаки - людина, яка має хороші навички та дуже ефективний член команди, але яка не знає, як догодити керівництву, а отже, отримує менше рейтингів.
Потім трапляються марні зустрічі, коли хтось займає високу посаду з віддаленого місця, читаючи лекції про ефективні процеси та про те, як його / її остання зміна процесу сприятиме підвищенню продуктивності. Ви повинні знати, як приховати своє нудне обличчя і виглядати енергійно.


1
"Ви повинні знати, як приховати своє нудне обличчя та виглядати енергійним" ха-ха
Адріан.

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