PM Stories » Анкети

Проучване на в. InfoWeek за пазара на труда в ИТ сферата

Майк Рам — Tue, 16 Mar 2010 16:15:35 +0000

Вестник InfoWeek са предприели една много хубава идея – да направят проучване сред българските ИТ компании на тема “Пазарът на труда”. Въпросите са насочени към мениджърите в българските фирми и се отнасят предимно до политиките, които фирмите прилагат към задържането на настоящите си служители, набирането на нови, провеждането на обучения и механизмите на възнаграждение по време на криза.

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

Колегите от InfoWeek, а и аз, ви призоваваме да дадете своето мнение и да отговорите на въпросите от анкетата – те не са много, така че няма да ви отнеме много време. Ако не сте мениджъри – препратете я на вашите шефове.

Анкетата ще е активна още 2 седмици, след което резултатите ще се появят в хартиеното и в онлайн изданието на вестника. Нека да видим каква е ситуацията на трудовия пазар в ИТ сектора днес.

Благодаря ви за участието!

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

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

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

Добрите практики на софтуерното производство – анкета

Майк Рам — Thu, 09 Jul 2009 05:10:59 +0000

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

Аз се включих в анкетата и наистина времето за попълването е между 30 и 60 минути, но вие не сте длъжни да попълвате всички категории, особено пък ако не се занимавате с всички описани дейности. Можете да дадете мнение само за онези дейности, с които активно се занимавате и с които имате най-много опит. Тогава би трябвало да се справите за 20-ина минути.

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

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

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

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

Кой решава дали да стартира един проект?

Майк Рам — Thu, 20 Nov 2008 10:44:10 +0000

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

Дали това е главният изпълнителен директор (The Big Boss) или друг отдел във фирмата (маркетинг, финанси, счетоводство), дали проектният мениджър и екипът, който ще изпълнява поетия проект, имат право на глас във вземането на това решение или то се взема от неведоми външни сили?

Гласувайте в новата анкета на блога (горе вдясно) и подкрепете вашия глас с коментар. Имате право да изберете не повече от 3 опции.

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

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

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

Майк Рам — Tue, 04 Nov 2008 17:49:08 +0000

Тази анкета се застоя малко по-дълго, но това беше преднамерено. Реших, че трябва да дам достатъчно време, за да могат повече хора да дадат своето мнение и така анкетата да придобие малко по-голяма тежест. Хубавото е, че този подход даде резултат – имаме цели 212 участника! Лошото е, че резултатите не ми харесват и според мен не показват мениджърско мислене.

Зададеният въпрос беше: “Ако имате 1000 лева, които трябва да използвате, за да мотивирате своя екип, какво бихте направили с тях?” А ето и вашите отговори:

Ще им ги раздам в брой като бонус (29%, 61 гласа)
Едно голямо ядене и напиване за всички (22%, 46 гласа)
Професионални книги за всички (17%, 35 гласа)
Професионален курс за някои (16%, 34 гласа)
Друго (7%, 14 гласа)
Ще ги похарча за себе си (4%, 8 гласа)
500 бири за всички (3%, 6 гласа)
Нови монитори за някои (2%, 4 гласа)
Нови столове за някои (2%, 4 гласа)

Топ-отговорът беше провокативен. Раздаването на пари е лош мотивационен подход, а когато сумата е малка, не носи почти никакъв резултат. Фактът, че този отговор е избран от най-много хора, говори, че гледната точка на гласувалите е била не тази на мениджъра на проекта, а на изпълнител в този проект. Помислете: ако екипът е от 10-ина човека, това означава всеки един да получи средно по 100 лева. На фона на сегашното равнище на заплатите на софтуерните разработчици от около 2000 лева, какъв мотивационен ефект биха имали тези 100 лева? Колко точно ще се повиши производителността на един програмист, ако му връчите бонус в размер на 5% от месечната му заплата? Не мисля, че някой ще се напъне особено много да работи в резултат на това възнаграждение.

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

Анкетата всъщност постави няколко дилеми:

Дали всички да бъдат наградени или само някои?
Дали проджект мениджъра може да реши кое е най-доброто средство за мотивация?

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

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

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

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

Дано да греша. Очаквам вашите коментари и тълкувания на резултатите.

Ето и една оферта за професионално обучение: На 12.11.2008 г. ще водя курса “Управление на риска в софтуерни проекти“, организиран от фирма RammSoft. Там не само ще се запознаете с теорията на риск мениджмънта, но и ще имате възможността веднага да приложите придобитите знания на практика.

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

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

Проучване на “soft skills” на проектните мениджъри

Майк Рам — Tue, 28 Oct 2008 04:15:47 +0000

