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

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

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

• PMBOK Guide на български език
• За плановете и планирането
• Среща на Agile и Lean общостта – 18.04.2011
• Безплатна електронна книга за PRINCE2
• Да си се похваля или “който рискува – пичели”

Хората, които се занимават с управление на проекти, знаят, че PMI (Project Management Institute) е най-голямата международна организация, обединяваща професионалистите в областта на проектното управление, и че PMBOK наистина представлява “библия” за всички нас, обобщаваща всички добри практики за управление на проекти в една стройна методология. Четвъртото издание на това Ръководство, което е най-актуалното и което излиза на български език, показва по-голяма зрелост и по-добро описание и структуриране на събраните в него знания.

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

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

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

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

Единственото, което ми направи неприятно впечатление, е буквалният превод на заглавието – “Ръководство за система от знания за управление на проекти”, – което звучи много тромаво и неразбираемо, но за щастие то се появява само на корицата на книгата, а вътре в текста се използва по-простия израз “Ръководството PMBOK”. Поздравявам и издателство Класика и Стил, които са физическите издатели на тази скъпоценна книга.

Като казах “скъпоценна”, цената на Ръководството е 47 лева, което е доста изгодно на фона на цената на оригиналното издание на английски което струва 66 долара (без да броим доставката). У нас можете да си купите книгата от интернет книжарница “Нова визия” с 10% отстъпка, а най-изгодната покупка за вас би била ако се запишете за участие в семинарите по управление на проекти, които водя аз, където не само можете да разберете основните принципи на методологията на PMI, разказани на ясен и разбираем език, но и да си купите PMBOK Guide с цели 30% отстъпка! Това си е направо далавера!

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

Надявам се, че тази добра идея ще се запази и занапред и след време ще можем да видим и петото издание на Ръководството на български език и все повече колеги да се възползват от знанието, представено в него.

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

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

• Безплатна електронна книга за PRINCE2
• Управлението на проекти е организиран здрав разум
• Spooning – една пародия на Pair Programming
• За плановете и планирането
• Среща на Agile и Lean общостта – 18.04.2011

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

Как обаче оценяваме дали целта е постигната? Това става с по-малките цели, които си поставяме. На английски това се нарича objectives, а аз го нарекох стъпки към постигане на главната цел. Те трябва да отговорят на определени характеристики, описани с акронима SMART:

• Конкретни (Specific)
• Измерими (Measurable)
• Приемливи (Acceptable)
• Реалистични (Realistic)
• Ограничени във времето (Time-bounded)

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

Темата за целта на проекта и нейното разбиране като главен фактор за успеха, е важна част от семинара “Управление на проекти за простосмъртни“, който ще изнеса на 15.11.2011 г. във Варна и на 22.11.2011 г. в Русе. Вижте видеото:

Майк Рам за целите на проекта

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

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

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

• Що е проект? Дефиниция и особености – видео
• Как да ангажираме висшия мениджмънт в проекта?
• Защо водя семинари по управление на проекти?
• 10 проблема при преговорите с клиенти. Част 1 – избор на методология и избор на клиент
• Защо хората мразят процесите

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

Започвам с демотивацията, защото наскоро попаднах на една статия от Sean Kenney, който също я дефинира като един от двата големи фактора, които могат да “потопят” един проект. Това, което искам да ви разкажа, е една история от моя опит (нали затова този блог се казва PM Stories ), в която демотивацията изигра съществена роля за провала на проекта.

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

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

Аз имах някакъв опит в работа с банкови системи и прецених, че ще ни трябват 3-4 месеца за цялостен анализ на изискванията и формулиране на функционална спецификация, и още около 6 месеца разработка за един малък екип от четирима човека примерно. Каква беше моята изненада, когато разбрах, че аз ще съм единствения програмист в екипа (а бях титулован Team Leader!) и вместо очакваните 10-ина месеца за цялостно изпълнение на проекта, имах само 4! Заедно с колегата, който изпълняваше функциите на проектен мениджър и бизнес анализатор, се опитахме да обясним на големия шеф, че при тези условия нямаме никакви шансове да изпълним този проект, но отговорът му беше, че ако не се справим, значи не сме достойни за тази фирма и че той е направил грешен избор като ни е назначил.

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

