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

Публикувано от Майк Рам на 09.02.2009 г. в 10:14 часа

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

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

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

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

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

Продължи към пълния текст »

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

Публикувано от Майк Рам на 17.11.2008 г. в 15:16 часа

reporting to the boss

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

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

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

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

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

Продължи към пълния текст »

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

Публикувано от Майк Рам на 05.08.2008 г. в 10:47 часа

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

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

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

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

Продължи към пълния текст »

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

Публикувано от Майк Рам на 15.07.2008 г. в 10:42 часа

Cash

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

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

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

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

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

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

Публикувано от Майк Рам на 21.04.2008 г. в 18:00 часа

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

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

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

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

Продължи към пълния текст »

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

Публикувано от Майк Рам на 16.04.2008 г. в 12:11 часа

Fellowship

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

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

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

Продължи към пълния текст »

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

Публикувано от Майк Рам на 14.04.2008 г. в 10:38 часа

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

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

Продължи към пълния текст »

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

Публикувано от Майк Рам на 07.04.2008 г. в 18:44 часа

team

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

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

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

Продължи към пълния текст »

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

Публикувано от Майк Рам на 10.03.2008 г. в 11:51 часа

Meeting

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

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

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

Продължи към пълния текст »

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

Публикувано от Майк Рам на 24.01.2008 г. в 15:08 часа

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

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

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

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

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

По-стари публикации →