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

By: Петър Лефтеров

Петър Лефтеров — Wed, 13 Feb 2008 14:08:41 +0000

Проблемът на тези методи е, че са прекалено общи. “Интервю с клиента” не е техника. Техника е това, което правиш в интервюто. А отворени въпроси е начин да поддържаш разговор с който и да е, за каквото и да е.

На мен любимият ми подход е на накарам човека да опише как си представя работата си след като се въведе системата и да документирам процеса. С подходящи насочващи въпроси се добива доста ясна представа.

Естествено ако имам време документирам и стария процес. За това наистина директното наблюдение е най-сигурният начин, но никога не съм имал време да стигам дотам.

За самата система рядко питам директно. Обикновено ги прокрадвам като странични въпроси като “Аха, значи тук смяташ да правиш еди какво си със системата?”. Обикновено когато питам директно “Какво искаш” после много съжалявам. Отговорът в 90% от случаите забива разговора в прекалена конкретика и ми трябват 20-30 мин. за да се ориентирам за какво се говори и да го насоча обратно към по-общата картина.

By: Techniques for Gathering Requirements : PM Stories

Techniques for Gathering Requirements : PM Stories — Tue, 05 Feb 2008 18:09:18 +0000

[...] This post is also available in Bulgarian language. [...]

By: Nikolay

Nikolay — Tue, 29 Jan 2008 19:09:01 +0000

Tom Mochal е наистина много добър във всеки елемент от управлението на проекти. Само искам да наблегна на нещо – той НЕ говори само за IT проекти и следва доста стриктно по PMBOK-а като се абстрахира от спецификата на проекта.

Относно моя опит. Обикновено имаме начален документ разработен “самостоятелно” от клиент (говорим за вътрешни проекти) и след това на базата на този документ (чрез срещи за уточняване на изискваният) се изготвят по-точни и детайлни изисквания. Като много често има срещи един-на-един или сесии за уточняване на цял компонент.

By: Илия Добрев

Илия Добрев — Tue, 29 Jan 2008 12:15:38 +0000

Техниките които си изброил са много полезни, аз лично имам едно основно правило, може да се стори на някой доста крайно, то е:
“Клиента никога не знае какво точно иска”.
Клиента идва с конкретен проблем и сам никога не може да обхване пълната специфика което би изисквало софтуерното решение. Аз мисля че най-полезните техники са “Наблюдение” и “Brainstorming” за да се предвиди какви нужди би имал клиента след известно време(зависи от проекта), а “Разработване на прототип” е много хубаво и скъпо нещо.