PM Stories » екип

Кой решава дали да стартира един проект?

Майк Рам — Thu, 20 Nov 2008 10:44:10 +0000

Във връзка с поредния курс по управление на проекти, който подготвяме в RammSoft, посветен на стартирането на един проект, искам да ви попитам кой е човекът или факторът, който решава дали да се започне един проект във вашата компания или не.

Дали това е главният изпълнителен директор (The Big Boss) или друг отдел във фирмата (маркетинг, финанси, счетоводство), дали проектният мениджър и екипът, който ще изпълнява поетия проект, имат право на глас във вземането на това решение или то се взема от неведоми външни сили?

Гласувайте в новата анкета на блога (горе вдясно) и подкрепете вашия глас с коментар. Имате право да изберете не повече от 3 опции.

Гласувайте за тази статия в Svejo.net:

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

Вижте и тези публикации:

Оптималният размер на екипа е ясен

Майк Рам — Fri, 04 Jul 2008 13:38:51 +0000

Като постоя достатъчно дълго време, анкетата за оптималния размер на екипа успя да събере доста гласове (цели 96) и придоби някаква представителност, макар и само в рамките на този блог.

Въпросът беше: Какъв е оптималния размер на един софтуерен екип? Ето и вашите отговори:

3-5 човека (40%, 38 гласа)
5-9 човека (32%, 31 гласа)
10-20 човека (11%, 11 гласа)
2-ма души (приятели) (10%, 10 гласа)
над 40 човека (3%, 3 гласа)
1 човек (freelancer) (2%, 2 гласа)
20-40 човека (1%, 1 гласа)

Очевидно е, че за повечето от вас малкият екип е много по-ефективен – ако обобщим първите два резултата, излиза, че цели 72% от вас подкрепят това мнение.

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

Подобна е и логиката за екипи между 10 и 20 човек, за които са гласували 11% от вас. Такъв екип е необходим при по-големи проекти, където се налага и по-голяма специализация на различните членове, но ако се налага да направим един простичък уеб сайт, едва ли е необходимо да стреляме с топ по врабчета, т. е. по-големите екипи са по-трудно управляеми и са по-неефективни за по-малки задачи.

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

Радвам се, че проявявате все по-голям интерес и по-голяма активност в анкетите, които публикувам в този блог. Надявам се, че въпросите са смислени и интересни за вас. Благодаря на всички за участието! Очаквайте следващите анкети!

Гласувайте за тази статия в Svejo.net:

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

Вижте и тези публикации:

Кой тества вашия продукт? Резултати от анкетата

Майк Рам — Wed, 02 Apr 2008 13:32:37 +0000

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

Въпросът беше: Кой тества вашия продукт? Общо гласувалите в анкетата са 66 човека, като разпределението на отговорите е следното:

Тестери – членове на проектния екип (36%, 24 гласа)
Отдел по качеството във фирмата (23%, 15 гласа)
Програмистите (23%, 15 гласа)
Клиентът (18%, 12 гласа)

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

Това, което ме плаши, е, че 41% от отговорите показват, че в тези фирми на практика няма тестване. Съвременните практики в контрола на качеството изискват на този процес да се посвети много време, знания и усилия, за да се предотврати издаването на софтуер със сериозни бъгове в него. Да оставиш тази дейност в ръцете на програмистите е дълбоко погрешно. Първо, те нямат възможността да погледнат на своята работа отстрани, за да открият дълбоко заровените бъгове. Второ, нямат и времето да се занимават сериозно с това, тъй като обикновено са натоварени над 100% с разработка.

Още по-тревожен е процентът на хората, отговорили, че оставят клиента сам да си тества продукта. Това е направо самоубийствен подход! Клиентът може и да няма представа от процеса на софтуерна разработка и при първоначално тестване ще се сблъска с множество дребни (в нашите очи) бъгове, които могат дълбоко да разклатят неговото доверие в нас като специалисти и във фирмата като цяло. Много често, в резултат на тестването, клиентът изпада във враждебно отношение и в един момент забравя, че софтуерът, който сме разработили за него, служи за облекчаване на неговия труд, и се вманиачава в откриване на нови и нови бъгове, доказващи нашата професионална некадърност (в неговите очи).

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

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Кой тества вашия продукт?

Майк Рам — Sun, 20 Jan 2008 16:14:45 +0000

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

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

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

В други фирми пък за тестването отговаря специален отдел по качеството, който не се числи към нито един проект, а извършва оценка на качеството на всички продукти, които се разработват в компанията. Обикновено този отдел се ръководи от Quality Manager – човек, който има последната дума по отношение на това дали продуктът покрива критериите за качество, зададени при самото стартиране на проекта. На този тип организация му казват Testing as service или тестването като услуга.

Въпросът е: кой е по-ефективният метод и кой е по-подходящ за нашия проект?

Напоследък се налага организация от типа “тестване като услуга”, може би поради това, че тестерите от отдела по качеството могат да бъдат по-ефективно натоварени. От друга страна, тестването като услуга има и своите недостатъци, един от които е изискването за предварително подготвена детайлна документация, което на практика е рядко срещано явление – най-вече поради постоянно променящите се изисквания от страна на възложителя.

В подкрепа на организацията, при която тестерите са равноправни членове на проектния екип, Johanna Rothman е публикувала един пост в блога PM Hut, озаглавен Тестването не е услуга. В него тя аргументира своята позиция със следното:

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

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

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

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

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Съвети от едно "плешиво куче"

Майк Рам — Thu, 26 Jul 2007 11:52:00 +0000

Под заглавието A Bald Dog Can Teach Us New Tricks в блога на PM Hut се появи статия на Elizabeth Harrin, в която тя споделя в резюме интервюто си с Tom “Bald Dog” Varjan – авторитетен бизнес-консултант в Англия – по въпросите на управлението на проекти.

Както и много други специалисти Varjan също смята, че основното предизвикателство и съответно основен проблем в управлението на проекти, са хората – както личните качества на проджект мениджъра, така и способността му да ръководи, мотивира и вдъхновява хората от своя екип. Според него в повечето случаи на провалени проекти се оказва, че “проектния екип всъщност не е никакъв екип, а просто сбор от хора със свои собствени планове”. След това той изброява и основните причини за това:

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

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