Herding Cats
“Herding” произлиза от “herd”, което означава “стадо”. “Herding” е отглеждането на животни в стадо. Употребява се най-често за овце и крави. Каубоите в Америка и Австралия се занимават с този тежък, но благороден труд. На български изразът “herding” би могъл да се преведе като “да пасеш”, макар че това не описва достатъчно пълно дейността по отглеждането на едно животно в стадо. Кравите и овцете освен, че ги пасат, също ги и стрижат, доят, израждат и т. н.
Предполагам, че добихте представа за какво иде реч като дейност. Е, сега си представете да пасете и отглеждате котки в такова стадо!
Всеки, който е имал поне малко вземане-даване с котки, знае, че котката е животно индивидуалист и никога не би живяла с други животни в стадо. Котката има собствено мнение и не се поддава на дресировка, нито изпълнява заповеди. Точно затова, изразът “да пасеш стадо от котки” или “herding cats” се използва в професионалния жаргон за работата на един проджект мениджър, особено в областта на информационните технологии.
Програмистите са точно като котките - интелигентни, но своенравни и особняци. Трудно общуват с други хора и не понасят стадния начин на живот и работа. Можете ли да си представите колко е трудно за един шеф на проект да ги накара да работят в един екип, да си помагат и да спазват срокове и технически изисквания? Ето това е “да пасеш котки” 
Благодарение на Craig Brown, открих един изключително забавен клип, в който е представен тежкия живот на каубоите, които пасат котки. В крайна сметка това е, което правим ние, когато управляваме нашите проекти - herding cats.
Гласувайте за тази статия в Svejo.net:
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се за съдържанието му чрез RSS feed или по имейл.
Категории: Професията на проджект мениджъра, Хумор | Няма коментари
6 съвета за повишаване на ефективността на програмистите
Програмистите са особено племе. Хем са най-обикновени служители (т.е. не изпълняват никакви ръководни функции), хем са високо квалифицирани, скъпи и трудно заменяеми. Това принуждава мениджмънта да се опитва да “изстиска” максимална производителност от тях. Само че, поради навик или поради ограничено мислене, единственият механизъм, който повечето мениджъри прилагат, е увеличаване на работното време. За съжаление, той винаги води до изтощаване - физическо и психическо - и до напускането на програмиста, което едва ли е бил целения резултат.
Ето няколко съвета, които ако не пряко, то косвено могат също да доведат до повишаване на производителността на програмиста, без да разрушават неговата мотивация или здраве.
1. Поддържайте съвременни хардуерни конфигурации.
Съвременните информационни технологии се развиват с главоломна скорост. Един компютър, който миналата година е бил последен писък на технологията, днес вече е не само морално остарял, но и не достатъчно ефективен. Ако някои процедури, като компилирането, например, отнемат по 5 минути, това води не само да чиста загуба на време (особено ако тази дейност се извършва по няколко пъти на ден), но и прекъсва творческата мисъл на програмиста. Понякога изчакването на подобна операция може да го изнерви, с което допълнително се нарушава работния му ритъм. Връщането в режим на креативно мислене, може да отнеме до половин час на всяко едно прекъсване. Като вземем предвид и факта, че цената на хардуера е значително по-ниска от заплатата на програмиста, ще разберем, че наистина няма смисъл да се пести от разходите по техническото оборудване, защото качествения хардуер несъмнено води до по-висока производителност.
2. Не карайте програмистите да “откриват топлата вода”.
Купете всички компоненти, визуални контроли и библиотеки, които екипът прецени, че могат да свършат работа. Щом едно нещо е разработено от други хора и може да влезе в употреба - купете го, вместо да карате вашите програмисти да го разработват наново. Възползвайте се от труда и времето, които други хора са инвестирали, вместо да ги инвестирате и вие. Не карайте вашия екип да открива топлата вода отново, а ги фокусирайте върху специфичните особености на предметната област, която автоматизирате.
Категории: Разработка на софтуер | 7 коментара
Прегърни програмист (Hug a Developer)
“Hug a developer” или “Прегърни програмист” е един филм за нашата професионална действителност, направен с много любов, хумор и малко тъга. Героите на филма мълчаливо показват надписи, направени от картон и флумастер, разказващи за тежкия професионален (а и личен) живот на съвременния програмист.
Филмът е направен преди доста време, но аз го открих съвсем наскоро, благодарение на Michel. За тези, които не знаят английски (срамота!), текстът на горния надпис гласи:
Прекарвам половината си дни в събрания за това как да работим повече (вместо просто да работим)
За тези, които разбират английски - можете да видите целия филм при Мишел или в YouTube. Струва си!
Гласувайте за тази статия в Svejo.net:
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се за съдържанието му чрез RSS feed или по имейл.
Категории: Разработка на софтуер, Хумор | 2 коментара
Планирането отгоре надолу (top-down planning) - добро или лошо?
Наскоро попаднах на една много странна статия, в която се казва, че планирането отгоре надолу е грешен подход, който неминуемо ще доведе до провал на проекта. Авторът твърди, че при този подход проектните мениджъри или даже още по-големите шефове правят плана и не дават на никой друг да участва. Поради това, а и поради факта, че на тези позиции поставят хора, които са достигнали нивото си на некомпетентност, авторът вади заключението, че такъв план не струва.
Моята теза е, че планирането отгоре надолу е техника за планиране, а не за управление на проекти. То казва как ще се направи плана, а не кой ще го прави. Ако мениджърите ви са некомпетентни, естествено е, че проектът ще пропадне, но причината за това няма да бъде в начина на планиране, а просто в некомпетентното управление.
Вижте цялата публикация в английската версия на блога.
Гласувайте за тази статия в Svejo.net:
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се за съдържанието му чрез RSS feed или по имейл.
Категории: Управление на проекти | 1 коментар
Ежедневието ми на бизнес аналитик
Прави ми впечатление че когато говоря за бизнес анализ хората често имат доста различна представа какво означава това. И колкото по-дълбоко изпадам в описание какво е бизнес анализ, толкова по-недоверчиво ме гледат.
Затова реших да напиша нещата които реално върша в рамките на работния ден, като се надявам да помогне на заинтересованите да си изградят представа. При други аналитици е различно, но обикновено има някакво сходство, за да е дисциплината една и съща.
1. Документиране – най-известната и обикновено най-досадната дейност на бизнес аналитиците. Проблемът, който се налага да избегна тук, е от 5 души екип по проекта и 3 поръчителя да има 15 различни представи какво точно трябва да се свърши. Софтуерната спецификация е средство за това, но не единствено и често недостатъчно надеждно.
2. Описание на процеси – не се занимавам с описание на процесите на организацията. Описанието на процеси в моя случай е в много по-ограничен обхват – когато променим системите неизбежно някой ще промени начина си на работа. Това, което трябва да опиша, е как се вършат нещата сега и как ще се вършат след промяната на системите. Целта е да илюстрирам на програмистите каква всъщност е целта на разработката, която правят. Също така да илюстрирам в детайли на “бизнеса” какво се опитват да постигнат.
Категории: Бизнес анализ, Гост-автори | 4 коментара
100-те най-иновативни технологични компании за 2008 г.
Списание CIO публикува своя списък със 100-те компании, които създават най-висока бизнес стойност за 2008 г. чрез иновации в технологиите. На сайта на списанието можете да видите подробна информация за мотивите една компания да бъде включена в този списък.
Можете да разберете повече за компанията и нейния водещ проект, като цъкнете върху тяхното име. Заглавията на колоните също могат да се цъкат, за да се промени начина на сортиране.
Интересно е да се отбележи, че гиганти като IBM и HP сякаш винаги имат запазено място в подобни класации, докато Microsoft, например, отсъстват.
Прави впечатление присъствието на доста фирми, описани в книгите на Джим Колинс “Създадени вечни” и “Пътят към величието“, които силно ви препоръчвам. В тях авторът е успял да отгатне точните съставки, необходими за създаването на една велика фирма.
Разгледайте класацията и споделете вашето мнение тук. Ще бъде интересно за всички.
Гласувайте за тази статия в Svejo.net:
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се за съдържанието му чрез RSS feed или по имейл.
Категории: Връзки, Новини | Няма коментари
Още за проектните спонсори
Elizabeth Harrin има чудесна серия за проектните спонсори и след въвеждащия пост за ролята на спонсора, бих искал да ви цитирам още един от нейните постове по тази тема.
Проектният спонсор е основна фигура в проекта - този, който представя екипа пред борда на директорите, този, който отстоява интересите на проекта, който взема стратегически решения и най-важното - силно желае това, което проектът се стреми да постигне. Всеки проект има нужда от спонсор.
Ето и още няколко характеристики на проектния спонсор. Той е човек, който:
- е измисли идеята и наистина иска да я реализира;
- контролира парите;
- иска да получи крайния продукт;
- може да представя екипа на високо ниво и да потушава политическите битки преди да засегнат екипа;
- “притежава” ресурсите;
- е ефективен резонатор и ментор на екипа.
Последното, подчертава Елизабет, е особено важно. Спонсорът трябва да бъде винаги достъпен, особено за проектния мениджър, за да може да изслуша и разбере неговите проблеми и да може да помогне - с действие или със съвет.
Наличието на добър спонсор на проекта, отговарящ на всички изброени дотук качества, може и да не е сигурна гаранция за успех, но определено повишава значитлно шансовете на проекта. Обратно, липсата на такава ключова фигура, почти сигурно обрича проекта на провал.
Гласувайте за тази статия в Svejo.net:
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се за съдържанието му чрез RSS feed или по имейл.
Категории: Управление на проекти | 1 коментар
Бизнес изискванията са пълни глупости!
Това твърди Steve Yegge в своя провокативен пост, озаглавен по този начин - Business Requirements are Bullshit! Статията е дълга и изпъстрена с много примери от различни сфери на бизнеса, но основната идея е проста и страшна:
Не можете да извлечете бизнес изискванията за един продукт. Каквито и методи да ползвате, на края клиентът пак няма да е доволен.
Това си звучи направо страшно. За какво се пънат толкова много специалисти да правят софтуер, щом така или иначе клиентът няма да го хареса? Разбира се, тук целта на автора е просто да ни провокира и да размърдаме мозъците си. Затова той предлага и своето решение на този проблем, което, естествено, отново е доста радикално:
За да направиш успешен продукт, трябва да го правиш за себе си. Тогава няма да има нужда да “събираш изисквания”, защото изискванията са в главата ти. Когато правиш нещо за себе си, ти го правиш с желание, разбиране и страст и то върши перфектна работа. Който има специални изисквания, да си направи продукта сам!
Статията е забавна и сериозна едновременно. Едва ли всички хора могат да станат програмисти и да си програмират сами всички бизнес приложения, но пък проблемите, които авторът поставя, са си сериозни и до ден днешен никой не е успял да измисли решение, което да ги отстрани напълно. Всичко, до което е достигнала професията на софтуерния разработчик, е само едно малко приближение до идеалния вариант и търсенето все още продължава.
Прочетете статията тук. След нея има и огромно количество коментари, някои от които също заслужават по-голямо внимание.
Гласувайте за тази статия в Svejo.net:
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се за съдържанието му чрез RSS feed или по имейл.
Категории: Бизнес анализ, Разработка на софтуер | 2 коментара
Спонсор на проекта - кой е той и каква е неговата роля?
Спонсорът на проекта е по дефиниция човек, който има голям интерес от успеха на проекта и подпомага неговата работа. На практика това е мениджър от високо ниво, който може да взема стратегически решения, които не са в прерогативите на проектния мениджър.
За какво ни е спонсор на проекта?
Ползата от спонсора е в това, че той може да реши проблеми с недостига на ресурси- хора или средства - или да участва в преговори на високо ниво с клиента, когато настъпят сериозни разногласия. Докато ролята на проектния мениджър е основно да планира и разпределя работата и да следи за движението по план, то спонсорът е стратегическия “закрилник” и ментор на проекта. Той се намесва там, където правомощията на проджект мениджъра свършват.
Мантри на мотивацията или съставките на един успешен проект
Статистиката показва, че все още провалените или проблемните проекти са много повече от успешните. Особено пък в областта на софтуерното производство. Умните глави все още мислят над въпроса: “Къде сбъркахме?” Аз, обаче попаднах на нещо много ценно - точните съставки, които могат да доведат един проект до успех.
Това са твърдения, които всеки член на екипа трабва да може да каже за себе си с чиста съвест - нещо като мантра - думи, в които ако вярваш и си ги припомняш често, несъмнено ще повдигнат бойния ти дух и ще те мотивират за ефективна работа.
Въпросът е: можете ли да ги кажете без да излъжете? Можете ли да организирате процеса си така, че хората да ги изрекат искрено? Това е трудната работа и всъщност това е истинското задължение на един проектен лидер.
Ето ги и тях - мантрите на мотивацията:
Категории: Курсове и семинари, Лидерство, Работа в екип | 1 коментар
-
RSS абонамент
Препоръчвам ви
Връзки
Авторски права
-
Admin
