Това, на което попаднах, обаче, направо ме изуми. Graig Brown от блога Better Projects представи една статистика от доклада Chaos на Standish Group от 2002 г., в която се вижда, че цели 45% от изискванията, които клиентът е включил в проекта и са били реализирани, в крайна сметка въобще не се ползват. (Цъкнете върху картинката за по-голямо изображение.)

Като добавим и 19-те процента на много рядко използвани изисквания, положението придобива трагични размери. На практика, едва 20% от изискванията на клиента влизат в активна употреба, което означава, че огромно количество труд и енергия на проектиния екип са отишли на вятъра.

Какъв е изводът?

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

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

Така че – внимавайте с изискванията! Анализирайте ги детайлно и ги обсъдете неколкократно с възложителя, преди да ги включите в заданието. Иначе, в края на проекта ще бъдете затрупани с работа, клиентът ще недоволства, че закъснявате и няма да иска да си плати, а в крайна сметка, дори няма да ползва всички глезотии, които си е поискал.

Трябва да бъдем малко по-критични към техните изисквания. Това, в крайна сметка е за доброто и на двете страни.

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

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

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

• Техники за събиране на изисквания
• Как да ангажираме висшия мениджмънт в проекта?
• Документи на бизнес анализа
• Добри новини за онези, които се интересуват от бизнес анализ
• Международният институт по бизнес анализ обновява сертификационният си изпит

Не можете да извлечете бизнес изискванията за един продукт. Каквито и методи да ползвате, на края клиентът пак няма да е доволен.

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

За да направиш успешен продукт, трябва да го правиш за себе си. Тогава няма да има нужда да “събираш изисквания”, защото изискванията са в главата ти. Когато правиш нещо за себе си, ти го правиш с желание, разбиране и страст и то върши перфектна работа. Който има специални изисквания, да си направи продукта сам!

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

Прочетете статията тук. След нея има и огромно количество коментари, някои от които също заслужават по-голямо внимание.

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

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

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

• Внимавайте с изискванията на клиента!
• Техники за събиране на изисквания

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

• Наблюдение. Много често клиентът идва и ни представя своето виждане за това как трябва да изглежда новия продукт и какво трябва да прави без да може да обясни какъв точно е настоящият бизнес процес в неговата компания, нито как той ще се промени и подобри с внедряването на новото софтуерно решение. Един от най-ефективните подходи за разучаване на бизнес процеса, както и за навиците и нивото на техническа грамотност на потребителите, е просто да стоиш до тях и да наблюдаваш техните ежедневни действия. При наблюдението може много лесно да се видят недостатъци в работата, прекалено сложни или направо ненужни действия, които биха могли да бъдат отстранени, както и да ни хрумнат много идеи за подобряване на ефективността на процеса, а и оттам реална печалба за клиента от внедряване на новото софтуерно решение. Още по-добрият вариант е ако бизнес анализаторите сами имат възможността да поработят в условията, в които работи реалния потребител.
  За съжаление, много често сме притиснати от кратки срокове, особено във фазата на анализа (което е голяма грешка!) и рядко използваме този механизъм за събиране на информация.
  Понякога самият клиент, под предлог, че неговият процес е секретен, не ни разрешава достъп до хората, които го практикуват. В такива случаи трябва дебело да подчертаем пред него, че това е риск за правилното разбиране на заданието и съответно за успешното реализиране на проекта. Ако в последствие забележим трайна тенденция у клиента към укриване на информация, добре е да се замислим дали неговата цел е успешното завършване на този проект или нещо съвсем друго.
• Brainstorming. Поредната непреводима на български дума. Брейнстормингът е техника, която работи успешно в много случаи и анализът на изискванията е един от тях. По време на такава сесия, хората са освободени от задръжки и успяват да развихрят въображението си максимално, което води до генерирането на огромно разнообразие от идеи, някои от които могат да се окажат изключително ефективни. Много често възложителят сам не е в състояние да измисли изискванията към продукта, защото самият продукт ще трябва да работи в среда, която в момента не съществува – един нов процес, който тепърва трябва да бъде измислен. Брейнстормингът е много ефективен начин да помогнем на нашия клиент да изясни за себе си какво трябва да се направи, за да бъде продуктът успешен.
• Разработване на прототип. Този метод е един от най-добрите в софтуерния бизнес, но за сметка на това е и един от най-скъпите. Най-добре приложим е в проекти, където се разработва нещо съвсем ново и уникално като концепция и където качеството на резултата е по-важно от цената. Разработката на софтуер е много специфичен бизнес и една от най-важните му характеристики е неговата абстрактност – той не може да се види и да се пипне, още по-малко докато е в процес на разработка. Затова, каквото и да си говорим с клиента, каквито и спецификации да обсъждаме, винаги съществува една голяма вероятност да не сме се разбрали правилно и в момента, в който му представим нашия продукт, той да се окаже неприятно изненадан. Разработката на прототип ни предпазва от това, като ни дава възможността на един много ранен етап да покажем “на живо” възможностите на поръчания продукт. Когато потребителят го “пипне” и усети, тогава ще има много по-ясна представа дали това, което ще получи, е точно това, което му трябва и ако не е – ще има възможността да коригира изискванията си достатъчно рано, че те да могат да бъдат имплементирани.

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

Ще се радвам да споделите примери от вашата практика – какви методи ползвате и дали винаги успявате да ги приложите?

Този пост е достъпен и на английски език. 

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

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

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

• Внимавайте с изискванията на клиента!
• Документи на бизнес анализа
• Добри новини за онези, които се интересуват от бизнес анализ
• Международният институт по бизнес анализ обновява сертификационният си изпит
• Българската секция на Международния институт по бизнес анализ е вече факт