Класическите грешки: Демотивация на екипа
Когато говоря на моите семинари за управление на проекти за факторите, които предричат успеха или провала на един проект, неминуемо стигаме до класическите грешки, дефинирани от Steve McConnell и публикувани в неговата книга “Rapid Development” (1996). Тя и до днес е “библия” в областта на проектното управление в софтуерния бизнес и постулира, че ако искаме един проект да бъде успешен, преди всичко трябва да престанем да правим класически грешки – онези действия, които са доказали в практиката на много проекти, че със сигурност водят до провал. Един от тези важни фактори е демотивацията на екипа.
Започвам с демотивацията, защото наскоро попаднах на една статия от Sean Kenney, който също я дефинира като един от двата големи фактора, които могат да “потопят” един проект. Това, което искам да ви разкажа, е една история от моя опит (нали затова този блог се казва PM Stories 
), в която демотивацията изигра съществена роля за провала на проекта.
Това беше първият ми проект в една от най-авторитетните софтуерни фирми в България. Бях толкова щастлив, че са ме одобрили да работя за тях, че бях готов да работя денонощно, за да докажа своите професионални качества. Аз нямах особени постижения преди това – бях просто редови програмист в малка фирма и нямаше с какво да се похваля. Но сега бях попаднал на място, където хем имаше много неща, които да науча, хем можех да покажа пред шефовете и клиентите на какво съм способен.
Възложителят беше сериозна финансова институция с разрастващ се бизнес и имаха остра нужда да заменят екселските файлове, които ползваха за отчитане на финансовото състояние на своите клиенти, със специализирана информационна система, която можеше да им даде точна и навременна информация за това. За съжаление, човекът, който отговаряше от тяхна страна за изпълнението на проекта, беше недостатъчно компетентен и още в самото начало разбрахме, че само изясняването на изискванията ще ни отнеме ужасно много време.
Категории: Класически грешки | 6 коментара
Банка ДСК – софтуерно решение за управление на опашка от клиенти
Днес в блога си The Man on the Silver Mountain публикувах една статия, озаглавена Банка ДСК – реален социализъм в действие. В тази история разказвам за два феномена, с които се сблъсках там. От една страна е нежеланието или неспособността на банката да се справи с огромните опашки от клиенти и превръщането им в нормално ежедневие, и от друга е софтуерното решение, с което банката иска да вкара опашката в някакъв ред, и което се оказва поредната софтуерна недомислица.
Трудно някой, който се е занимавал с разработка на софтуер, може да се сети за по-проста задача от това да раздаваш последователни номера, но явно екипът, разработил системата на Банка ДСК, е успял дори от тази проста задача да сътвори нещо, което не само не помага, но и още повече обърква и без това ошашавения клиент.
Тази история е поредния пример за софтуерно изпълнение, което напълно е игнорирало крайния потребител – нито е съобразено с неговите изисквания, нито пък с възможностите му и спецификата на неговото поведение. (Не бива да забравяме, че 90% от клиентите на банката са пенсионери, които не само нямат компютърна грамотност, но имат затруднения с четенето и придвижването.)
Прочетете статията. Сигурен съм, че ще ви накара да се замислите.
Категории: Класически грешки, Разработка на софтуер | Няма коментари
Класически грешки – 2008
Онзи ден получих писмо от Steve McConnell с линк към резултатите от изследването, което той проведе миналото лято върху Новите класически грешки на софтуерното производство. Аз участвах в това проучване и писах за него в Класическите грешки. Стив публикува своя списък от класически грешки в книгата си Rapid Development от 1996, но поради много динамичното развитие на софтуерния бизнес, той реши, че списъкът се нуждае от актуализация. В него бяха предложени няколко нови грешки, а всички останали бяха подложени на верификация.
Сега той е публикувал резултатите от това проучване в брошура от 39 страници заедно с презентация на PowerPoint. Проучването включваше много въпроси, целящи да се направи един по-задълбочен анализ на същността и причините за възникването на най-големите грешки, които правим в областта на софтуерното производство. Списъкът от 2008 година ги подрежда според честотата на тяхното срещане и според пораженията, които могат да нанесат на един проект. Събрани заедно, тези критерии ни дават списъка на най-разрушителните класически грешки в нашия бизнес. Няма да ви издам коя е най-фаталната грешка, която правим, за да не ви разваля удоволствието да си го прочетете сами – просто кликнете на този линк (може да ви поиска регистрация, която е безплатна) и ще го узнаете.
Моят професионален опит ми показва, че повечето софтуерни компании все още са много далече от стандартите, които Steve McConnell поставя за Rapid Development и първата и най-важна стъпка, която трябва да се направи, е да се научим да избягваме тези “класически грешки”. Допускането на подобни грешки е гаранция, че няма да можете да завършите своя проект навреме. Според мене, всеки добър проджект мениджър трябва да има този списък пред себе си, за да го следи периодично и да си задава въпросите: Продължаваме ли да допускаме класически грешки? и Как можем да ги избегнем?
Това, разбира се, никак не е лесно. Понякога се налага да правиш неща, които биха били класифицирани като класически грешки, принуден от обстоятелствата или от по-висшия мениджмънт. Но знаейки, че това, което правиш, може да ти донесе големи неприятности, ще те накара да внимаваш повече и да следиш по-внимателно за рисковете, които заплашват да провалят твоя проект.
Документът с новите класически грешки е безценен източник на информация. Прочетете го и се замислете дали не допускате класически грешки във вашите проекти.
Гласувайте за тази статия в Svejo.net:
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл
Категории: Класически грешки | 2 коментара
10-те най-важни грешки в разработката на софтуер, според InfoWorld Tech Watch
Наскоро, в блога InfoWorld Tech Watch открих един пост, озаглавен 10 mistakes to avoid in software development (“10 грешки, които да избягваме в софтуерното производство”), където цитират резултатите от едно проучване на Forrester Research, публикувани наскоро. Въпреки, че принципно съм съгласен с това, че списъкът представя едни от най-важните грешки, които могат да доведат всеки проект до неуспех, ще навляза в малко по-дълбоки детайли и ще коментирам всяка една от тях.
Ето го и самият списък с 10-те грешки, които трябва да избягваме при разработката на софтуер (Както и в други постове, не съм превел оригиналния текст, за да не бъда обвиняван в идиотски превод. Вярвам, че няма да се затрудните с това.):
Категории: Класически грешки, Разработка на софтуер, Управление на проекти | Няма коментари
Класически грешки – Случаят "ГигаЛийз", Част 2
Историята продължава с изграждането на екипа и първите внедрявания при клиента, когато някои неприятни истини излизат наяве. Още много грешки в един относително малък проект.
Четете втората част на случая “ГигаЛийз” в англоезичната версия на блога, а коментари може да пишете и тук. Ще съм безкрайно щастлив, ако и вие имате подобни истории, които да споделите с мене и моите читатели.
Категории: Класически грешки | Няма коментари
Класически грешки – Случаят "ГигаЛийз", Част 1
След дълго умуване и канене започнах серията за класическите грешки с един пример от моята практика – случаят “ГигаЛийз”. Реших, че споделянето на реални примери от живота е най-добрия начин да видим и оценим грешките, които са допуснали различните участници в историята и да преценим как трябва да постъпваме ние в подобни ситуации, за да не ги повтаряме. Първата част на тази история можете да прочетете тук (на английски език).
Ще се радвам да споделите и вашия опит от подобни проекти и допуснати грешки, като коментирате тук, в имейл или във вашите блогове, като не забравите да пуснете линк насам.
Класическите грешки
Снощи изнесох първата си лекция на семинар на БАРС и съдейки по положителните отзиви, смятам, че ако не моето лично представяне, то поне темата е била интересна за участниците в семинара. Темата за класическите грешки отново излезе на дневен ред, след като авторът Steve McConnell реши да актуализира списъка и да предложи анкета за това доколко често правим класически грешки и колко са сериозни пораженията в последствие. Горещо ви препоръчвам да се включите в изследването и да попълнете анкетата – това ще помогне на целокупното програмистко братство да си изясним кои са най-важните грешки, които правим в работата си и да се научим да ги избягваме.
По този повод, и имайки предвид интереса, който предизвика темата за класическите грешки, реших да започна една серия от постове в англоезичната версия на този блог, в които да разкажа за моя списък от класически грешки – такива, които аз съм видял или направил в професионалната си кариера и които считам за важни и опасни.
Категории: Класически грешки, Курсове и семинари | 2 коментара
Семинар на БАРС – 19.06.2007
Щастлив съм да обявя, че на 19.06.2007 г. ще се проведе семинар на Българската асоциация на разработчиците на софтуер (БАРС), в който съм поканен да участвам и аз като лектор и ще изнеса презентация на тема Rapid Development – Part 1. Лекцията представя основните идеи и принципи на концепцията за Rapid development, представена от Steve McConnell в едноименната му книга, издадена още през 1996 г., но валидна в пълна сила и до днес и неслучайно считана за библия в света на софтуерното производство и управлението на софтуерни проекти.
Семинарът ще се проведе на 19.06.2007 г. в София, в клуб “Sugar” на ул. “Граф Игнатиев” 1. Заповядайте!
По-подробна информация за събитието можете да прочетете от официалната обява на сайта на БАРС.
Книгата “Rapid Development” можете да си купите от: Amazon.
Категории: Класически грешки, Курсове и семинари | 2 коментара
-
RSS абонамент
Препоръчвам ви
Връзки
Авторски права
-
Admin
