< Browse > Home / SQA, Управление на проекти / Blog article: QA като PM

| Mobile | RSS

QA като PM

July 22nd, 2008 | 43 мнения | Публикувано в SQA, Управление на проекти

sqa управление на проекти
Тези дни проведох един интересен разговор. В него ставаше въпрос затова дали QA специалист може да бъде ръководител проект. Разбира се, аз защитавах позицията че може, дори има много примери за това. Отсрещната страна в дискусията също беше QA Lead. За него един QA не може да е ръководител проект на софтуерни разработки, защото ако дойде един старши програмист и го попитал някакъв казус, няма да мога да му отговоря. Тук се предполага, че дадената фирма ще има ресурс, ще се отдели нужното време за research и изследване на проблема, след което ще се вземе решение.
Нима, за да си ръководител проект трябва да бъдеш програмист ? Нима ръководител проект трябва да пише код, а не да контролира и координира процеса и жизнения цикъл на проекта ?
Много странно ми стана за позицията на този човек – QA може да е ръководител проект само на чисти QA-ски проекти.

Доста PM-та четат този блог, а и хора, заемащи места във висшият мениджмънт. Искам да ви попитам вас, какво мислите по този въпрос. Бихте ли доверили проект на QA, дори и да не е старши програмист и да не е запознат изцяло с програмистките задължения :) ?
Нима трябва да си “техничар-програмист”, за да можеш да управляваш процеса на създаване на софтуерния продукт ?

Картинката е взета от www.areait.info

About the author

Kalin4y Консултант по управление на онлайн репутация (ORM), е-PR и e-маркетинг, SEO оптимизация и email маркетинг. За контакти e-mail: [email protected], skype: kalin4y_eha или Google

Leave a Reply 5438 views, 1 so far today |
Follow Discussion

