PM Stories » софтуерен екип

Най-добрия начин да мотивирате своя екип

Майк Рам — Mon, 14 Apr 2008 08:38:09 +0000

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

Дайте възможност на хората от вашия екип да бъдат креативни!

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

Затова, моите съвети са следните:

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

Като изключим темата за парите – любима на всички българи – какво смятате вие, че е най-доброто средство за мотивиране на един софтуерен екип? Споделете и вашето мнение.

Между другото, Бас предлага безплатно ebook версия на своята книга “Surprise! Now You’re A Software Project Manager” на този, който даде най-интересния отговор на този въпрос, така че вижте неговия пост и дайте своя коментар там , за да имате шанс да спечелите книгата.

Тази статия е налична и на английски език.

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

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

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

Числата на Дънбар и размера на софтуерния екип

Майк Рам — Mon, 07 Apr 2008 16:44:22 +0000

R. I. M. Dunbar е бил антрополог в University College of London и на базата на изследвания на хора и примати е стигнал до извода, че максималния брой контакти, които човек може да поддържа активно в съзнанието си, е приблизително 150. Т.е. всяка една група може да бъде витална и да оцелее, ако има по-малко от 150 члена. Историята показва, че по-големите групи започват да се делят на по-малки щом броят на членовете им започне да надвишава това число. Оттук числото 150 започва да се нарича “числото на Дънбар”.

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

Моят опит показва, че най-малкият размер, при който групата е жизнена, е някъде между 5 и 9 човека.

Ако погледнем по-малките групи, можем да забележим, че група от двама може да бъде изключително креативна (попитайте който и да е родител), но често страда от недостиг на ресурси и поради това налага много голяма отдаденост и от двете страни. Естествено оттук трудностите на едно бизнес партньорство от двама души често да бъдат сравнявани с тези на един брак. Група от трима често е нестабилна, тъй като единият човек се чувства изолиран от другите двама или пък единия контролира другите двама накланяйки везните в полза на единия или другия партньор при вземането на решения. Група от 4-ма пък често се разделя на две двойки.

По мое мнение, едва при 5-ма члена започва усещането за “екип”. При група от 5 до 8 човека можете да имате събрание, на което всеки да може да се изкаже за работата на цялата група и всеки да се чувства упълномощен. Но при групи от 9 до 12 човека усещането започва да се разпада – вниманието, което всеки един член получава, вече не е достатъчно и срещите стават все по-шумни, по-скучни или по-дълги.

Същият принцип важи и в бизнеса. Падът, който настъпва при екипи над 12 човека налага създаването на специализирани отдели, които да се поемат от делегирани мениджъри. Проблемът е, че групата все още е малка и съответния мениджър става тежък overhead за екипа. Едва при разрастване над 25 човека разделението на отдели започва да става рентабилно, твърди Кристофър. При достигане на членска маса от 80 човека трудностите в комуникацията започват да се увеличават отново, докато при достигане на “числото на Дънбар” – 150 – отношенията между хората стават неуправляеми.

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

Подобни идеи има заложени и в някои от гъвкавите методологии за разработка на софтуер – Scrum препоръчва екипите да бъдат от 5 до 9 човека, за да бъдат най-ефективни, други препоръчват 3 до 7 човека.

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

Моята оценка е чисто емпирична, но съвпада с мнението на Кристофър Алън, че бройката трябва да е някъде между 5 и 9. При по-големи екипи започват да се сформират по-малки групички и групировки и често се получава нездрава конкуренция помежду им. Ако работата е голяма и налага много хора да се включат в разработването на даден продукт, добра практика е да се създават “feature teams”, т.е. екипи, които се занимават с разработката на отделен модул или feature и които да бъдат отново толкова малки, че да могат да се управляват ефективно. Проджект мениджмънта в този случай се изразява в управлението на няколкото екипа, които разработват отделните компоненти на продукта.

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

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

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

Ролята на бизнес анализатора – резултати от анкетата

Майк Рам — Sun, 09 Sep 2007 17:11:00 +0000

Вече повече от месец стои анкетата за ролята на бизнес анализатора в един софтуерен екип. Преди да я закрия, за да пусна нова, обявявам резултатите.

Въпрос: Как оценяте ролята на бизнес анализатора във вашия екип?
Общо отговорили: 27 човека (малко, но от сърце).

Отговори:

Много важна. Той проучва нуждите на клиента и го представлява пред екипа – 14 гласа (52%)
Всички роли са еднакво важни. БА отговаря за функционалната спецификация, която после програмистите реализират – 6 гласа (22%)
На нас такъв човек не ни трябва. Програмистите се оправят сами с анализа на клиентския бизнес – 4 гласа (15%)
Какво е това “бизнес анализатор”? – 3 гласа (11%)
Само се мотае наоколо и се прави на важен. Един прост JavaScript не може да напише – 0 гласа (0%)

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

Все пак, може да се отчете като положителен факта, че макар и с малко участници, отговорите показват, че в съвременните софтуерни екипи съществува позицията на бизнес анализатора и неговият труд се оценява по достойнство. Независимо дали се тачи високо (отговор 1) или просто се приема за равноправен член на екипа (отговор 2), бизнес анализатора заема своето утвърдено място в софтуерния екип (общо 20 гласа на двата въпроса, което прави към 74%)

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

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

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

Възможно е, обаче, и друго тълкувание. Фирмата може да е съставена само от “велики програмисти”, смятащи, че знаят и могат всичко – едни истински “многостранно развити личности” – идеалът на отминалото социалистическо общество, които вярват в идеята, че един програмист трябва да разбира от всички аспекти на софтуерния бизнес и специализация в отделни области като бизнес анализ, управление, тестване, обучение на потребители и т.н. не е нужна. Програмистът може всичко!

Много ми се ще да зная какво точно са имали предвид хората, отговорили по този начин. Призовавам ги да коментират този пост, пък дори и анонимно. Ще бъде полезно за всички.

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

Ролята на бизнес анализатора в един софтуерен екип

Майк Рам — Mon, 30 Jul 2007 12:07:00 +0000

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

Та, що е бизнес анализатор и има ли той почва у нас?

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

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

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

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

Безспорно най-важното качество е способността да общува с други хора. Craig Brown се е потрудил да изследва около 100 обяви за бизнес анализатори в САЩ, Англия и Австралия и в резултат е получил следната картинка за качествата, които най-много се ценят у бизнес анализаторите, според публикуваните обяви за работа:

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

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

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

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

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

Какви качества трябва да притежава човека на тази позиция?
Откъде да намерим такива хора?
Как да си ги отгледаме вътре в екипа?

Имате думата