Кои са най-важните “soft skills” за един проджект мениджър?
Кои от тях успяваме да изградим у себе си с кои се затрудняваме?
Дали жените са по-добри от мъжете по отношение на уменията за общуване и взаимодействие сдругите хора?

Това са въпросите, на които търси отговори Zuzana Botkova в интернет проучването, което е организирала. Самият израз “soft skills” много трудно се превежда на български (може би защото такива качества по принцип липсват в нашите мениджъри?). Това са уменията за общуване и въздействие върху хората (за разлика от “твърдите” (“hard”) умения, които са свързани с управление на процесите).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Usability пример: забранени (disabled) менюта и бутони

Майк Рам — Mon, 07 Jul 2008 10:41:22 +0000

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

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

Аргументът на Джоел е прост – като види едно забранено меню, потребителят има да се чуди защо е така и няма да може да си върши работата добре. Това е напълно валиден аргумент, що се отнася до хора, които още не познават системата добре и имат нужда от помощ. Но от друга страна, опитният потребител би се почувствал досадно ако избере меню или бутон и му се каже: “Сори, но това в момента не работи.”

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

От друга страна, опитния потребител предпочита всички ненужни неща да изчезнат от погледа му, за не го разсейват. Избирането на бутон, който не работи и четенето на обяснителното съобщение за него е губене на ценно време. Един забранен (disabled) бутон е достатъчно красноречив начин да разбере, че тази функция не работи и за него не е трудно (понеже е опитен) да се сети защо.

Следователно големият въпрос е: как да направим нашия софтуер така, че с него да могат да работят и опитни, и неопитни потребители? Отговорът, разбира се, никак не е прост. Един от механизмите, които смятам, че са полезни в това отношение, е използването на системни параметри за настройването на тези опции.

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

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

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

Бих искал да знам и вашето мнение и затова съм отворил нова анкета, в която въпросът е: да забраняваме или да не забраняваме? Споделете вашите предпочитания, гласувайки.

Естествено, осъзнавам, че качественият отговор не е толкова прост, така че очаквам вашите мнения и като коментари под този пост.

Гласувайте за тази статия в 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:

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

Кой тества вашия продукт? Резултати от анкетата

Майк Рам — Wed, 02 Apr 2008 13:32:37 +0000

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

Въпросът беше: Кой тества вашия продукт? Общо гласувалите в анкетата са 66 човека, като разпределението на отговорите е следното:

Тестери – членове на проектния екип (36%, 24 гласа)
Отдел по качеството във фирмата (23%, 15 гласа)
Програмистите (23%, 15 гласа)
Клиентът (18%, 12 гласа)

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

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

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

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

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

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

Как оценяте бюджета на един проект? Резултати от анкетата

Майк Рам — Tue, 18 Dec 2007 09:35:00 +0000

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

Въпросът беше: Как оценяте бюджета на един проект?
В анкетата гласуваха общо 65 човека. Ето и разпределението на гласовете:

На око – 28 гласа, 43%. Както предвиждаха моите лични наблюдения, това се оказа най-честият отговор. Ако приемем, че повечето участници са гласували сериозно, а не са си правили майтап, това е доста тревожен симптом. За мен, този отговор означава, че голяма част от проджект мениджърите не са запознати с основните задачи и методи на професията (главно поради случайно попадане в нея) и поради това работят основно на принципа на пробите и грешките, където грешките май са повече. На тези колеги им препоръчвам да четат по-активно материалите в този блог и да участват в дискусиите. Убеден съм, че ще им бъде много полезно.
По учебника – правим WBS, оценяме всяка една задача и отчитаме и рисковите фактори – 16 гласа, 25%. Очевидно това е добрата новина – има проекти, където нещата се правят на базата на утвърдени теории и практики за управление на проекти. За съжаление, такива примери все още са малко. Много ще се радвам, ако някой от подалите такъв глас сподели на страниците на този блог своя опит и примери от неговата успешна работа.
Не знам. Шефът се занимава с парите – 11 гласа, 17%. Това е най-неприятната ситуация за един проджект мениджър – поставят те в ситуация, в която някой друг е определил параметрите без да се допита до тебе, а ти си човекът, който трябва да избута проекта до успешен край. Добре е поне, че гласувалите по този начин са относително по-малко, но аз мисля, че този подход е много погрешен и истински прогрес ще имаме само тогава, когато такива проекти изчезнат напълно.
По друг начин – 10 гласа, 15%. За съжаление, участниците в анкетата, които са избрали този вариант, не са уточнили какъв точно е техният подход, с което само ни карат да гадаем. Но никога не е късно да се поправи този пропуск. Могат да споделят техния начин на оценка на бюджета в този или други постове като коментар. Всички са добре дошли!

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

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