10-те най-важни грешки в разработката на софтуер, според InfoWorld Tech Watch

Наскоро, в блога InfoWorld Tech Watch открих един пост, озаглавен 10 mistakes to avoid in software development (“10 грешки, които да избягваме в софтуерното производство”), където цитират резултатите от едно проучване на Forrester Research, публикувани наскоро. Въпреки, че принципно съм съгласен с това, че списъкът представя едни от най-важните грешки, които могат да доведат всеки проект до неуспех, ще навляза в малко по-дълбоки детайли и ще коментирам всяка една от тях.

Ето го и самият списък с 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 или по имейл

Leave a Reply

Your email address will not be published. Required fields are marked *