43 Responses to “QA като PM”

  1. Stilgar Says:

    Мne.

  2. Ник Says:

    Ако има управленски манталитет, ама да не е bossy що не. На мене предишния ми шеф незнаеше да програмира на PHP, ама това не му пречеше да ръководи проектите ни.

    Това, че девелопер дойде да пита ръководителя защо не влиза в даден if() или нещо друго … ама ПМ-а е точно човек, който спазва сроковете и поставя задачи, а девелопера трябва да пита старшията /senior-a си/ що, или ако самият е старши да си намери решението сам :)

    Принципно ПМ-а е за секретарки, защото повечето време пишеш документи, правиш срещи и съгласувания и според мене със сигурност не трябва да програмира. Освен ако целия проект не се движи от един човек, то тогава той ще е и PM, Dev и QA :)

    Така го разбирам аз

  3. Манол Says:

    PM Мениджъра трябва да има познания най – малкото, за да управлява проект. Винаги най – добрите PM ( за софтуерен проект ) са програмисти, иначе не се познава добре технологията, и не може да се взимат акуратни решения, а преценката на програмиста, който изпълнява проекта, може да не е най – доброто за проекта, поради липса на опит примерно.

  4. Светльо Бляхов Says:

    Аз съм на малко по-различно мнение от горе изказаните коментари. PM-а си е PM. Ако dev дойде да пита PM защо не влиза в if(), то тогава по-добре PM-a да му каже да си ходи. :)
    Доста зависи от фирмената политика и наистина има може би около 60% от фирмите, където PM е x-Dev. Според мен обаче PM трябва да разбира от основите на програмирането и да знае кое е добре и кое не за даден проект, но не и да пише код по него.
    Не съм съгласен, че PM трябва да е бивш програмист, защото това, че е добър в кода не значи, че ще е добър PM. Кодът на проекта може да е написан перфектно, но въпреки това крайния продукт да не става за “чеп за зеле” както се казва :) ПМ-а има повече координаторска и бизнес анализаторска роля.
    Колкото до въпроса на Калин…
    Мисля, че по-добре PM-a да е и QA, отколкото QA-a да е и PM. :)

  5. Николай Says:

    Аз съм програмист и мога да ти кажа, че в чистия си вариант дали “може” – отговорът е абсолютно – ДА. А дори понякога е и по-добре да не разбираш. Да не стигаме до PMBOK, където се казва, че винаги можеш да стигнеш до човек с експертно мнение, който да ти обясни за какво става дума. Project Manager-a ако следва всички процеси описани в PMBOK няма да има никакъв проблем. Иначе да си експерт в областта в която е проекта винаги е от . Сега остава въпроса дали ти си само QA или знаеш как се управляват проекти? Аз до колкото сме разговаряли мисля, че си от втория тип хора.

  6. Kalin4y Says:

    Манол, не мисля, че познаването на една или друга технология за разработка на софтуер, може да те направи по-добър мениджър проект. До колкото ми е известно на мен, колкото повече един РМ започва да коди и да ревизира кода, толкова повече почва да “бяга” от основните си задължения. Да не казвам, че почва да изоставя проекта.

    Светльо, съгласен съм с теб. РМ-то е редно да дава насоки как да се направи нещо, каква да бъде логиката, а да не казва на програмиста как да го накоди. Все пак това си му е негово задължение и разрешаването на даден проблем, свързан с техническото изпълнение трябва да се взема след консултации с по-запознати. Един РМ, било то и програмист, не може да разбира от всичко … какво правим тогава ?

    Ники, мерси за подкрепата. Наистина вярвам, че може да не си програмист и пак да доведеш екипа и проекта до успешен завършек. Стига да притежаваш нужните умения.

    По стечения на обстоятелствата станах свидетел, как един отличен програмист го повишиха до PM. С ръка на сърцето мога да кажа, че е отличен кодър и притежава добри умения за справяне с технически проблеми. Но от гледна точка на управлението не ставаше. Викаше на членове на екипа, не всички участваха в работните срещи, сядаше и захващаше да пише код, като “хулеше” младши програмистите, защо са написали това или онова.
    Просто нямаше лидерски умения да обедини екипа около общата цел.Преди всичко трябва да можеш и да имаш умения за ръководене да поведеш екипа към общата цел, а това че не можеш да отговориш как да направят един по-сложен джойн или иф … затова имам ресурс, има предвидено време за търсене на решение.

  7. Stilgar Says:

    Nе triabva da se izvurtat neshtata. Nikoi ne e kazal, che shtom si bil programist shte stanesh dobur (ili izobshto niakakuv PM). Nikoi ne spori, che ne vseki programist stava za PM. Vuprosut e obratnia dali triabva da si kodil za da moje da si PM.

    Spored men PM-a tria da moje da kaje shto ne vliza v onia if. Ako ne moje za kvo mi e toia PM? Osven tva kak shte vzema reshenia ako ne znae tehnologichnia background? Posle triabva da nosi otgovornost za tova. Razbira se ako proekta e mnogo ogromen (50 ) choveka moje shefa nai-otgore da ne otbira ot kod, no togava pod nego shte ima 3-4 pod-PM-a deto otbirat.

  8. Манол Says:

    от опит го казвам , имал съм жена мениждърка, която е изключително и само мениждърка и sales, говорише с клиенти, координираше проектите. Тази жена сега е само sales, project manager стана единият дизайнер ( запознат с технологията ). Защото мениджъра трябва да взима решения кой коя задача да изпълни ( и с коя технология ). Да, изискват се лидерски умения, Не се изискват програмистки умения, но мениджъра трябва да е в крак с технологиите и да работи в тясна връзка с главния програмист ( ако има такъв и самия той не е програмист ). Иначе [email protected] :)

  9. Николай Says:

    stilgar, защо PM-a трябва да ти казва за IF-a? PM-a отговаря за хората, ресурсите, планирането и една камара други неща, ако той ще ти казва за IF-a. Просто нека не пропускаме и други позиции като Technical Lead, Solution Architect. Това са хората с най-голям technical background, те ще ти кажат за IF-a ако ги попиташ, а понякога и без. PM-a има съвсем други задължения. Понякога самото програмиране се случва и то навреме, но пак проекта закъснява…

  10. Николай Says:

    Манол, защо шефа решава кой коя задача да поеме. Това трябва да става заедно с екипа и всеки да каже къде е добър и силен, за да вземе подходящата задача.

  11. Stilgar Says:

    Misliа, che proektite deto ima iasno izrazeni roli “Technical Lead” i “Solution Architect” spadat v kategoriata na proektite s nad 50 choveka ekip. Interesno obache kak PM-a e stanal takuv bez da mine prez vuprosnite pozicii predi tova. Izvednuj e stanal PM? Neshto kato Junior PM?

    if-a e mnogo vajen shtoto spored men vseki problem ako ne moje da se reshi izpluva nagore i nakraia triabva da stigne do choveka koito nosi otgovornostta. Razbira se che niama da se razplacha i da izticham pri PM-a pri purvia problem s if, no predstavi si che ne moga da go resha? Tozi nad men sushto ne moje da go reshi? Togava kvo pravim?

  12. Kalin4y Says:

    Stilgar, съмнявам се, че само ти ще си единственият програмист във фирмата. Затова е екипа, да се справя заедно с даден проблем или ситуация. Един човек, просто няма как да знае отговора на всички въпроси и решението на всички проблеми :)

  13. Stilgar Says:

    Аko shte da znae. Vajnoto e, che triabva da moje da nameri. Da nameri niakoi da nameri znam li:)

    Az kato biah susobstvenik na internet zala sum izpulniaval vsiakakvi dlujnosti. Administriral sum mrejite, pazaruval sum hardware, bil sum operator na smiana (mnogokratno) i sum chistil kenefa (mnogokratno). Ne, che e niamalo hora deto im se e plashtalo da praviat tezi neshta, no koi bil bolen, koi ne doshul na rabota (posle bil uvolnen ama kvo ot tva?), nakraia tozi, koito nosi otgovornostta triabva da moje da se opravi s problemite nishto, che ne mu e rabota. Mislia che i PM-a triabva da e taka. Triabva da moje da debugne if-a i da chisti kenefite ako se naloji. Ne znam dali tova e nai-tochnoto sravnenie, no taka go vijdam az.

  14. Kalin4y Says:

    Мишо, значи толкова сте били и шефове, щом не сте могли да мотивирате членовете на екипа си :)

  15. Манол Says:

    @Николай във фирмите, в които съм работил, е нямало практика да се събере екипа и да се обсъди кой е най добър в нещо, че на него да му се даде някаква задача. По скоро по “хубост” се избират :)

  16. Николай Says:

    Още малко по темата. Не бъркайте PM-a със шеф. Той не винаги седи над вас и не винаги взема повече пари. По принцип зависи от организацията (фирмата). Понякога PM-a може да бъде и човек изобщо не разбиращ технологии и въпреки всичко да се справя с проектите. Управлението на проекти включва много повече неща от това да се напише софтуер.

  17. Николай Says:

    Понеже ми стана много интересна темата – реших да я продължа http://nyordanov.blogspot.com/2008/07/project-manager.html

  18. Никола Дачев Says:

    Моя отговор е – зависи.

    За малки и отработени технически проекти QA би могъл да бъде успешен PM.

    За по сериозните неща си трябва аналитик(архитект) минал преди това през Senior Programmer. Дори да изключим изискването за техническа грамотност на по високо ниво QA практиките само ще пречет в повечето етапи преди края на проекта.

    Ще ви дам пример от реалния живот:
    QA=счетоводител
    PM=мениджър
    тотално различни роли и начин на мислене. Единия създава а другия вкарва в шаблон. Единия гони бъдещи цели – другия гони настоящ баланс. За едното ти трябва напредничаво мислене – за другото назадничаво.

    Досега не съм виждал счетоводител(по призвание) да е станал читав мениджър.

  19. Kalin4y Says:

    Какво значи за вкарва в шаблон ? QA не е само човек, които да гледа къде да ти грешките и да пише някакви неща по стандарти. Една от най-големите софтуерни компании в Германия, а до колкото знам и една доста солидна, френска, която има офиси и в България, QA и BA се изпълняват от един човек. Обхваща се целия процес на комуникация и ефективност на даденото приложение.
    Да се върнем на темата – отново не съм съгласен, че трябва да си бил старши програмист, за да бъдеш добър РМ.
    Никола, защо намесваш тук QA практики ? Говорим изцяло за управление на проекти, а не даден програмист или QA да пренесе практиката си на работа в процеса на проекта. Доста е неуместно това. По същата логика, програмист ще пренесе собствените си принципи на работа, ще започне на върши 100 неща едновременно, ще започне да кодва и къде отиде проекта тогава ?

  20. Stilgar Says:

    Be ne znam kvi shefove sme bili, ama to vseki moje da e shef na ekip ot trudoliubivi i otgovorni hora na proekt deto e dobre izmislen, sus zamrazena specifikacia i vuobshte si vurvi gladkо. To taka moje i bez PM. Det se vika: “Vseki moje da ebe krasivi. Istinskia ebach ebe i grozni”.

  21. Ivan Says:

    Пониакога спецификата на проекта изисква от ПМ-а да навлиза в много роли – системен архитект, хеад девелопер, БА, ЯА, тестер, ментор на новобранците. В такива случаи подобно предизвикателство би поел единствено човек с течницал бацкгроунд, защото БА или ЯА просто ниама да могат да се справиат. В големи компании с установени процеси и голиам ресурс вероиатно един ПМ ниама да триабва да влиза вьв всички тези роли, но в млади компании често се налага ниакои, както Мишо каза по-горе, да чисти кенефа от време на време.
    Дори Билл Порталски е бил девелопер, а вийте каде е сега (ниакои бьркат девелопер с цодер, както пониакога пониатиата тестер и ЯА са замениат едно с друго). Да се надиаваме, че ще видим един ден и ЯА с постийениата ба Билл :).

    П.С. Калине, направи си едно цоде ревиев на блога, два пьти постнах с непьлни данни (липсваше ми емаила) и ведньж на латиница и поста ми отиде в небитието.

  22. Ivan Says:

    ЯА = QA :)

  23. Никола Дачав Says:

    >>Никола, защо намесваш тук QA практики ? Говорим изцяло за
    >> управление на проекти, а не даден програмист или QA да
    >> пренесе практиката си на работа в процеса на проекта. Доста е
    >> неуместно това. По същата логика, програмист ще пренесе
    >> собствените си принципи на работа, ще започне на върши 100
    >> неща едновременно, ще започне да кодва и къде отиде проекта тогава ?
    Калине, разбирасе че ще си пренасяш привичките в известна степен когато се занимаваш с нещо ново.

    Явно не си ме разбрал обаче. Казах че където тяма техничесто предизвикателство не е необходимо да си бил developer за да си PM. Т.е. когата се правят познати неща.
    Иначе единствено те спасява ако има аналитик/архитект, който да ти избута нещата, но ако има такъв ти би бил излишен ;) Ако няма такъв и има техническо предизвикателство е класичаски случай на прецакан проект, защото всичко зависи от човек, който не разбира материята а ако изобщо има някой който разбира то той обикновено няма правата/гласноста/мотивацията да поеме тази отговорност. Да не говорим, че ако не си технически грамотен, разработчиците ще те литват с архитектурата и сроковете, както им падне.

  24. Stilgar Says:

    Оsven tova devs sa edni stranni, naduti kopeleta deto gledat nakrivo hora bez tech background. Ako PM-a e legenda, no ne e kodil ot 10 godini (realno ne razbira kolkoto tekushtite devs) e OK, no ako nikoga ne e hodil prosto niama da go ebavat.

  25. Nikolay Says:

    Ами има много начини да накараш програмистите да те уважават. Аз имах PM, който примерно (това го разбрахме накрая) е управлявал създаването на първите предавания на Стани Богат. През целия проект абсолютно всички уважавахме супер много PМ-a и се радвахме и забавлявахме с него, без изобщо да усещаме technical background. Заедно преминахме супер много пречки и предизвикателства. Той просто ни вдъхновяваше да успеем с проекта. Дори накрая всеки от програмистите се наложи да пошофира из България за да успеем да направим 117 инсталации в рамките на 5 дена. Така, че това, че няма да те уважават ако не си с tech background въобще не е вярно.

  26. Kalin4y Says:

    Май тук изпускаме и най-важното умение на един РМ. То е нито техническо образование, нито дали е минал през старши програмист.
    Говоря затова той да бъде лидер и да умее да обедини екипа. Щом не можеш да обединиш екипа си към постигане на общата цел за какво говорим тогава :)

    Ванка, латиницата е забранена. Мишо успя да хакне плъгина, ама той нали си е машина :)

  27. Stilgar Says:

    Nikоi ne tvurdi che nai-vajnoto za PM e da ima tehnicheski background, no spored men e neobhodimo uslovie. Kakto kazah ne vseki programist moje da stane PM samo shtoto imal tehnicheski background, obache ako niama shte se razpurdi rabotata. Moje da ne e v purvia proekt, moje da ne e i v 10tia no rano ili kusno shte se razpurdi.

  28. Stoyanoff Says:

    Може и QA да бъде, но защо?

  29. Ivan Says:

    Tova, che “obediniavaneto na ekipa” bilo nai-vajnoto, sa meko kazano stranni prikazki. PM ne e prezident ta da obediniava naciata, ima mnogo po-vajni zadachi za tazi dlajnost. A “obediniavaneto na ekipa” se sluchva kato sledstvie na uspeshno zavarshenia proekt. Neka ne slagame karucata pred magaretо.

  30. Nikolay Says:

    Малко ми писна този спор. PM-a трябва да управлява проекта – това няма нищо общо с програмиране – ама грам.

  31. Stilgar Says:

    Оsven ako celta na proekta ne e suzdavane na software…

  32. Ivan Says:

    Kаto ti e pisnal spora ne pishi :).

  33. Nikolay Says:

    Един последен коментар от мен. Разберете, че Управлението на Проекти е 90 процента комуникация и това умение е номер 1. Помислете върху това. Помислете колко проекти са се прецакали защото някой си е замълчал за нещо.

  34. Stilgar Says:

    Pоchti kolkoto sa se precakali zaradi losh kod. Da ne govorim za tezi v koito niakoi si e zamulchal za loshia kod:)

  35. Ivan Says:

    There are many ways to skin a cаt.

  36. entwickler Says:

    Понеже доста поговорихме имам един въпрос, на който искам да ми отговорят само хората които са програмисти/технически background и са PM-и.
    Как се справяте с конфликтите в няколко стъпки?

  37. Никола Дачав Says:

    PM е относно цели(milestones), ресурси, организация на ресурсите и срокове. Ако нямаш пряк поглед върху тези неща не си PM а само се изживяваш като такъв(по всяка вероятност само временно). Всяко нещо което спомага за работата по горните, като комуникационни способности например, е полезно но не задължително условие.

    И така, ако проекта е свързан с разработка съдържаща техничаско предизвикателство, ако не си с подходящ технически опит то нямаш никаква идея нито какви ресурси имаш, нито къде точно ти се явяват стъпките/целите нито какви са сроковете, за които могат да бъдат постигнати. Това е просто и ясно.

    Ако проекта не съдържа елементи пречещи ти на качествен поглед върху горните неща и кръвар да си, нищо не ти пречи да го водиш.

    @entwickler 3 стъпки – со кротце, со благо и со кютек ;)

  38. Stilgar Says:

    Znаchi az ne sum PM, niamam nervi i ne jelaia da stavam, no shte si pozvolia da otgovoria. Ima dva varianta

    Tehnicheskia podhod:

    1. Slagash breakpoint v ekipa kudeto ima problem i debugvash.
    2. Ako ima deadlock sinhronizrash kritichnata sekcia.
    3. Ako ima problem s komunikaciata znachi niakakuv event ne se vdiga. Proverete dali ekipa e aboniran za vsichki neobhodimi eventi.
    4. Ako ima problemi s performance-a togava probvaite da keshirate chast ot zadachite i da izpolzvate pooling za zadachi za koito sa neobhodimi mnogo resursi za inicializacia.

    Pravilnia nachin:

    1. Vuvejda se fizzariadka za ekipa. Vseki den se idva predi rabota praviat se uprajnenia i 5-50 obikolki na sgradata na ofisa (tochnia broi zavisi ot razmera na sgradata).
    2. Ako tova ne pomogne vsichki da praviat licevi opori pri vsiaka izdunka na chlen ot ekipa.
    3. Ako i tova ne pomogne e red na vikaneto.
    4. Ako i tova ne pomogne se prebiva chlen ot ekipa za nazidanie.
    5. Ako i tova ne pomogne se obesva DRUG chlen na ekipa na lampata i se ostava da visi tam za nazidanie.

  39. Майк Рам Says:

    Малко съм изпуснал дискусията, но все пак ще дам един глас в полза на PM-a като PM :-)

    За да ръководиш проекти се изискват определени качества и ако наистина ги притежаваш, няма проблем да заемеш този пост. Въобще не е задължително да си програмист, но е добре да разбираш от технологията. Тук е голямото неразбиране на някои програмисти, че проджект мениджъра трябва да им казва какво да програмират. За тази цел си има Team Lead и Architect, както казва Ники. Те дават насоките и поставят задачите от технически характер. PM-ът се занимава с това да дефинира процеса, да планира етапите на по-високо ниво, да отстранява пречките пред екипа и да взема решения. Ако проблемите са твърде технически, точно хората от екипа му трябва да му дадат съвет, подкрепен с аргументи, а не да му подливат вода, както често се случва у нас.

    Колкото до въпроса, който Калинчу поставя, аз заставам зад мнението на Светльо – по-правилно е PM-ът да изпълнява и функцията на QA Manager, тъй като той е отговорен за целия проект, което включва и качеството на изработвания продукт. Обратното има смисъл само ако QA Lead-а има подходящата квалификация и тогава говорим вече не за заместване, а за кариерно развитие.

  40. Kalin4y Says:

    Майк, напълно те подкрепям :)
    Предполага се, че един човек когато е поставен за шеф проект, то той трябва да отговаря за самият цикъл на разработката, контролира и координира дейността на екипа. Никога не съм твърдял, че за да си РМ може да не знаеш нищо за технологията, но не е задължително да си бил старши програмист. Стига да обясниш кое как трябва да стане от към бизнес логика, а задачата на програмиста е да го накоди. Предполага се, че в дадената фирма ще има старши програмисти (ресурс) към който може да се обърнеш по всяко едно време, ако даден член на екипа среща трудности.

  41. Илияна Says:

    Попаднах наскоро на блога ти :) Относно темата “QA специалист може да бъде ръководител проект”, за мен въпроса е можеш ли ти като QA да бъдеш ръководител проект?
    Моженето се определя от човека, неговите лични качества и желанието му да успее. Ако имаш желание, знания и умения, нищо не може да те ограничи да бъдеш какъвто си поискаш :)
    Сега на примависта се сещам за един човек започнал преди години много успешна в момента ИТ фирма. Човека е бил психиатър :)
    Само ти можеш да си поставиш ограничения и никое друго мнение няма значение.
    Успех!

  42. Kalin4y Says:

    Илияна, добре казано. Искаше ми да чуя и другата страна. А и доста хора ми писаха по IM, вместо да пишат тук – незнам защо.
    Наистина, за да си добър РМ ти трябват и нужните умения, знания и да ти “идва отвътре” да управляваш и координираш работата на другите. А това дали си минал през старши програмист или не – не е гаранция, че ще се реализираш като добър ръководител.

    П.П. още си чакаме тортата :P

  43. Кирилгео Says:

    Ръководителят на проекта е този, който може да го води.
    Т.е. да възложи задачите, да следи сроковете и качество на изпълнение (да не се отплесвам в общопознатите бла-бла).

    Погрешно е схващането, че най-добрия или опитен програмист трябва да бъде лидер на проекта. Освен, че е отличен програмист той може ли да мотивира хората, да делегира отговорности, да търси отговорност, да взима трудни решения и да ги отстоява, да се бори с бизнес партньорите, да намира пари и ресурси допълнително, да това и онова…
    Колкото един проект е по-комплексен, толкова по-малко нужно е да бъде водачът му най-добрия програмист!

    Поздрави,

Leave a Reply