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

Іноді я не можу витримати, коли керівники проектів просять мене оцінити час для виконання різних завдань. Оцінка - здогад, і здогадки можуть помилятися. Як правило, погані вимоги та документація призведуть до поганих здогадок.

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

Моє питання тоді: чи повинні хороші менеджери проектів мати досвід програмування?

Або , може бути , це питання має бути, робити хороші керівники проектів повинні були хорошим програмістом раніше? Чи є кореляція?

Управління ІТ-проектами, безумовно, не те саме, що управління іншими проектами. Я колись чув про керівника проекту без досвіду ІТ. Він зрештою засмутив програмістів і в основному відлякував їх.

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

Менеджер із сильним технічним досвідом зазвичай краще розуміє, як "думає" їх команда. Завжди краще мати менеджера, який вас розуміє, чи не так?

№. Два абсолютно різних навички. Поганий керівник проекту - це не обов'язково людина, яка не розуміє ІТ, і навпаки.

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

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

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

Аргумент щодо здатності керівників проектів без технічного досвіду трохи нагадує мені таке:

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

Що стосується давання оцінок, то це реальність життя на будь-якій роботі. Ви ніколи не зможете придбати будинок, побудований вчасно, якби електрик не міг сказати вам, скільки часу знадобиться йому, щоб зробити електропроводку - коли ви знаєте, щоб забронювати ваших стін? Я погоджуюсь, що в ІТ дуже важко давати оцінки через велику кількість неправдоподібних. Клієнти не завжди знають, чого хочуть, і вони, як правило, забувають розповісти вам купу речей. Те, що я раніше робив, - це приблизно, скільки часу я вважав, що це займе, а потім помножте його на 2! І хороший керівник програми не повинен розіп'яти вас, коли ваша оцінка виявиться невірною, це призведе до того, що він перестане організовувати графік, поговорить із замовником, пояснить начальникам, що це обійдеться дорожче тощо тощо. це частина їх роботи - знову ж таки, в основному те, що потрібно.

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

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

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

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

Я не думаю, що менеджер проектів ІТ-проекту вимагає ІТ-досвіду. Але він / вона повинен неодмінно розуміти ІТ і повинен знати, як працюють ІТ-проекти.

Хоча ІТ-фон є додатковою перевагою, його відсутність не робить нікого не дуже хорошим менеджером ІТ-проектів. Також наявність ІТ-досвіду не є вирішальним фактором.

Я працював з обома типами, і кожен мав свій унікальний набір якостей та проблем.

ІТ-фон:
- Зрозумів би, коли ми говоримо про помилку в роботі, тому що код не є багатопотоковою
- Але в деяких ситуаціях сказали б "ей давай, це просто додавання 4 рядків коду, ти можеш це зробити за 10 днів"

Без передумови для ІТ:
- Було б дуже зручно вести переговори щодо зміни строку зручності
- Для проекту без будь-яких вимог (взагалі, поки що), іноді можна сказати «чи можемо ми дати приблизну оцінку 100 днів і згадати 30% буфер.

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

@NimChimpsky Я згоден.

Справа в тому, що , а не як (Активне слухання - приємний інструмент).

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

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

Ні.

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

Хороший чи поганий керівник проекту може мати будь-яке походження:

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

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

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

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

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

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

Або крайність погана, на мій погляд; Люди з надто малим досвідом програмування можуть сліпо довіряти своїм програмістам (Шепард слідкує за вівцями); Люди з надто великим досвідом можуть постійно ставити під сумнів зусилля своєї команди (мікроуправління).

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

Безумовно.

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

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

У будь-якому випадку є цей хлопець, який він нічого не розуміє, як працює сервер, як працює веб-сторінка, як працює програмування тощо. Іноді мені здається, що він нічого не знає. Тому кожен раз, коли я намагаюся дати йому зрозуміти, що ми маємо робити зараз, або в чому полягає проблема в тому, що ми маємо на даний момент, він нічого не розуміє. І він не такий хлопець, який би сказав "Почекай на секунду. Чи можеш ти повторити, що я насправді не дуже розумію цього". Ні, він такий тип хлопця, який не хоче показувати, що нічого не розумів у всій розмові.

Але це не закінчується, тому що він зателефонував замовнику та розповідає щось, що в основному не відповідає дійсності. І в кінцевому підсумку ми повинні зателефонувати замовнику разом, щоб знову зрозуміти.

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

До речі, оскільки я працюю з ним, моя робота вже не є цікавою.

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

Технічні навички не роблять хорошого керівника, хороші навички управління. Це може бути корисно, якщо менеджер провів свій час у «окопах», оскільки вони можуть оцінити процес, який миряни не можуть мати. Однак це також може спричинити за собою своєрідну контрольну вигадку, якої не мають навіть керівники мирян-контролерів. Вони можуть спробувати виконати всю роботу самі або уважно вивчити вашу вкрай незручно.

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

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

Здається, якась плутанина:

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

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

Ви можете бути прем'єр-міністром - це ви: А) розумієте, як керувати проектами В) розумієте процес розробки. Жодне з них не вимагає знань з кодування, але це може допомогти.

Визначення того, чи програмісти будуть достатньо виконані, не є завданням прем'єр-міністра, якщо він не виступає в ролі лідера команди. Щоб знати, чи хтось «димить» про час для виконання завдання, менеджер завжди матиме перевагу, якщо він зрозуміє, що пов’язано.

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

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

Коротка відповідь полягає в тому, що практичний досвід кодування не є необхідним програмним забезпеченням хорошого програмного забезпечення, але зазвичай він є кращим. Найважливішим для того, щоб бути здатним прем'єр-міністром, є розуміння процесу розробки (незалежно від методології, що використовується) та довіра розробникам, які бажають і вміють виконувати свою роботу. Досвід розвитку дає практичні знання про цей процес, тому він допомагає. Прем'єр-міністри, які працюють по сходах в компанії, додатково знають корпоративну культуру (і кодову базу) і мають зв'язок з іншими членами команди розробників, які довго служать, і саме тому ІМО пропонують найкращі прем'єр-міністри зсередини бути принесеним ззовні. Якщо хтось поза компанією може керувати командою краще, ніж хтось ізсередини, речі ДУЖЕ неправильні.

Одне, що я згадав - це взаємозв'язок між прем'єр-міністром та командою розробників. Це і на міжособистісному, і на технічному рівні. Ключовим тут є спілкування; дияволи повинні відчувати, що можуть поставити проблеми, як технічні, так і міжособистісні, прем'єр-міністру, і прем'єр-міністр повинен зрозуміти членів команди розробників, коли описують проблему.

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

Якщо коротко, менеджер прийме вашу оцінку за номіналом лише в одному з трьох сценаріїв:

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

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

Я поняття не маю, але мені потрібні певні технічні знання. Іноді пояснити його неможливо.