Публикувано на: 10 февруари, 2022*Автор: Искра Бочева, Бизнес анализатор в софтуерната компания DataArt
Искра Бочева работи в сферата на бизнес анализа от 2005 г., а през 2017 година става част от екипа на DataArt. Притежава солиден опит както в ИТ бизнес анализа, така и в банковата сфера – работила е за финансови институции като ДСК, Уникредит Булбанк и др. Специализира в BA процесите в областта на електронната търговия и електронните разплащания.
Какво включва работата на бизнес анализаторите и кои са основните термини, които използват те в ежедневната си дейност?
Ще разгледаме основните понятия, както и каква е тяхната роля и приложение в процеса на разработване на нови системи и функционалности.
1. Обхват
Това е първото нещо, което анализаторът трябва да уточни в проекта. Включва преди всичко функционалностите, които трябва да бъдат разработени. Този термин се отнася и до това кои софтуерни модули трябва да бъдат създадени или модифицирани, както и за кои видове потребители трябва да работи – например потребител „клиент“, потребител „бекофис“ и т.н. Важно е да се уточнят и нещата, попадащи извън обхват, за да е сигурно, че няма погрешни очаквания.
2. Stakeholder
Това са хората, които определят изискванията. Често пъти това са директори на отдели, които желаят да внедрят нови системи и по този начин да оптимизират работата на своя отдел или предприятие. Могат също така да бъдат потребители-експерти, които детайлно познават текущия начин на работа, текущите системи и какво е необходимо да се подобри. Бизнес анализаторът комуникира с тези хора ежедневно, затова е много важно да изгради добри отношения с тях. Дори се препоръчва комуникацията помежду им да не прекалено формална, а в малко по-свободен стил.
3. Приложение
Това най-често са софтуерните системи, които трябва да бъдат разработени и за които бизнес анализаторът подготвя изискванията. Те могат да са базирани на различни платформи и технологии – например уеб приложение, мобилно приложение, десктоп приложение, IoT, Cloud. Всяко от тях има своите технически особености, с които е добре бизнес анализаторът да се запознае при подготовката за проекта.
4. Спецификация / user story
Това всъщност е писменото представяне на изискванията. То е много важна част от работата на бизнес анализатора. От една страна stakeholder-ите трябва да разгледат и потвърдят изискванията, а от друга – програмистите и валидаторите да използват спецификациите по време на имплементацията. Изискванията могат да се представят по различен начин. Доскоро се подготвяше техническата спецификация – документ, описващ една или повече функционалности, включително стъпките от процеса, workflow диаграми и други видове диаграми. Все повече се налага agile начинът на представяне на изискванията – на малки части, наречени user stories, където изискванията се предават в GIVEN/WHEN/THEN формат. Това е предпочитан начин от програмистите, тъй като се доближава доста до техния if/then/else логически формат.
5. Потребител
Това са различните роли, чрез които ще се използват новите функционалности. Важно е те да се уточнят още в най-ранна фаза – при определянето на обхвата на проекта. Потребителските роли могат да се представят чрез няколко различни техники – например като User persona, където описваме примерен представител на ролята – какъв човек е, какво прави ежедневно, от какви функционалности има нужда, за да улесни своите задачи и т.н.. Друг вариант е Use Case диаграмата от UML стандарта – на нея представяме основните роли и функциите, които те ще извършват. Често се използва и вариантът да представим ролята още в името на дадено User Story – във формата „As a <потребителска роля> I want to … so that …“
6. Потребителски интерфейс (UI)
Важна част от бизнес анализа е дискутирането и представянето на екраните на бъдещите функционалности. Това могат да бъдат напълно нови екрани или пък промени по съществуващите – например да се добави ново поле. Много е важно да се вземе под внимание използваемостта (usability) на тези екрани – например екраните да не са претрупани с информация, често използваните действия да са разположени по-нагоре и по-наляво, също да се изберат подходящи шрифтове и цветове.
Визията на екрана може да се предаде с няколко техники – първоначално се подготвя само wireframe – черно-бяла схема, представяща UI компонентите и тяхното разположение на екрана, например за всеки един екран от процеса, който специфицираме. Когато тези екрани се одобрят, те могат да се доразвият до Mockup и Prototype – първото представя същия екран, но с цветове, стилове и картинки, а второто добавя и навигация между екраните, например натискането на бутон да отвори друг определен екран. Mockup и Prototype много често се изготвят от UI UX дизайнер.
7. Дискусия
Бизнес анализаторът често води или поне участва в много дискусии. Някои от тях разглеждат функционалностите на по-високо ниво – например на срещите с бизнеса. Други срещи разглеждат техническите детайли и вариантите за имплементацията – такива са срещите със solution архитекти, както и срещите с екипа разработчици. Важна роля на бизнес анализатора е да събере отворени въпроси от дадена група хора, например от екипа разработчици, и да намери техните отговори чрез срещи с други групи хора, например с бизнеса.
Loading …
София
Hybrid
8. Отворени въпроси
Най-общо въпросите могат да бъдат генерални и детайлни. Генералните обикновено се задават още в самото начало при определянето на обхвата – например върху какви платформи трябва да работи новата функционалност. Детайлните въпроси се задават при разписването на детайлните изисквания, например user stories, и целят да изяснят всички възможни разклонения в процеса – какви са валидациите на дадена стъпка, какво се случва при възникване на грешка на тази стъпка и т.н. Това е много важно и за процеса по приемане на готовия продукт от клиента (User acceptance test) – за да сме сигурни, че няма да има промени в системата на този късен етап.
9. Workflow
Много важно е бизнес анализаторът да представи цялостния процес и към коя част от него се отнасят новите функционалности. Много често бизнесът цели да замести един ръчен процес с нов автоматизиран или пък да замени един автоматизиран процес с нов такъв, който е по-удобен за работа и по-оптимизиран с цел да намали стъпките на потребителя или да добавя нови роли.
За целта много полезни са диаграмите. В случая най-подходящи са Swimlane diagram, която представя всеки потребител и неговите действия в отделен „коридор“, както и Data flow diagram, която представя процеса чрез няколко обекта. Тези обекти включват: external entity (външни за системата фактори – например потребителски роли или други системи); data flow (групи от данни, които се обменят); процеси, обработващи данните, и data store (вътрешни системи или бази, които съхраняват данните).
10. Диаграма
Чрез диаграмата бизнес анализаторът чертае и представя различни аспекти от новата система или функционалности. Диаграмата онагледява информацията по много достъпен начин, за да могат всички участници да разберат информацията, да поискат корекции или да зададат уточняващи въпроси. Препоръчително е да се използват стандартни видове диаграми – например Use case diagram, Sequence diagram, Activity diagram от UML стандарта.
11. Функционалност / feature
Важно е изискванията да бъдат представени в структуриран вид, защото няма как всичко да бъде имплементирано и тествано наведнъж. Затова трябва да разделим изискванията на части (функционалности), а тях на още части – например user story или просто задача за разработка. Така тези части могат лесно да се разпределят между програмистите. Подобна е и структурата в Jira, където имаме ниво Epic и ниво User story. Когато ги подготвяме, трябва да помислим и за качеството на изискванията – да бъдат точни, измерими, постижими, релевантни, обвързани във времето (т. нар. SMART критерий).
12. Приоритет
Това е показател доколко важна е дадена функционалност и на кой етап да бъде имплементирана. Много често това зависи от бизнес стойността на функционалността, но също се определя и от техническите особености – някои функционалности са основа за други и трябва да се разработят първи. Аналогичен (и опростен) пример е да се опитаме да построим къща, но да пропуснем мазето, защото не е толкова важно за нас, но да го добавим на по-късен етап. Затова винаги трябва да взимаме под внимание техническите препоръки и особености – често те се разискват със Solution архитектите.
13. Зависимост
Много често една функционалност зависи от друга или дори от няколко. Например ако тази функционалност ги надгражда с допълнителни функции или пък е стъпка в процес, която се предшества от други стъпки или е необходимо изграждане на свързаност (интерфейс) между системите преди да се премине към потребителските функции. Тези зависимости могат да се отбележат на ниво функционалност или на ниво user story. В Jira може да се отбележи кое user story зависи от друго и каква е зависимостта – blocks, is blocked by, relates to, duplicates и т.н.
Нещата стават още по-сложни, когато стъпката, от която зависим, трябва да се изпълни от друг екип или от друга компания. В тези случаи е много важно задачите и сроковете да се координират от бизнес анализатора или от мениджъра на проекта, а самите детайли относно функционалностите да се комуникират проактивно и да се дискутират от страна на бизнес анализатора, за да няма изненади при получаването на готовата задача.
14. Валидации
Важно е да се проверяват данните, които постъпват в системата, защото няма идеални потребители. Може да се случи потребител да въведе грешна стойност, да избере грешна комбинация от параметри или пък да постъпят грешни данни чрез интерфейс от друга система. Важно е да защитим нашата функционалност от грешни данни, затова е необходимо да се въведат проверки на различни нива – на ниво потребителски интерфейс още при въвеждането на данните от потребителя на ниво сървър, когато получаваме данните от потребителския интерфейс или от други системни интерфейси. Тези проверки трябва да бъдат описани ясно в user story-тата, за да бъдат взети под внимание при разработването и тестването на системата.
15. Противоречиви изисквания
Често бизнес анализаторът комуникира с различни stakeholder-и. Възможно е да има различия в техните очаквания за новата система относно потребителските групи, приоритетите за разработка или детайлите на изискванията. В тези случаи бизнес анализаторът трябва да поеме ролята на балансьор и да намери консенсус между stakeholder-ите. Има много техники за това – да разговаря с всеки поотделно, да открие интересите, стоящи зад различаващите се изисквания, да се опита да намери решение, удовлетворяващо всички интереси, да предложи компромис, да организира обща дискусия със stakeholder-ите, да се гласува или да се ескалира към по-високо ниво, което да вземе решение.
Казано иначе, работата на бизнес анализатора е комплексна, изисква много добро ниво на комуникация и детайлно разписване на изискванията, за да се гарантира успешно разработен продукт, доволни клиенти и нови поръчки за следващи функционалности.
