Техники за събиране на изисквания
Наскоро ми попадна една статия, озаглавена 10 техники за събиране на изисквания. Tom Mochal е много авторитетен експерт в областта на проджект мениджмънта и аз много ценя неговото мнение, но някои от нещата, описани в тази статия ми изглеждат съвсем тривиални, като обсъждане с един човек, обсъждане с двама човека и обсъждане с 3-4 човека.
По-интересно за мен беше това, че той посочва някои техники, които ми се струва, че не са толкова популярни, а според мен са изключително ефективни. Затова реших да се спра на тях и ги разгледам по-детайлно.
Ходене по вода
Благодарение на Ирина Марудина открих тази мъдра мисъл, принадлежаща на Edward V. Berard и не мога да се сдържа да не я споделя с вас тук. В оригнила звучи така:
Walking on water and developing software from a specification are easy if both are frozen.
А на български така:
Ходенето по вода и разработването на софтуер по спецификация са лесни, ако и двете неща са замразени.
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл
Категории: Разработка на софтуер, Хумор | 1 коментар
Най-важните правила в делегирането
Днес в английската версия на блога PM Stories публикувах един пост, озаглавен Най-важните правила в делегирането. В него съм събрал идеи и съвети от различни специалисти, като съм фокусирал мислите си върху това, което смятам за най-важно: Защо трябва да делегираме? и Какво трябва да делегираме?
Много важно е да разберем, че делегирането на задачи е двустранен процес - ние поставяме задачата, но и този, който ще я изпълни, трябва да бъде мотивиран за това. А основната мотивация да поемаш нови отговорности, е възможността за професионално развитие и растеж. Това, което е задължение на мениджъра, е поставяйки задачи и делегирайки отговорност, постоянно да дава възможност за растеж на хората от своя екип.
Прочетете цялата статия. Вярвам, че ще ви бъде полезна.
Гласувайте за тази статия в Svejo.net:
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл
Категории: Връзки, Лидерство, Работа в екип | 1 коментар
Кой тества вашия продукт?
Процесът на тестване на продукта отдавна е утвърден в теорията на софтуерното производство и даже съществува ролята на тестера - човек който притежава специфични качества и умения (различни от тези на програмиста), и е специално обучен да провери дали това, което произвеждаме, отговаря на зададените изисквания и се държи стабилно.
В интерес на истината, до неотдавна у нас съществуваха фирми, които не практикуваха никакво тестване, т.е. оставяха откриването на грешки като изненада за клиента, и такива, които възлагаха тази работа на самите програмисти, въпреки че практиката е установила, че този, който пише даден код, не е в състояние да открие голямо количество от бъговете, защото не може да разчупи мисленето си и да погледне на продукта от друг ъгъл. Вярвам, че такива фирми вече не са останали в днешно време, а ако все още съществуват, съм убеден, че пазарът ще ги принуди да променят отношението си към качеството на продукцията си или просто ще ги смачка.
Категории: Работа в екип, Разработка на софтуер, Управление на проекти | 8 коментара
10 стъпки в кариерата на проджект мениджъра
Наскоро ми попадна един видеоклип на Ammar Mango, в който той леко хумористично разкрива кои са 10-те стъпки, които трябва да извърви един проджект мениджър в своята кариера. Филмчето можете да видите тук - то е дълго само 2 минути, а аз научих за него от блога на Craig Brown.
И така, кои са 10-те стъпки в кариерата на успешния проджект мениджър?
1. Формално обучение
Според западното мислене, преди да започнеш работа в някаква област, е редно да си учил за това. Или си посещавал лекции по управление на проекти в университета, където си следвал, или твоите работодатели са те пратили на курс по project management преди да ти възложат първия проект. На теория е така, но на практика - не съвсем. От една страна, у нас темата за управление на проекти е все още слабо застъпена в учебните програми на университетите, а от друга работодателите много-много не обичат да инвестират в обучение на своите служители. Току-виж си напуснал точно след като са те научили да управляваш сложни проекти.
2. Придобиване на PMP сертификат
Американците ценят сертификатите и обичат да си ги окичват по стените. Колкото повече сертификата имаш - толкова по-добре. PMP специално е много авторитетен, защото е взема трудно и е скъп. Оттук и допълнителното уважение - щом си дал толкова пари, значи си сериозен. У нас тепърва започна да се пробужда интереса към него, но сложната процедура и високата цена сякаш са най-големите пречки пред кандидатите. (Бележка в скоби: и аз още не съм го взел, въпреки че се каня от половин година поне. Срам, срам!…)
Категории: Професията на проджект мениджъра | Няма коментари
Препоръчано четиво: Agile Software Development
Гъвкавите (agile) методологии са постоянно обект на спорове и дискусии - дали са методологии, дали са форма на мениджмънт или стил на програмиране, дали въобще са полезни и какъв е техния смисъл.
Това донякъде е оправдано, като се има предвид, че повечето методи възникват като алтернатива на класическите (или тежки) методологии, които и до ден днешен се използват в големи и скъпи проекти и за съжаление не винаги успяват да доведат проекта до успешен край.
Честно да си призная, не съм голям почитател на гъвкавите методи, може би защото са прекалено радикални и екстремни. И аз, както и Steve McConnell, смятам, че много от идеите, които те проповядват, са полезни и биха могли да се използват при традиционното управление на проекти, но не всичко от agile development е приложимо за всички проекти. Както казват американците, “one size doesn’t fit all“.
Категории: Връзки, Препоръчано четиво, Разработка на софтуер | 2 коментара
Двата типа програмисти
Jeff Atwood от Coding Horror публикува наскоро една статия, озаглавена Двата типа програмисти, която разпали страстите и събра огромно количество противоречиви и емоционални коментари. По-късно, усетил, че нещата залитнаха в неправилната посока, той написа още един пост, опитвайки се да потуши страстите и да донесе мир, но войната вече се беше разгоряла. Аз ги прочетох и двата, при това няколко пъти. Прочетох и всички коментари и все още не съм много сигурен какво точно искаше да каже Джеф и защо го каза по този начин. Тук ще се опитам да представя моето виждане за нещата..
Той казва, че съществуват два вида програмисти - тип 0 (20%) са хората, които програмират за удоволствие. Тези хора живеят и дишат програмиране. Те използват Linux и участват в Open Source проекти. Иначе казано, (макар и той да не го казва в прав текст), това са готините пичове, истинските програмисти, умните програмисти. Другата група са тип 1 (80%) - хората, които програмират, за да си вадят хляба. Такива хора бихме могли да наречем “професионалисти”, но той ги нарича по-скоро “чиновници”. Те работят от 9 до 5, използват само Microsoft технологии и не четат технически статии и новини по интернет. “Те не са глупави”, казва той, но аз мисля, че точно това иска да каже, защото финалният призив е към умните момчета да преглътнат гордостта си и да помогнат на глупавите си другарчета да поумнеят и те.
Целта е всъщност благородна. Ако пък случайно вие почувствате, че сте от онези 80% - глупавите програмисти - не се притеснявайте - една от най-важните характеристики на групата на 20-те процента е, че те четат блогове, особено неговия. Така че, вие просто трябва да прочетете поне една статия от неговия блог и автоматично ще се прехвърлите в елитната група.
Съжалявам, Джеф, но не мога да приема това!
Категории: Разработка на софтуер | 3 коментара
Банка ДСК - софтуерно решение за управление на опашка от клиенти
Днес в блога си 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 коментара
Новият дом на блога за управление на софтуерни проекти
Добре дошли на страниците на PM Stories - блогът за разработка на софтуер и управление на проекти!
Започнах да пиша по тази тема преди няколко месеца в моя първи блог Спри и помисли!, но реших, че темата за software engineering и project management си заслужава свое собствено място, където да се концентрира интереса на програмисткото братство, и където (надявам се) да се включат повече хора в дискусиите, а защо не и като автори?
Този блог има и версия на английски език, но не всички постове са еднакви. Постовете на английски език третират теми, които засягат професията на софтуерния разработчик и на проджект мениджъра в по-общ смисъл и биха били интересни за читатели от целия свят. Постовете на български език са свързани с теми от нашата действителност, които са по-важни за нас, отколкото за чужденците. Надявам се, че тези от вас, които могат да четат на английски, ще намерят интересни неща и в английската версия на блога.
Ще се радвам, ако сред вас има желаещи да станат автори в този блог. Вярвам, че по този начин ще успеем да направим този блог истински полезен източник на информация в областта на софтуерното производство и управлението на проекти.
Добре дошли в PM Stories!
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл
Категории: Лични, Разработка на софтуер, Управление на проекти | Няма коментари
Анкета
Loading ...
-
-
Безплатен абонамент
-
Препоръчвам ви
-
Авторски права
-
Admin
