PM Stories » Работа в екип

Гнилите ябълки в екипа

Майк Рам — Mon, 09 Feb 2009 08:14:20 +0000

Така Steve McConnell нарича в книгата си Rapid Development онези членове на екипа, които не само не успяват да се сработят с останалите, но и активно се противопоставят (да не кажа “саботират”) на екипната работа. Хората, които ме познават, знаят, че почитам изключително много тази книга и нейния автор, но може би малцина знаят, че точно тази тема е една от най-важните и най-спорните в книгата и че аз категорично подкрепям позицията, че такива хора не само вършат много малко полезна работа, но и лесно могат да разрушат всичко, което екипът е постигнал.

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

За темата ме подсети Jeff Atwood, който е също верен (по)читател на McConnell и даже е нарекъл своя блог по името на една от рубриките в книгата.

Ето как можем да разпознаем такива хора в екипа си:

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

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

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

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

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

Вие как мислите? Трябва ли да толерираме онези, които не помагат на работата на екипа, единаците, онези, които преследват някакъв собствен интерес в проекта?

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

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

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

5 неща, които никога не бива да казвате на шефа си

Майк Рам — Mon, 17 Nov 2008 13:16:38 +0000

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

1. Никога на говорете само за технологии.

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

2. Има само една технология.

Всички софтуерни разработчици и ИТ специалисти си имат любима технология. Дали това е език за програмиране, среда за разработка, операционна система или нещо друго – те се привързват много силно към тази технология и всички решения, които предлагат, са базирани на нея. Живеем в свят на голямо разнообразие на бизнес проблеми и технически решения и това налага да имаме по-широк поглед върху възможностите, които можем да предложим. Не бива да забравяме, че основната ни цел е да решим бизнес проблема на нашия клиент. Независимо от личните ни предпочитания, това, което предлагаме, трябва да бъде решението, което в най-голяма степен и най-ефективно решава този проблем. Робуването на една определена технология може да ни изиграе лоша шега и в стратегическо отношение и да ни остави вън от големия бизнес, ако не успеем навреме да усетим тенденциите на развитие. Някой да си спомня за PowerBuilder, за Clipper, за Delphi?

3. Лоши думи за колегите си.

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

4. Няма начин.

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

5. Изненада.

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

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

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

Мантри на мотивацията или съставките на един успешен проект

Майк Рам — Tue, 05 Aug 2008 08:47:33 +0000

Статистиката показва, че все още провалените или проблемните проекти са много повече от успешните. Особено пък в областта на софтуерното производство. Умните глави все още мислят над въпроса: “Къде сбъркахме?” Аз, обаче попаднах на нещо много ценно – точните съставки, които могат да доведат един проект до успех.

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

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

Ето ги и тях – мантрите на мотивацията:

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

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

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

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

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

Хиляда лева за мотивация. Нова анкета

Майк Рам — Tue, 15 Jul 2008 08:42:40 +0000

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

Предложил съм няколко варианта. Имайки предвид резултатите от по-предишната анкета, предполагаме, че екипът ви е от десетина човека. В новата анкета, в горната дясна част на сайта, съм ви предложил няколко примера:

Бихте могли да организирате голям купон с ядене и пиене за целия екип (може и с половинките) и да профукате всичките пари наведнъж. Някои наричат това “тийм билдинг”.
За хора, работещи по цял ден пред компютър, всички знаем колко е важно да имаме ергономични мебели и оборудване. Бихте могли да им купите хубави и скъпи столове, за да не ги болят гърбовете или пък нови монитори, за да им е по-удобно да виждат всичко на екрана. Проблемът е, че тези неща са скъпи (особено мониторите) и парите няма да ви стигнат, за да можете да купите на всички. Бихте ли избрали решение, при което само някои хора от екипа ще бъдат облагодетелствани?
Най-демократичното решение, може би, би било да се похарчат всичките пари за бира в пластмасови бутилки и чипс. Така ще запасим офиса за дълги времена с ценната течност. Проблемът е, че някои може и да не пият бира.
Можете да вложите парите в професионалното развитие на своя екип. Тук дилемата е дали да пратите няколко човека на специализиран курс или да купите книги за всички.
Справедливо решение е може би просто да се раздадат пари на всеки като бонус за добре свършената работа. Проблемът е, че ако имате 10 човека в екипа, бонусът ще бъде средно по 100 лева, което не е кой знае колко мотивиращо.
Разбира се, можете и да задържите парите и да ги похарчите за себе си. Приемаме, че шефът няма да ви държи точна сметка, така че решението остава изцяло на вашата съвест.

