Не се задълбавайте в технически проблеми

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

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

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

Ако проектът е относително малък и твоите задачи като проджект мениджър не могат да те натоварят на 100%, тогава е по-добре да ръководиш няколко проекта, отколкото да работиш като програмист и като проджект мениджър едновременно. Ако пък наистина се налага да изпълняваш и ролята на разработчик, да речем поради недостиг на кадри, избери за себе си по-тривиални и по-малко важни задачи, а делегирай по-важните и отговорни неща на хората от екипа, които могат да им посветят цялото си време и внимание. Ако си наистина опитен програмист, ще имаш и задачите да бъдеш наставник и помощник на екипа си и времето, което ще ти остава за писане на код, ще бъде изключително малко. Затова не рискувай успеха на проекта поемайки задачи, които може и да не успееш да изпълниш.

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

Този пост е публикуван и на английски език. Можете да изпратите този линк на ваши колеги и познати, които не говорят български.

Гласувайте за тази статия в Svejo.net: [wp:svejo-net]

Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл

13 Comments

  • […] This post is also available in Bulgarian language.  […]

  • […] Рам добре е написал какви грешки, могат да допуснат младите ръководител проекти, с не голям опит зад гърба си). Когато се окажете […]

  • Статията е наистина интересна и поставя добри въпроси относно правилния ход на работния процес. Аз обаче имам един малко страничен въпрос към автора.
    А именно:
    “Какво значение оказва според теб това дали PM-а е бивш програмист или е човек с общи познания в програмирането, но с други по-развити личностни качества?” (що се отнася до управляване на проекти от IT сферата).

    Благодаря предварително за отговора 🙂

    Поздрави!

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

    За съжаление, в практиката често се случва топ-програмисти да бъдат произвеждани в проджект мениджъри. Това не винаги е правилен ход. Първо, поставяйки му управленски задачи, губиш един ценен разработчик и второ, той може лесно да изпадне в ситуация като описаната в този пост – да се задълбае в някакъв технически проблем и да пренебрегне мениджърските си задължения.

    Аз самият съм минал по същия път – от програмист към ПМ, но просто в един момент спрях да пиша код, за да не смесвам двете работи. За да успее проджект мениджъра в такъв момент е важно да има доверие в хората от екипа си и да повярва, че те могат да свършат програмистката работа достатъчно добре.

  • SEO says:

    Добре, но какво правим с случай, че РМ е доста вдлъбен в себе си и не позволява до известна степен критика от членове на екипа. До колкото ми е известно, комуникацията и страничните мнения допринасят за правилния път на екип проект. Когато РМ изпитва и влага лични пристрастия и взаимоотношения към даден човек от екипа…това как ще въздейства на работата ? Още повече, че ако настройва и ръководните кадри към този човек, защото те му имат доверие и са го направили РМ.

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

    SEO: И двата зададени въпроса от твоя страна мисля, че са с отрицателен отговор. Лошо е за PM да не приема критика от хората, с които работи, още повече ако са му подчинени и той иска те да го уважават. Колкото до личното отношение към точно определен човек в екипа… това е доста деструктивна сила за целия екип.

  • SEO says:

    В такъв случай, имам едно просто въпросче:
    Заслужава ли, този човек да бъде РМ ? 🙂

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

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

    Ако се окаже, че ти имаш личен конфликт с него и проблемът не е в неговите качества, а в невъзможността вие двамата да общувате нормално, тогава по-добре признай този факт пред висшия мениджмънт и просто поискай да бъдеш преместен в друг проект.

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

    Вярно е, че в днешно време много хора попадат на такива позиции без знания и опит по стечение на обстоятелствата, но дори и това не означава, че не стават за тази работа. Понякога просто трябва повече време и малко формално обучение, за да се научи човека да се справя по-добре. Разбира се, някои хора наистина не са подходящи за тази професия, ако например не са достатъчно комуникативни, но за да направиш правилна оценка на характера на един човек е необходимо да го познаваш наистина много добре.

    Така че не бъркай личния конфликт с това дали човек притежава качества да си върши работата или не. Ясно е, че вие двамата не можете да работите заедно, но може да се окаже, че без теб проектът ще върви по-добре, отколкото без него. Кой тогава не си е на мястото? Помисли над това.

  • Maya says:

    Дискусията предизвикана от SEO започва да прераства в другарски съд. Не мисля, че има еднозначен и правилен отговор на последният му въпрос. Очевидно е, че има много емоции в цитираната ситуация. Освен това какъвто и отговор да дадем, едва ли би помогнал в решаването на проблема, защото не знаем каква е реалната ситуация, не сме запознати с фактите, както и с мнението на ответната страна.

    Правилното поведение според мен в този случай е да проведеш откровен разговор с въпросния ПМ, да му разкажеш как се чувстваш в създалата се ситуация, да споделиш какво очакваш от него и от останалите от екипа, както и как виждаш твоята роля и отговорност. Докато проблемите не се извадят на масата, няма как да бъдат решени. Трупането на емоции и обсъждането с трети лица, които не са вътре в ситуацията може само те настрои негативно. Ако искаш да се справиш с проблемите, трябва да търсиш конструктивни решения, а не съчувствие.

  • SEO says:

    @Maya: не търся съчувствие…както каза, по мое настояване седнахме да си поговорим. Според него няма място за притеснение и проблем. По време на разговора една “лукава” усмивка не слезна от лицето му. Положението се нормализира за известно време и след една моя конструктивна критика скоро време … пак се появи това отношение.

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

  • links for 2008-02-09 says:

    […] Не се задълбавайте в технически проблеми Не рискувай успеха на проекта поемайки задачи, които може и да не успееш да изпълниш. (tags: управление-на-проекти проджект-мениджър) […]

  • […] а не от действителните нужди на бизнеса, както и задълбаването в технически проблеми и загърбването на елементарни управленски задължения […]

  • […] с други думи казано: Не се занимавайте с дреболии. Не си губете времето в неща, които не носят полза. Не […]

Leave a Reply

Your email address will not be published. Required fields are marked *