Техники за събиране на изисквания

Наскоро ми попадна една статия, озаглавена “10 техники за събиране на изисквания”. Tom Mochal е много авторитетен експерт в областта на проджект мениджмънта и аз много ценя неговото мнение. Тук някои от нещата, описани в статията ми изглеждат съвсем тривиални, като обсъждане с един човек, обсъждане с двама човека и обсъждане с 3-4 човека.

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

Наблюдение

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

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

Още по-добрият вариант е ако бизнес анализаторите сами имат възможността да поработят в условията, в които работи реалния потребител. За съжаление, много често сме притиснати от кратки срокове, особено във фазата на анализа (което е голяма грешка!) и рядко използваме този механизъм за събиране на информация.

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

Brainstorming

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

Брейнстормингът е много ефективен начин да помогнем на нашия клиент да изясни за себе си какво трябва да се направи, за да бъде продуктът успешен.

Разработване на прототип

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

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

Разработката на прототип ни предпазва от това, като ни дава възможността на един много ранен етап да покажем “на живо” възможностите на поръчания продукт. Когато потребителят го “пипне” и усети, тогава ще има много по-ясна представа дали това, което ще получи, е точно това, което му трябва. И ако не е – ще има възможността да коригира изискванията си достатъчно рано, че те да могат да бъдат имплементирани.

Заключение

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

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

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

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