Можете да давате и други идеи в коментарите отдолу. Мисля, че въпросът си струва да си поразмърдаме малко мозъците

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

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

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

Предимства и недостатъци на малкия екип

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

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

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

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

Не, че малкият бенд не свири по правилата – просто ги интерпретира по различен начин. Изводът в проектната организация е аналогичен – и малкият, и големият екип трябва да се управляват по някакъв процес, но те са различни в двата случая. Както се казва по американски – one size doesn’t fit all.

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

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

Разбира се, малкият екип има и своите преимущества, които в много случаи са много по-сериозен аргумент в негова полза.

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

Надявам се, че тези няколко аргумента са достатъчна храна за размисъл за вас как да структурирате и организирате собствения си екип. В статията има и много полезни съвети как да се организира работата на един малък екип – струва си да се прочете цялата.

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

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

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

Ако “Властелинът на пръстените” беше проект…

Майк Рам — Wed, 16 Apr 2008 10:11:34 +0000

… кой щеше да е проджект мениджъра?

Този въпрос разглежда Diane Ellis в блога PM Hut и той звучи съвсем разумно. Приключението, което предприемат главните герои има всички характеристики на един проект:

Имат ясна цел и задачи
Имат екип от хора (и не само), които имат ясно изразени (макар и неизказани) роли
Всички членове на екипа трябва да работят заедно, за да постигнат набелязаната цел
Има ясно определен краен срок, в рамките на който целта трябва да бъде постигната

ОК, имаме проект, но кой е мениджърът? Преди да решим кой е шефа на проекта, авторката ни припомня какви са неговите основните задължения:

Носи изключителната отговорност за успеха или провала на проекта
Изготвя план и бюджет на проекта
Осигурява ефективни ресурси за проекта
Следи за изпълнението на плана и бюджета
Управлява качеството на работата, рисковете и проблемите
Управлява ежедневните задачи
Комуникира статуса на проекта с основните заинтересовани лица (stakeholders)

Според авторката, във филма има четирима герои, които могат да бъдат посочени за ръководители на този проект – Арагорн, Гандалф, Фродо и Елронд. Кой, обаче, е истинският проджект мениджър, ви предлагам да разберете сами, като прочетете цялата статия

Обърнете внимание и на последния въпрос, който авторката задава: Ако проектът се беше провалил, дали избраният ПиЕм щеше да поеме отговорността изцяло?

Прочетете статията, пък после можете да напишете дали сте съгласни с нейното мнение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Майк Рам — 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:

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

Чудесен пример за ефективни събрания

Майк Рам — Mon, 10 Mar 2008 09:51:17 +0000

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

Историята, която ме впечатли, и която искам да споделя с вас, я разказва Cheri Baker в своя блог The Enlightened Manager. Чери е собственик на консултантска фирма по мениджмънт, а историята се случва в един екип, с който тя е работила като консултант и е присъствала на едно от техните събрания, което я е впечатлило с бодрия и позитивен дух на участниците и с невероятната ефективност на работата на екипа. Примерът е много ценен и с това, че важи навсякъде, независимо от конкретната професионална област.

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

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

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

Изказване на благодарност. Още в самото начало на срещата, водещия приканва всеки от участниците да изрази своята благодарност към колегите си. И тук не става въпроса за някакво лицемерно четкане, а за искрена признателност към колегите за съвсем конкретни действия. Чери цитира следните изказвания:

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

“Бих искал да благодаря на Маги, че ме измъкна от огъня миналата седмица, когато компютърът ми се счупи – тя ми помогна да си отпечатам справките, когато го бях закъсал.”

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

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

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

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

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

Рекламно съобщение: На 13.03.2008 в София ще се проведе курс по основи на управлението на софтуерни проекти, воден от мен. Курсът е полезен за всеки, който се интересува професионално от разработка на софтуер. Повече информация за него можете да намерите в блога PM Stories, в блога Спри и помисли! и на официалния сайт на RammSoft.

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

Най-важните правила в делегирането

Майк Рам — Thu, 24 Jan 2008 13:08:13 +0000

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

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

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

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

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

Кой е отговорен за проекта?