Comments on: Трябва ли анализът да е “тромав”?

By: georgim

georgim — Mon, 26 May 2008 11:34:47 +0000

Хъмм признавам, че не съм достатъчно запознат с този процес и на пръв поглед прочитайки статията останах с впечатлението, че се чудим, има ли смисъл да правим формален анализ или… като се замисля от това което казва (Петър) явно има някакво двоумене но не ми е ясно точно къде е.
Освен това … смяната на изискванията “ежедневно” ми звучи като хубава рецепта за зрелищен провал на един проект.
Всични сме работили с клиенти които си сменят мението сутрин, обед и вечер и знаем че няма начин да следваш бурния полет на мисълта има дори само в спецификацията да не говорим за девелопмент.
И аз съм привърженик на кратки дежелопмен цикли, рапид прототайпинг, и други такива “врътки” … но всеки ден ми се струва прекалено рапид. (вероятно те разбирам прекалено буквално но…)
Напоследък четох за един интересен девелопмент подход (Scrum) който може би е добра тема за статийка … въобще… Мике? дали на читателите ти няма да им е интересно да видят серия от постове описващи “екзотични” ПМ и девелопмент техники?
И съответно коментари които да казват кой ги е пробвал и какви са резултатите (добри/лоши) и зашо?
Аз лично на няколко(2) места съм наблюдавал до какво води когато двама разработчици работят заедно (на един компютър)… резултата е повече от задоволителен. За себе си съм убеден че производителноста не е 1/2 (тоест еквивалент на 1 човек при работещи двама) а по-скоро 150% (все едно че работят трима поне, и то без неизбежния комуникационен оверхеад /да ме прощавате за неправиланта употреба на английски)

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

Петър Лефтеров — Thu, 22 May 2008 14:05:03 +0000

Здравей Георги, радвам се че статията е привлакла интереса ти.

Относно процедурите никъде не съм написал, че не трябва да се спазват. Когато говоря за гъвкавост и “тромавост” това е в директна връзка с Agile методиките. А повечето от тях си имат много стриктни процедури и изобщо не толерират нарушаването им.

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

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

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

By: Майк Рам

Майк Рам — Thu, 22 May 2008 11:41:40 +0000

Здрасти, Жоро!
Добре дошъл на борда!

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

By: georgim

georgim — Thu, 22 May 2008 10:20:54 +0000

Убеден съм, че бизнес анализа трябва да е “формален” (не “тромав”). Под формален разбирам, че трябва да са минати всички стъпки от избрания в организацията процес и да са изработени всички необходими документи (като МНОГО важно е, че организацията ТРЯБВА да има Документиран съответния процес). Виж какъв е процесът и какво трябва да пише в документите е въпрос който е по-сложен и подлежи на оптимизация в зависимост от организацията.

Да направим няколко предположения и да поразсъждажаме над тях.
За начало се абстрахираме от въпроса дали ни трябва “формализирана” система за анализ на изискванията на клиентите.

Ако човекът който прави анализа няма дарбата/уменията/опита да разговаря с клиенти и да анализира техните нужди … липсата на формална система описваща стъпките по които той трябва да проведе процеса на анализа и съсответно шаблони за документи които да го насочват към задаването на важните въпроси и изясняването им в определни детайли би ли му помогнало с нещо?
Не бих казал… убеден съм, че най-малкото не би му навредила. (даже бих казал, че би му била изключително полезна/незаменима и би му помогнала да направи един приемлив макар и не добър анализ)

Ако от друга страна човекът е МНОГО добър в работата си с клиентите и може да вникне дълбоко в техните проблеми и изисквания… но не документира тези неща надлежно?
Какво става когато точно след като приключи 1-2 месечния анализ в който е работил с 15+ души от страна на клиента той си счупи крак или се напие и получи амнезия??? Не мисля, че по паметни бележки (ако въобще е водил такива) може да се възпроизведе анализа на изискванията на клиентите.
(тоест още една точка за “формалните” процедури и документи)
От друга страна… (ако не си счупи кракът)… пречи ли с нещо формалната процедура и формалните документи? Според мене не – ако процедурата/шаблоните са добри то в тях е ясно какво може да се пропусне и какво не, така че тяхното изработване не би трябвало да затрудни аналитика повече от колкото е необходимо. (Ако не са добри то най-добре си ги оправете защото това отново е задача на добрия БА или по точно на групата БА-ци)
Хъмм … като преброя точките… май няма ни една в полза на това да Няма формална процедура.

By: Първи гост-автор в PM Stories - Петър Лефтеров : PM Stories

Първи гост-автор в PM Stories - Петър Лефтеров : PM Stories — Mon, 19 May 2008 07:05:11 +0000

[...] PM Stories се появи първата статия, написана от гост-автор – Трябва ли анализът да е “тромав”? от Петър [...]