Малко по-късно на всички стана ясно, че комуникацията с клиента върви бавно, поради тяхната неспособност бързо да формулират своите изисквания, и че обемът на работата наистина е голям и за да успеем въобще е нужен малко по-голям екип. Тогава в екипа бяха включени аутсайдерите. Единият колега беше назначен с връзки и въпреки напомпаните препоръки, се оказа, че на практика няма никакъв опит в програмирането и почти с нищо не може да бъде полезен. Другият пък беше доста колоритна личност, за който понятията трудова дисциплина и отговорност не съществуваха. Той идваше на работа след 13:00 часа, защото до обяд си отспивал след нощни игри на Counterstrike, а в 17:00 вече си тръгваше, защото имал среща с гадже. Кодът, който пишеше и публикуваше в общата source code база, не се компилираше и в крайна сметка той носеше повече вреда, отколкото полза на работата. Да, беше веселяк, но това никак не помагаше на нашите проблеми.

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

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

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

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

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

• Препоръчано четиво: Workflow, Scrum, честност и продуктивност
• Класически грешки – 2008
• Добрите практики на софтуерното производство – анкета
• Какво знаят опитните проджект мениджъри?
• Хиляда лева за мотивация. Резултати от анкетата

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

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

След известно размишление, стигнах до два вероятни извода – оптимистичен и песимистичен.

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

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

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

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

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

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

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

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

Надявам се, че този въпрос ще провокира интересна дискусия, а за тези, които се интересуват повече от темата, препоръчвам моя семинар Управление на проекти за простосмъртни, който ще се проведе на 19.10.2011 г. в София, а малко по-късно и в други градове на страната.

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

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

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

• Целите на проекта – видео
• Внимавайте с изискванията на клиента!

Планът е нищо! Планирането е всичко!

Съвсем наскоро пък попаднах на друг цитат, чийто автор не е упоменат, но пък звучи малко по-ясно:

Изкуството да правиш планове е толкова ценно, колкото и умението да ги променяш.

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

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

На 12.07.2011 г. ще водя семинар по управление на проекти, посветен на планирането. По този повод, освен че ви каня да участвате в него, искам да ви попитам за вашето мнение относно плановете и планирането. Какво мислите за горните цитати? Вярвате ли, че е важно да имаме план – не само в проектите, които изпълняваме, а и в живота? И доколко трябва да следваме плана, който веднъж сме създали – трябва ли да се стремим да го изпълняваме на всяка цена или можем всеки ден да го променяме?

И за да ви стимулирам към активност (след доста продължително затишие в този блог), обявявам награда: онзи коментар, който най-пълно и аргументирано отговори на поставените въпроси по мое субективно мнение, ще получи ваучър за участие в семинара “Планиране на проекти” на 12.07.2011 с 50% отстъпка от редовната такса за регистрация.

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

Ако всичко това ви изглежда интересно и полезно, заповядайте – регистрирайте се за участие до 08.07, за да се възползвате от по-ниската цена за ранно записване. Няма да съжалявате!

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

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

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

• Spooning – една пародия на Pair Programming
• PMBOK Guide на български език
• Безплатна електронна книга за PRINCE2
• Да си се похваля или “който рискува – пичели”
• Вероятност за риск

Здравейте, приятели!

Наскоро да имаше семинар на тема “Методологии за управление на проекти”, където стана дума за Lean & Agile. Затова няма да изпадам в подробности – ще отбележа само, че Lean & Agile са философии/принципи/методи/практики, които през последните години набират широка популярност по света (до някаква степен и в България) и които имат сериозно отражение върху начина на управление на проекти (софтуерни и не само).

Конкретният повод да пиша тук е една инициатива, подета от Jurgen Appelo, целяща подобряване на комуникацията и сътрудничеството между хората в Европа, интересуващи се от Agile и Lean. Подробности за инициативата има тук: http://www.noop.nl/2011/02/agile-lean-europe-energize-the-network.html

