Техники за събиране на изисквания
Наскоро ми попадна една статия, озаглавена 10 техники за събиране на изисквания. Tom Mochal е много авторитетен експерт в областта на проджект мениджмънта и аз много ценя неговото мнение, но някои от нещата, описани в тази статия ми изглеждат съвсем тривиални, като обсъждане с един човек, обсъждане с двама човека и обсъждане с 3-4 човека.
По-интересно за мен беше това, че той посочва някои техники, които ми се струва, че не са толкова популярни, а според мен са изключително ефективни. Затова реших да се спра на тях и ги разгледам по-детайлно.
- Наблюдение. Много често клиентът идва и ни представя своето виждане за това как трябва да изглежда новия продукт и какво трябва да прави без да може да обясни какъв точно е настоящият бизнес процес в неговата компания, нито как той ще се промени и подобри с внедряването на новото софтуерно решение. Един от най-ефективните подходи за разучаване на бизнес процеса, както и за навиците и нивото на техническа грамотност на потребителите, е просто да стоиш до тях и да наблюдаваш техните ежедневни действия. При наблюдението може много лесно да се видят недостатъци в работата, прекалено сложни или направо ненужни действия, които биха могли да бъдат отстранени, както и да ни хрумнат много идеи за подобряване на ефективността на процеса, а и оттам реална печалба за клиента от внедряване на новото софтуерно решение. Още по-добрият вариант е ако бизнес анализаторите сами имат възможността да поработят в условията, в които работи реалния потребител.
За съжаление, много често сме притиснати от кратки срокове, особено във фазата на анализа (което е голяма грешка!) и рядко използваме този механизъм за събиране на информация.
Понякога самият клиент, под предлог, че неговият процес е секретен, не ни разрешава достъп до хората, които го практикуват. В такива случаи трябва дебело да подчертаем пред него, че това е риск за правилното разбиране на заданието и съответно за успешното реализиране на проекта. Ако в последствие забележим трайна тенденция у клиента към укриване на информация, добре е да се замислим дали неговата цел е успешното завършване на този проект или нещо съвсем друго. - Brainstorming. Поредната непреводима на български дума. Брейнстормингът е техника, която работи успешно в много случаи и анализът на изискванията е един от тях. По време на такава сесия, хората са освободени от задръжки и успяват да развихрят въображението си максимално, което води до генерирането на огромно разнообразие от идеи, някои от които могат да се окажат изключително ефективни. Много често възложителят сам не е в състояние да измисли изискванията към продукта, защото самият продукт ще трябва да работи в среда, която в момента не съществува - един нов процес, който тепърва трябва да бъде измислен. Брейнстормингът е много ефективен начин да помогнем на нашия клиент да изясни за себе си какво трябва да се направи, за да бъде продуктът успешен.
- Разработване на прототип. Този метод е един от най-добрите в софтуерния бизнес, но за сметка на това е и един от най-скъпите. Най-добре приложим е в проекти, където се разработва нещо съвсем ново и уникално като концепция и където качеството на резултата е по-важно от цената. Разработката на софтуер е много специфичен бизнес и една от най-важните му характеристики е неговата абстрактност - той не може да се види и да се пипне, още по-малко докато е в процес на разработка. Затова, каквото и да си говорим с клиента, каквито и спецификации да обсъждаме, винаги съществува една голяма вероятност да не сме се разбрали правилно и в момента, в който му представим нашия продукт, той да се окаже неприятно изненадан. Разработката на прототип ни предпазва от това, като ни дава възможността на един много ранен етап да покажем “на живо” възможностите на поръчания продукт. Когато потребителят го “пипне” и усети, тогава ще има много по-ясна представа дали това, което ще получи, е точно това, което му трябва и ако не е - ще има възможността да коригира изискванията си достатъчно рано, че те да могат да бъдат имплементирани.
Тези техники не са единствените възможни, но са изключително ефективни. За съжаление, има много случаи, в които не ни се удава възможност да ги ползваме, особено в проекти, за които се прави търг, и в които много рядко се дава възможност за общуване с клиента преди да се подаде официалната оферта с техническото предложение и цената. Много често се налага да правим анализ на процесите след като имаме подписан договор и поети ангажименти, което ни поставя в много неприятна ситуация.
Ще се радвам да споделите примери от вашата практика - какви методи ползвате и дали винаги успявате да ги приложите?
Този пост е достъпен и на английски език.
Гласувайте за тази статия в Svejo.net:
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл
Коментари
4 коментара to “Техники за събиране на изисквания”
Споделете вашето мнение
Анкета
Loading ...
-
-
Безплатен абонамент
-
Препоръчвам ви
-
Авторски права
-
Admin
Техниките които си изброил са много полезни, аз лично имам едно основно правило, може да се стори на някой доста крайно, то е:
“Клиента никога не знае какво точно иска”.
Клиента идва с конкретен проблем и сам никога не може да обхване пълната специфика което би изисквало софтуерното решение. Аз мисля че най-полезните техники са “Наблюдение” и “Brainstorming” за да се предвиди какви нужди би имал клиента след известно време(зависи от проекта), а “Разработване на прототип” е много хубаво и скъпо нещо.
Tom Mochal е наистина много добър във всеки елемент от управлението на проекти. Само искам да наблегна на нещо - той НЕ говори само за IT проекти и следва доста стриктно по PMBOK-а като се абстрахира от спецификата на проекта.
Относно моя опит. Обикновено имаме начален документ разработен “самостоятелно” от клиент (говорим за вътрешни проекти) и след това на базата на този документ (чрез срещи за уточняване на изискваният) се изготвят по-точни и детайлни изисквания. Като много често има срещи един-на-един или сесии за уточняване на цял компонент.
[…] This post is also available in Bulgarian language. […]
Проблемът на тези методи е, че са прекалено общи. “Интервю с клиента” не е техника. Техника е това, което правиш в интервюто. А отворени въпроси е начин да поддържаш разговор с който и да е, за каквото и да е.
На мен любимият ми подход е на накарам човека да опише как си представя работата си след като се въведе системата и да документирам процеса. С подходящи насочващи въпроси се добива доста ясна представа.
Естествено ако имам време документирам и стария процес. За това наистина директното наблюдение е най-сигурният начин, но никога не съм имал време да стигам дотам.
За самата система рядко питам директно. Обикновено ги прокрадвам като странични въпроси като “Аха, значи тук смяташ да правиш еди какво си със системата?”. Обикновено когато питам директно “Какво искаш” после много съжалявам. Отговорът в 90% от случаите забива разговора в прекалена конкретика и ми трябват 20-30 мин. за да се ориентирам за какво се говори и да го насоча обратно към по-общата картина.