Трябва ли анализът да е “тромав”?
Търсейки интересна тема за бизнес анализ попаднах на дискусия по тема, която често съм обсъждал и аз с колеги. В своята статия Do we need Agile Business Analysys? Крейг Браун задава въпроса дали Agile не прави бизнес аналитика като позиция излишен, което провокира добър отговор от професионалист съчетаващ двете.
Според мен отговорът зависи от това как възприемаме бизнес аналитика като задължения и позиция. И с каква цел организацията е намерила такава позиция за нужна.
Много организации и ИТ фирми приемат бизнес аналитика като позиция, която придава тежест. Независимо дали си ИТ фирма бореща се за проекти или ИТ мениджър, желаещ да покаже професионализъм, винаги е от полза да имаш хубав, подреден бизнес анализ, завършващ с красив, голям документ с много диаграми, носещ гръмкото название Business Requirements Specification. Това показва че си сериозен. В тази ситуация бизнес анализа се налага да е бюрократичен, бавен и негъвкав, по простата причина, че той е създаден с тази мисъл и с тази цел.
Не мога да отрека, че за много колеги тази идея е привлекателна и дори признавам, че в много случаи именно бизнес аналитиците се явяват основен адвокат на бюрокрацията. Това обаче е черта на някои организации и хора, прилагащи бизнес анализ – не на самата дисциплина.
Първата основна цел на бизнес аналитика не е да документира, а да определи изискванията на клиента, и един добър специалист би трябвало да го направи по-добре отколкото самият клиент. Би било добре ако живеехме в идеален свят, където клиентът винаги знае всички изисквания на организацията си, говори конкретно и по същество, обмисля всичко, което може да се обърка в процеса му на работа и съобщава всичко това с разбираеми за програмистите термини. Но случаят рядко е такъв.
Втората цел е да предаде на програмистите целите и изискванията, и да следи дали софтуера в разработка се движи в правилната посока. Именно в тази си роля замества „клиента на място”, който е запазена марка на Agile. С тази разлика, че има солидни ИТ познания, поради което задава по-малко глупави въпроси и е способен свободно да участва в дискусии по проблемите на дизайна.
Нека предположим, че изхвърлим „лошия” бизнес анализ, с всичките процедури, документи, и т.н. Очевидно е, че горните два задачи трябва да се вършат от някой, бил той програмист или клиент. За да ги върши качествено, той трябва да мине специално обучение. По принципа на добавената стойност когато този човек веднъж стане наистина добър в тази работа, няма смисъл да се занимава с неща, с които е по-малко полезен. Като ежедневната си работа (ако е клиент) или програмиране (ако е програмист). Та логичният въпрос който следва е: как точно ще се казва длъжността на този човек?
Споделете как е при вас. Работите ли с бизнес аналитици? Бизнес анализа какви нужди обслужва – чисто административни или свързани със самото изпълнение на проекта? Ако административната полза изчезне бихте ли продължили да ползвате бизнес аналитици в проектите си?
Гласувайте за тази статия в Svejo.net: [wp:svejo-net]
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл.
[…] PM Stories се появи първата статия, написана от гост-автор – Трябва ли анализът да е “тромав”? от Петър […]
Убеден съм, че бизнес анализа трябва да е “формален” (не “тромав”). Под формален разбирам, че трябва да са минати всички стъпки от избрания в организацията процес и да са изработени всички необходими документи (като МНОГО важно е, че организацията ТРЯБВА да има Документиран съответния процес). Виж какъв е процесът и какво трябва да пише в документите е въпрос който е по-сложен и подлежи на оптимизация в зависимост от организацията.
Да направим няколко предположения и да поразсъждажаме над тях.
За начало се абстрахираме от въпроса дали ни трябва “формализирана” система за анализ на изискванията на клиентите.
Ако човекът който прави анализа няма дарбата/уменията/опита да разговаря с клиенти и да анализира техните нужди … липсата на формална система описваща стъпките по които той трябва да проведе процеса на анализа и съсответно шаблони за документи които да го насочват към задаването на важните въпроси и изясняването им в определни детайли би ли му помогнало с нещо?
Не бих казал… убеден съм, че най-малкото не би му навредила. (даже бих казал, че би му била изключително полезна/незаменима и би му помогнала да направи един приемлив макар и не добър анализ)
Ако от друга страна човекът е МНОГО добър в работата си с клиентите и може да вникне дълбоко в техните проблеми и изисквания… но не документира тези неща надлежно?
Какво става когато точно след като приключи 1-2 месечния анализ в който е работил с 15+ души от страна на клиента той си счупи крак или се напие и получи амнезия??? Не мисля, че по паметни бележки (ако въобще е водил такива) може да се възпроизведе анализа на изискванията на клиентите.
(тоест още една точка за “формалните” процедури и документи)
От друга страна… (ако не си счупи кракът)… пречи ли с нещо формалната процедура и формалните документи? Според мене не – ако процедурата/шаблоните са добри то в тях е ясно какво може да се пропусне и какво не, така че тяхното изработване не би трябвало да затрудни аналитика повече от колкото е необходимо. (Ако не са добри то най-добре си ги оправете защото това отново е задача на добрия БА или по точно на групата БА-ци)
Хъмм … като преброя точките… май няма ни една в полза на това да Няма формална процедура.
Здрасти, Жоро!
Добре дошъл на борда! 🙂
Много хубави доводи си изложил и са идеална основа за една интересна дискусия. Аз лично не смятам, че тезата на Петър е, че няма нужда от формални процедури. По-скоро акцентът е върху това, че в някои организации формализацията и бюрокрацията вземат връх над здравия разум, от което, в крайна сметка страда самия проект.
Здравей Георги, радвам се че статията е привлакла интереса ти.
Относно процедурите никъде не съм написал, че не трябва да се спазват. Когато говоря за гъвкавост и “тромавост” това е в директна връзка с Agile методиките. А повечето от тях си имат много стриктни процедури и изобщо не толерират нарушаването им.
Виж намаляването на документацията определено се препоръчва в Agile подхода, но това се компенсира от процедури за чести срещи с цел обмен на информация в рамките на екипа и извън него.
Проблемът обаче е че много привърженици на Agile отричат бизнес анализа в неговата цялост. Тяхната процедура изисква ежедневна комуникация с клиента и промяна на изискванията. Бизнес аналитика, работещ 1 месец над подробна спецификация няма място в техния процес.
Тезата ми е, че няма никаква обективна причина анализа да се върши на дълги, мащабни итерации, и при нужда може да се приспособи към процеса на Agile без това да представлява голям компромис с качеството му и ползата от него.
Хъмм признавам, че не съм достатъчно запознат с този процес и на пръв поглед прочитайки статията останах с впечатлението, че се чудим, има ли смисъл да правим формален анализ или… като се замисля от това което казва (Петър) явно има някакво двоумене но не ми е ясно точно къде е.
Освен това … смяната на изискванията “ежедневно” ми звучи като хубава рецепта за зрелищен провал на един проект.
Всични сме работили с клиенти които си сменят мението сутрин, обед и вечер и знаем че няма начин да следваш бурния полет на мисълта има дори само в спецификацията да не говорим за девелопмент.
И аз съм привърженик на кратки дежелопмен цикли, рапид прототайпинг, и други такива “врътки” … но всеки ден ми се струва прекалено рапид. (вероятно те разбирам прекалено буквално но…)
Напоследък четох за един интересен девелопмент подход (Scrum) който може би е добра тема за статийка … въобще… Мике? дали на читателите ти няма да им е интересно да видят серия от постове описващи “екзотични” ПМ и девелопмент техники?
И съответно коментари които да казват кой ги е пробвал и какви са резултатите (добри/лоши) и зашо?
Аз лично на няколко(2) места съм наблюдавал до какво води когато двама разработчици работят заедно (на един компютър)… резултата е повече от задоволителен. За себе си съм убеден че производителноста не е 1/2 (тоест еквивалент на 1 човек при работещи двама) а по-скоро 150% (все едно че работят трима поне, и то без неизбежния комуникационен оверхеад /да ме прощавате за неправиланта употреба на английски)