Професия ли е Project Management?
От дълго време осъзнавам, че уменията и способностите за управление на проекти, не трябва да се изграждат само в определени хора, наречени проджект мениджъри, а във всеки, който изпълнява някакви управленски функции. Наскоро попаднах на един пост, в който се цитират авторитетни специалисти (без линкове, за съжаление), които категорично потвърждават моята позиция.
“Project management не е професия, а бизнес дисциплина“, казва David Curling. “Той е част от дисциплината на общия мениджмънт, който едва ли ще бъде признат за професия.”
David Pells го казва още по-добре:
Наскоро стигнах до заключението, че проджект мениджмънта трябва да бъде разбиран и представян като “основно качество на всеки мениджър във всяка организация“. Посоката, която нашата “професия” трябва да поеме, е да покаже че ползите от професионалното управление на проекти са толкова значителни и широко разпространени, че то трябва да бъде прегърнато от всеки професионалист, от всеки мениджър и от всяка организация. Управлението чрез проекти вече не е въпрос на избор, а фактическа реалност в един конкурентен свят. Enterprise PM и Portfolio PM са просто стъпки напред към едно по-зряло и по-печелившо предприятие. За да оцелее и да просперира, всеки мениджър трябва да знае как да организира, да планира и да изпълнява проекти.
Просто няма какво да се добави.
По този повод, имам удоволствието да обявя повторното издание на курса Основи на управлението на софтуерни проекти, организиран от моята фирма RammSoft, на който аз съм лектор. Той ще се проведе на 19.06.2008 г. в София. Курсът е полезен не само за хора, носещи титлата “Project Manager”, а и за всички, които са ангажирани в процеса на изпълнението на един софтуерен проект или изпълняват управленски задачи в своята работа. Повече информация за курса можете да намерите в официалната обява на сайта на RammSoft.
Очаквам ви!
Гласувайте за тази статия в Svejo.net:
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл.
Категории: Курсове и семинари, Професията на проджект мениджъра | 2 коментара
Първи гост-автор в PM Stories - Петър Лефтеров
Миналата седмица на страниците на PM Stories се появи първата статия, написана от гост-автор - Трябва ли анализът да е “тромав”? от Петър Лефтеров.
Петър е бивш програмист и състезател по информатика, завършил Факултета по Математика и Информатика към СУ „Св. Климент Охридски”. По-рано се е занимавал с разработка на приложения с ASP .NET и Delfi. От две години се е фокусирал основно върху бизнес анализ на софтуерни проекти. Сегашната му позиция е на старши бизнес аналитик в IT отдела на Българска Телекомуникационна Компания.
През свободното си време води лекции по бизнес анализ и софтуерни технологии в мениджмънта в Стопански Факултет на СУ. Активен участник е в Движение Български Великден, на което е и действащ председател.
С първата статия на Петър слагаме началото на една нова фаза в развитието на блога, с което вярвам, че той ще стане по-богат на информация и по-интересен за читателите, интересуващи се от проблемите на софтуерното производство и управлението на проекти.
Приканвам всеки, който има интереси в тази област и който смята, че има какво да сподели със своите колеги, да заповяда на страниците на PM Stories и да стане един от нашите автори. Така заедно ще създадем един център, който да фокусира интересите на професионалната общност в България. Заповядайте! Свържете се с мен чрез страницата за контакти и аз ще ви отговоря незабавно!
Гласувайте за тази статия в Svejo.net:
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл.
Трябва ли анализът да е “тромав”?
Търсейки интересна тема за бизнес анализ попаднах на дискусия по тема, която често съм обсъждал и аз с колеги. В своята статия Do we need Agile Business Analysys? Крейг Браун задава въпроса дали Agile не прави бизнес аналитика като позиция излишен, което провокира добър отговор от професионалист съчетаващ двете.
Според мен отговорът зависи от това как възприемаме бизнес аналитика като задължения и позиция. И с каква цел организацията е намерила такава позиция за нужна.
Много организации и ИТ фирми приемат бизнес аналитика като позиция, която придава тежест. Независимо дали си ИТ фирма бореща се за проекти или ИТ мениджър, желаещ да покаже професионализъм, винаги е от полза да имаш хубав, подреден бизнес анализ, завършващ с красив, голям документ с много диаграми, носещ гръмкото название Business Requirements Specification. Това показва че си сериозен. В тази ситуация бизнес анализа се налага да е бюрократичен, бавен и негъвкав, по простата причина, че той е създаден с тази мисъл и с тази цел.
Не мога да отрека, че за много колеги тази идея е привлекателна и дори признавам, че в много случаи именно бизнес аналитиците се явяват основен адвокат на бюрокрацията. Това обаче е черта на някои организации и хора, прилагащи бизнес анализ – не на самата дисциплина.
Лидер, мениджър или наблюдател?
Наскоро попаднах на една интересна категоризация на хората, заемащи позицията Project manager. Авторът ги дели на три архетипа, които имат следните характеристики:
- Лидер. Има дълбоки технологични познания, както и опит в бизнес областта, която се автоматизира. Може да пише код ако се наложи. Активно участва в код ревюта и обсъжда технически проблеми с екипа.
- Мениджър. Има технически или бизнес произход, но е минал и специализирано обучение в управление на проекти. Познава добре механизмите и средствата на управление на проекти. Не се занимава с технически подробности, но участва в обсъждането на детайли по функционалността.
- Наблюдател. Високо квалифициран и сертифициран проджект мениджър, който е вещ в процедурите и правилата, но въобще не се занимава с производствения процес. Следи изпълнението на плана, но не участва нитов технически, нито във функционални дискусии.
След като е дефинирал така трите типа мениджъри, авторът естествено задава въпроса “Кой е най-подходящият за управление на софтуерни проекти?” и без много замисляне отговаря: лидерът.
Разбира се, има и аргументи в полза на този избор. Един от тях е, че когато проектът започне да изостава от плана (а това се случва на практика с всеки проект), наистина най-добрият метод за връщане в релси е да се преразгледа обхвата на проекта, т.е. функционалността, заложена в софтуерния продукт и да се премахне всичко, което не е жизнено необходимо.
Категории: Професията на проджект мениджъра | Няма коментари
Най-добрият project management процес
Glen Alleman от блога Herding Cats ни дава храна за размисъл, дефинирайки критерии, по които да изберем процеса и методологията, с които да управляваме своите проекти. Независимо дали ползвате най-строгите методи на Министерството на отбраната или управлявате проекта си “гледайки на боб”, казва Глен, вашата методология трябва да може да даде смислен отговор на следните два въпроса:
- Колко дълго ще чакате, преди да разберете, че сте закъснели, надхвърлили бюджета или извън техническата спецификация?
- Какво ще направите, за да се върнете в състояние, приемливо за всички участници?
Ако процесът, който следвате, или врачуването с карти или боб не могат да дадат смислен и измерим отговор на тези въпроси, значи в действителност въобще не управлявате проекта.
Доста радикално, но пък изключително практично твърдение, с което не мога да не се съглася. А вие как мислите?
Гласувайте за тази статия в Svejo.net:
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл.
Категории: Управление на проекти | 1 коментар
Предимства и недостатъци на малкия екип
Във връзка с темата за размера на екипа, попаднах на един интересен пост в PM Hut, в който авторът под формата на интервю със себе си (малко шизофренично, но все пак интересно) представя своите съображения относно предимствата и недостатъците на един малък екип пред по-голям такъв.
Преди всичко, много е важно да се разбере, че малкият екип не е просто количествено различен от големия, той е и качествено различен. Авторът прави едно доста добро сравнение на малкия екип с джаз бенд, а на големия - със симфоничен оркестър. Джаз бендът не е малък оркестър, който иска да порасне - той просто е друга музикална структура.
Ако се опитате да дирижирате джаз квартет като симфоничен оркестър, ще получите лош джаз. Оставете филхармонията да импровизира като джем сешън и ще получите хаос.
Не, че малкият бенд не свири по правилата - просто ги интерпретира по различен начин. Изводът в проектната организация е аналогичен - и малкият, и големият екип трябва да се управляват по някакъв процес, но те са различни в двата случая. Както се казва по американски - one size doesn’t fit all.
Категории: Работа в екип, Разработка на софтуер, Управление на проекти | Няма коментари
Ако “Властелинът на пръстените” беше проект…
… кой щеше да е проджект мениджъра?
Този въпрос разглежда Diane Ellis в блога PM Hut и той звучи съвсем разумно. Приключението, което предприемат главните герои има всички характеристики на един проект:
- Имат ясна цел и задачи
- Имат екип от хора (и не само), които имат ясно изразени (макар и неизказани) роли
- Всички членове на екипа трябва да работят заедно, за да постигнат набелязаната цел
- Има ясно определен краен срок, в рамките на който целта трябва да бъде постигната
ОК, имаме проект, но кой е мениджърът? Преди да решим кой е шефа на проекта, авторката ни припомня какви са неговите основните задължения:
- Носи изключителната отговорност за успеха или провала на проекта
- Изготвя план и бюджет на проекта
- Осигурява ефективни ресурси за проекта
- Следи за изпълнението на плана и бюджета
- Управлява качеството на работата, рисковете и проблемите
- Управлява ежедневните задачи
- Комуникира статуса на проекта с основните заинтересовани лица (stakeholders)
Категории: Работа в екип, Управление на проекти, Хумор | 3 коментара
Най-добрия начин да мотивирате своя екип
Bas de Baar постави този въпрос в своя блог Project Shrink и помоли своите читатели да предложат своите отговори. Аз винаги съм смятал, че мотивираният екип е най-важният фактор за успеха на един проект, но никога не съм имал “готова рецепта” за това как да мотивираш един екип. Всъщност знам много неща, които могат да подкопаят мотивацията на екипа и доверието във вас, много класически грешки, които можете да направите, но наистина нямах отговор на този въпрос досега и се наложи доста да помисля над него преди пред мен да изплува отговор, който да мога да споделя и с вас.
Дайте възможност на хората от вашия екип да бъдат креативни!
Категории: Лидерство, Работа в екип | 5 коментара
Числата на Дънбар и размера на софтуерния екип
R. I. M. Dunbar е бил антрополог в University College of London и на базата на изследвания на хора и примати е стигнал до извода, че максималния брой контакти, които човек може да поддържа активно в съзнанието си, е приблизително 150. Т.е. всяка една група може да бъде витална и да оцелее, ако има по-малко от 150 члена. Историята показва, че по-големите групи започват да се делят на по-малки щом броят на членовете им започне да надвишава това число. Оттук числото 150 започва да се нарича “числото на Дънбар”.
Christopher Allen разказва много обширно в своя блог за теорията на Дънбар и всички последвали изследвания след това. Той отива доста по-далеч в своите разсъждения, разглеждайки ефективността на софтуерните екипи и се опитва и там да намери някаква закономерност между броя на техните членове и ефективността на комуникацията и производителността.
Моят опит показва, че най-малкият размер, при който групата е жизнена, е някъде между 5 и 9 човека.
Категории: Анкети, Работа в екип, Разработка на софтуер | 7 коментара
Как не се прави презентация
В света на информационните технологии се провеждат много конференции, семинари и срещи (както и в другите области от живота, разбира се), в които технически специалисти споделят своите знания и опит. За съжаление, изкуството на презентацията често се подценява и се получават сериозни издънки или просто ужасно скучни лекции.
Ето един пример от една конференция, където презентациите на няколко представители на Microsoft са заснети в едно филмче:
Гласувайте за тази статия в Svejo.net:
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл.
Категории: Курсове и семинари | Няма коментари
-
RSS абонамент
Препоръчвам ви
Връзки
Авторски права
-
Admin
