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

Опитните проектни мениджъри знаят, че:

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

Аз заставам зад тези твърдения категорично. Вие какво мислите?

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

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

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

• Мантри на мотивацията или съставките на един успешен проект
• Анкета за мотивацията на IT специалисти
• Почти перфектно
• Хиляда лева за мотивация. Резултати от анкетата
• Последно повикване за курса по основи на проектното управление

Ето един пример от една конференция, където презентациите на няколко представители на Microsoft са заснети в едно филмче:

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

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

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

• Почти перфектно
• Какво знаят опитните проджект мениджъри?
• Колко служители на Microsoft са необходими, за да се смени една крушка?
• 10-те най-важни грешки в разработката на софтуер, според InfoWorld Tech Watch

Ето го и самият списък с 10-те грешки, които трябва да избягваме при разработката на софтуер (Както и в други постове, не съм превел оригиналния текст, за да не бъда обвиняван в идиотски превод. Вярвам, че няма да се затрудните с това.):

1. Never committing to project success. Това е твърде очевидно и тривиално. Естествено е, че ако не си отдаден на успеха, няма да го постугнеш. Не виждам никаква мъдрост тук.
2. Freezing the schedule and budget before a project is sufficiently understood. За съжаление, това се случва винаги и навсякъде, особено у нас. Според мене, това е основният проблем на управлението на софтуерни проекти: какво да направим, когато ни питат за оценка на времето и цената, или пък ни карат да подпишем договор за това, при положение, че въобще не сме наясно какво точно трябва да се прави в даден проект?
3. Overscoping a solution. Да, това е грешка, но аз мисля, че тя се случва все по-рядко в наши дни.
4. Circumventing the application development organization altogether. Тук може би ще трябва да сложа някакъв превод, за да стане ясен и коментара ми. Доколкото знанията ми по английски се простират, това трябва да се преведе така: “Заобикаляне на организацията по разработка на приложения”. Не мисля, че това винаги е грешка, особено ако човек е наясно какво прави. Понякога даже е наложително да се прескочат всички правила, особено ако си бил “насаден” на проект от типа “Death March”. Истинският въпрос, все пак е: Можеш ли дори и при тези обстоятелства да доведеш проекта до успех?
5. Underestimating the complexity of a problem. Обикновено това е най-важната причина за подписване на договори с ниски бюджети и съкратени срокове. За съжаление, тази грешка най-често се прави от висшия мениджмънт, най-вече поради това, че не се консултират с екипа си (или му нямат доверие). Вярвам, че всяка компания трябва да инвестира повече време преди да подпише договор или да даде някакво обещание, през който период да се проведе задълбочено проучване на нуждите и проблемите на клиента, за да се придобие по-вярна представа за сложността на задачата.
6. Being stingy with subject-matter experts, in which their participation is not sufficient. Това е резултат от предишната грешка.
7. Choosing the wrong project leadership. Or the wrong leaders. Or the wrong managers. Or the wrong customers (Can there be wrong customers?) Без превод.
8. Distrusting managers who have had tasks delegated to them. Мисля, че липсата на доверие към когото и да е в една фирма или екип, е ключова грешка.
9. Jumping into development without enough research. Отново, това се случва поради подценяване на проблема, който трябва да се реши с дадения проект.
10. Suppressing bad news, in which dialogue is insufficient. Сучайно да познавате мениджър, който обича да чува лоши новини?

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

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

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

• Какво знаят опитните проджект мениджъри?
• Как не се прави презентация