На конференцията XP 2011 в Мадрид през месец май 2011 ще се дискутират идеи и планове за Agile Lean Europe (ALE) общността (http://www.noop.nl/2011/03/ale-gathering-at-xp2011.html). Идеята е всяка страна да представи своите идеи пред останалите.

Във връзка с това Scrum Bulgaria групата организира среща на 18 Април 2011, понеделник от 19:00 часа. Сборен пункт – фоайето на Факултета по Математика и Информатика (ул. Джеймс Баучър 5; град София). Основна тема за обсъждане: визия и идеи за Agile Lean Europe (ALE) общността:

• Какво е важно за нас от България по отношение на цялата ALE общност (Европа). В частност отговор на тези въпроси.
• Как ще представим нашите идеи пред останалите? (В най-добрия случай се търси някой да се появи на XP2011 в Мадрид през май 2011).

Междувременно темата се дискутира тук: http://bit.ly/ale-xp2011-bulgaria-sb
Подробности за събитието – на сайта на scrumbulgaria групата.

Срещата е отворена за всички желаещи! Заповядайте!

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

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

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

• Spooning – една пародия на Pair Programming
• PMBOK Guide на български език
• Безплатна електронна книга за PRINCE2
• The Zen Of Scrum
• Препоръчано четиво: Agile Software Development

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

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

Документите, които са представени в публикацията са:

• Current state analysis document (Анализ на текущото състояние)
• Project vision document (Визия за проекта)
• Solution vision document (Визия за решението / продукта)
• Business requirements document (Бизнес изисквания)
• Business process design document (Дизайн на бизнес процесите)
• Use case model document (Use case модели)
• Use case specification document (Use case спецификации)
• System-wide requirements document (Системни изисквания)
• Solution glossary (Речник на решението)

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

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

Надявам се, че използвайки тези документи по начина, представен в тази статия, можем значително да подобрим резултатността на нашите проекти.

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

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

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

• Добри новини за онези, които се интересуват от бизнес анализ
• Международният институт по бизнес анализ обновява сертификационният си изпит
• Внимавайте с изискванията на клиента!
• Българската секция на Международния институт по бизнес анализ е вече факт
• Ползата от бизнес анализа

Книгата “Inside PRINCE2“ е сборник със статии, написани от Елизабет, разказващи за основните концепции на методологията, принципите на толерансите, особеностите при иницииране и приключване на проекта, както и въпроси относно сертифицирането в тази област.

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

За да се сдобиете с тази книга е необходимо да посетите този пост, да си въведете името и имейл адреса в съответните полета и след това ще получите писмо с линк за потвърждение, а след него и връзка към самата книга за сваляне. Този тип регистрация ви прави абонат на нейния бюлетин, който, ако се занимавате сериозно с управление на проекти, си заслужава да следите, но ако не ви харесва, си има връзка за отписване (unsubscribe), която си работи коректно.

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

Книгата “Inside PRINCE2″ на Елизабет Харин е чудесно начало за онези, които тепърва се запознават с тази методология. Надявам се да ви бъде полезна!

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

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

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

• PMBOK Guide на български език
• Spooning – една пародия на Pair Programming
• За плановете и планирането
• Среща на Agile и Lean общостта – 18.04.2011
• Вероятност за риск

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

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

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

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

Още по време на семинара, Марио Пешев (@mpeshev) пусна няколко положителни коментара в Twitter, които завършиха с изказването “семинарът беше много силен, радвам се особено на практическите упражнения“. По-късно той написа цяла статия в блога си, посветена на отминалия семинар, в която отново подчерта, че за него най-полезни са били практическите упражнения, защото знанията, които е получил на семинара, е могъл да ги оползотвори още на следващия ден.

Мариана Евлогиева, в типичния си хумористичен и закачлив стил също посвети един пост в блога си на семинара, в който ме поставя редом с такива титани на интелектуалната мисъл като Къци Вапцаров (“Риск печели, риск губи”) и Христо Стоичков (“Който ни рискува – ни пичели”), но ако махнем шегата настрана, ще видим, че тя е открила за себе си ползите от анализа на рисковете, който може да разкрие десетки, ако не и стотици рискове, които не само могат да се превърнат в препъни-камъни за проекта, ами и в “истински канари”, които да не можем да заобиколим. И най-важното, което Мариана споделя, е че това не бива да ни плаши и паникьосва, а да ни помогне да си изградим успешна стратегия за предотвратяване на негативния ефект на такива събития.

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

Но онова, което ме накара да разбера, че съм на прав път, онова, което ми вдъхна нови сили и енергия да продължавам по този път, беше краткия но категоричен коментар на Петър Николов в Twitter:

Най-ефективният семинар изобщо в който съм участвал досега!

Нищо повече не мога да добавя, освен:

Благодаря ви, приятели! Продължаваме напред заедно!

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

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

• Spooning – една пародия на Pair Programming
• За плановете и планирането
• Вероятност за риск
• Как се справяте с рисковете?
• 10 проблема при преговорите с клиенти. Част 1 – избор на методология и избор на клиент