PM Stories » Бизнес анализ

Документи на бизнес анализа

Майк Рам — Wed, 09 Mar 2011 15:02:14 +0000

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

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

За щастие, попаднах на една доста изчерпателна статия в сайта Modern Analyst, която представя систематизирано всички необходими документи, които трябва да бъдат произведени в резултат на бизнес анализа, както и основните компоненти на тяхното съдържание. Това е от огромна полза, както за анализаторите, които много по-лесно ще могат да изготвят нужните за проекта документи, така и за останалите членове на проектния екип, които ще знаят коя информация къде трябва да се намира и много по-лесно да я открият и да оценят нейното качество и полезност.

Документите, които са представени в публикацията са:

Current state analysis document (Анализ на текущото състояние)
Project vision document (Визия за проекта)
Solution vision document (Визия за решението / продукта)
Business requirements document (Бизнес изисквания)
Business process design document (Дизайн на бизнес процесите)
Use case model document (Use case модели)
Use case specification document (Use case спецификации)
System-wide requirements document (Системни изисквания)
Solution glossary (Речник на решението)

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

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

Надявам се, че използвайки тези документи по начина, представен в тази статия, можем значително да подобрим резултатността на нашите проекти.

Гласувайте за тази статия в Svejo.net:

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

Вижте и тези публикации:

Добри новини за онези, които се интересуват от бизнес анализ

Майк Рам — Mon, 15 Mar 2010 13:42:00 +0000

Едната добра новина идва благодарение на Мария Недялкова, вицепрезидент “Маркетинг и комуникации” на българската секция на Международния институт за бизнес анализ (IIBA). Институтът съобщава на своя сайт, че съществено е намалил цените на членския внос, съобразно покупателната способност на страната, в която живее кандидат-членът. Ако искате да станете член на IIBA или на неговата българска секция, вече ще трябва да заплатите само $40, вместо досегашната такса от $95. Това, предполагам, че ще привлече повече хора, които се интересуват от най-новите идеи и постижения в бизнес анализа, да се включат активно в дейността на тази авторитетна международна организация, която от близо 2 години развива дейност и у нас.

Другата новина е съвсем безплатна: благодарение на Крейг Браун, научаваме, че IIBA са се споразумели с Google и вече предлагат своя най-важен документ – The Business Analysis Body of Knowledge (BABOK) като част от библиотеката Google Books за свободно четене онлайн. В този документ са събрани най-добрите практики в областта на бизнес анализа и той дава изключително полезни идеи как да се прилага ефективно и полезно тази дейност. Всички, който се занимават в някаква степен с бизнес анализ – професионални бизнес анализатори, софтуерни разработчици или бизнес стратези – могат да извлекат полезни идеи и техники от тази книга.

Не се колебайте – прочетете я!

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Международният институт по бизнес анализ обновява сертификационният си изпит

Майк Рам — Wed, 29 Jul 2009 11:55:10 +0000

Това е прес-съобщение от Българската секция на Международния институт по бизнес анализ.

Международният институт по бизнес анализ (International Institute of Business Analysis – IIBA) обновява сертификационен изпит Certified Business Analyst Professional (CBAP). Считано от 1 август 2009 г. новата версия на изпита ще включва ново съдържание, съответстващо на обновените и подобрени стандарти на института.

Промяната е в съответствие с публикуваната през март 2009 г. версия 2.0 на Business Analysis Body of Knowledge Guide (BABOK). След нейното публикуване бе даден период от четири месеца на започналите своята сертификация по версия 1.6 да завършат процеса, преди изпита да бъде обновен в съответствие с новия стандарт.

Новата версия на стандарта бе представена от Петър Лефтеров, вицепрезидент по образованието към българската секция на Международният институт по бизнес анализ, на среща-семинар, организирана съвместно с Технологика ЕООД.

Събитието се проведе на 23 юли 2009 г. в сградата на Факултета по Математика и Информатика към СУ „Св. Климент Охридски” и събра повече от сто експерти в областта на бизнес анализа. На срещата бе разгледана темата за използване на методологията АРИС за моделиране на бизнес процеси, изнесена от Борис Борчев, мениджър „Управление на бизнес процеси и проекти” в Технологика. Софтуерният специалист Георги Георгиев представи и опита на фирмата в управлението на софтуерни изисквания в рамките на целия жизнен цикъл на софтуерен проект.

Костадин Купенов, президент на българската секция на IIBA, съобщи че българската секция ще продължи практиката за редовни срещи-семинари в сферата на бизнес анализа и ще партнира с български организации и ИТ компании по инициативи, свързани с развитието на професията.

За повече информация посетете сайта на Българската секция на IIBA.

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Внимавайте с изискванията на клиента!

Майк Рам — Thu, 14 May 2009 13:42:14 +0000

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

Това, на което попаднах, обаче, направо ме изуми. Graig Brown от блога Better Projects представи една статистика от доклада Chaos на Standish Group от 2002 г., в която се вижда, че цели 45% от изискванията, които клиентът е включил в проекта и са били реализирани, в крайна сметка въобще не се ползват. (Цъкнете върху картинката за по-голямо изображение.)

Като добавим и 19-те процента на много рядко използвани изисквания, положението придобива трагични размери. На практика, едва 20% от изискванията на клиента влизат в активна употреба, което означава, че огромно количество труд и енергия на проектиния екип са отишли на вятъра.

Какъв е изводът?

Изводът е, че трябва много по сериозно да се акцентира върху бизнес анализа. Да се проучат по-добре нуждите и навиците на потребителя и да се отсеят ненужните и неважни изисквания.

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

Така че – внимавайте с изискванията! Анализирайте ги детайлно и ги обсъдете неколкократно с възложителя, преди да ги включите в заданието. Иначе, в края на проекта ще бъдете затрупани с работа, клиентът ще недоволства, че закъснявате и няма да иска да си плати, а в крайна сметка, дори няма да ползва всички глезотии, които си е поискал.

Трябва да бъдем малко по-критични към техните изисквания. Това, в крайна сметка е за доброто и на двете страни.

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Приоритизация на изискванията по метода MoSCoW

Майк Рам — Wed, 04 Feb 2009 05:10:25 +0000

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

Най-добре е това разпределение да бъде направено в самото начало и методът MoSCoW е един от най-простите, но за сметка на това най-ефективни подходи.

Той възниква за пръв път в методологията DSDM (Dynamic Software Development Method) – един от първите “гъвкави” подходи, но е приложим във всеки един проект, независимо от избраната управленска методология. “Московският метод” (двете “о”-та са поставени за благозвучие и така се е получило съвпадението с името на руската столица) е прост начин за категоризиране на изискванията по важност, за да може на всички участници в проекта да бъде ясно кое е важно за клиента и кое – не.

Съкращението MoSCoW означава:

Must have (задължително трябва да го има)
Should have (би трябвало да го има)
Could have (добре би било да го има)
Won’t have (няма да го има)

Какво означава това в детайли?

Must have. Това са изисквания и функционалности, без които основната цел на проекта не би могла да бъде постигната. Те са гръбнакът на системата, абсолютният минимум, за да има проекта някакъв смисъл.
Should have. Тези изисквания не са критични за съществуването на продукта, но са изключително важни и от голямо значение за клиента.
Could have. Това са изисквания, които е добре да ги има в системата, и биха могли да бъдат реализирани, ако не изискват някакви особени усилия. Но те са и първите, които ще бъдат отхвърлени от обхвата на проекта, ако се появи опасност от изпускане на сроковете.
Won’t have. Тези изисквания са категорично извън обхвата на текущия проект и дори не влизат в плана. Те се поддържат в списъка на изискванията, за да могат да бъдат реализирани евентуално в някоя от следващите версии на продукта.

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

Много клиенти се изкушават да декларират всичките си изисквания като абсолютно задължителни (Must Have), но това почти винаги обрича проекта ако не на провал, то на изключително мъчително изкарване. Затова още в самото начало на проекта, екипът по бизнес анализ и проектният мениджър трябва да извършат това приоритизиране и да получат неговото потвърждение и от клиента.

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

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Българската секция на Международния институт по бизнес анализ е вече факт

Майк Рам — Mon, 02 Feb 2009 14:40:58 +0000

Щастлив съм да обявя, че българските бизнес аналитици вече се сдобиха със своя собствена професионална общност. На 27.01.2009 г. беше проведено учредително събрание на българската секция на Международния институт по бизнес анализ. Учредителният протокол бе подписан от 19 члена на института (на снимката горе).

Международният институт по бизнес анализ (IIBA) е световна организация на професионалисти, които работят за установяването и поддържането на общоприети стандарти и добри практики в областта на бизнес анализа. Българската секция бе създадена от желанието на родните специалисти по бизнес анализ да се обединят в професионална общност, чрез която да подпомогнат развитието, споделянето и разпространението на знания и идеи, както и утвърждаването на бизнес анализа като значима и престижна експертна дейност в България.

Щастлив съм и съм горд от факта, че бях един от хората, спомогнали за създаването на тази организация. На снимката по-горе виждате петимата инициатори за създаване на българската секция на IIBA – Петър Лефтеров, Милена Комитска, Костадин Купенов, Милена Милева и моя милост.

На учредителното събрание бе избран и Управителен съвет на секцията – нейното официалното управително тяло. През следващите две години тя ще се ръководи от Костадин Купенов – ръководител на сектор «Бизнес анализи» в Мобилтел. Останалите членове на ръководния орган на секцията са: Петър Лефтеров, Андрей Русков, Ирина Василева и Веселин Политов.

Дейността на секцията предвижда организиране на курсове и семинари, и подпомагане по всякакъв начин на професионалната работа на бизнес аналитиците в България. Секцията има официален сайт, който в момента е още в процес на разработка, но скоро в него ще се появи актуална информация за дейността на секцията и предстоящите събития. Има създадена и мейл група на секцията, в която се публикуват обяви и съобщения и се водят дискусии.

Разбира се, блогът PM Stories е трибуна на всичко интересно, което се случва в света на бизнес анализа и аз ще продължавам да публикувам статии и новини свързани с тази тема.

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Кои са най-важните качества на добрия бизнес аналитик?

Майк Рам — Tue, 20 Jan 2009 11:36:23 +0000

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

Наскоро имах една среща с мениджър, който търсеше кадърни бизнес аналитици и това ме провокира да се замисля какви качества трябва да притежава един такъв човек, за да бъде наистина добър в работата си.

Ето няколко предложения, без да са подредени специално:

Способност за абстрактно мислене
Умение да разпознава модели в действията на хората от бизнеса и във формулираните изисквания
Умение да подрежда и категоризира логически изискванията
Способност да генерира идеи и решения
Умение да събира знания наблюдавайки дейностите в бизнеса
Усет за детайлите – т. е. да умее да търси и да формулира точното ниво на детайли в бизнес нформацията
Умение да общува с клиента и с техническия екип на техния език и да служи за мост между двата свята.
Да може да разбере организационната култура на изследваното предприятие и какво влияние оказва тя върху работните процеси и комуникацията
Умение да приоритизира изискванията по важност
Умение за водене на преговори
Интерес към изследване на нови области от живота и бизнеса

Може би изпускам нещо. Разчитам на вашите коментари за доуточняване на този списък. По-важният въпрос, обаче, е: откъде да намерим такива хора, които да притежават всички тези качества?

Аз си мисля, че като добавим изискването за сериозна техническа грамотност, задачата става доста трудна. Дали трябва да търсим “перфектния” бизнес аналитик, който отговаря на всички условия, или е по-добре да намерим някой, който само на някои от тях, а в последствие да го научим на останалото. Само че тук отново възниква въпрос: кой ще го научи? Имаме ли такива хора в нашата фирма, които да могат да “отглеждат” подобни специалисти, и дали можем да си позволим този лукс?

Както винаги, въпросите са повече от отговорите. Очаквам и вашето мнение.

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Управление на сложни изисквания в един “agile” проект

Майк Рам — Wed, 10 Dec 2008 05:10:29 +0000

Светът е сложен и това се отразява в сложни изисквания към всяка система, която трябва да го обслужва, независимо от прадигмата.

Това казва Scott W. Ambler в статия, публикувана в Dr. Dobb’s Portal. И още:

“Гъвкавите” методологии като Scrum и Extreme Programming (XP) ни показаха как можем значително да подобрим работата си, но много хора изпаднаха в другата крайност и изхвърлиха бебето на управлението на изискванията заедно с мръсната вода на бюрокрацията, вярвайки, че всичко може да се реши с прости методи. За щастие, има решение, което се справя с проблемите на сложните системи и то може да бъде реализирано напълно в стила на “Agile” методологиите, без да се налага връщане към традиционните тежки практики на писане на тонове (ненужна) документация.

Методът Scrum популяризира идеята да се управляват изискванията като списък от малки функционални единици, описани в приоритизиран стек, наречен “product backlog”. Идеята е, че в началото на всяка итерация (спринт) се изваждат онези изисквания, които трябва и могат да се имплементират в рамките на тази итерация. И всичко щеше да е прекрасно, ако в действителност беше толкова лесно.

Софтуерните екипи, включително и гъвкавите, имплементират не само нови функционални изисквания по време на една итерация, но също така поправят дефекти или изпълняват други, нефункционални задачи. Затова се налага едно допълнение към стратегията на Scrum за “product backlog”. Той се превръща в стек от работни задачи, които могат да бъдат: функционално изискване, бъг или друга работа, като ревю на работата на колега, обучение или инсталация на оборудване.

Статията е много интересна и показва пътя, по който могат да се развиват гъвкавите подходи, за да бъдат приложими и в разработката на по-сложни и обемни системи. От друга страна е и много полезна за почитателите на “класическите” методи, показвайки им начин, по който биха могли значително да облекчат работата си по анализа на изискванията и да опростят комуникацията между бизнес анализаторите, разработчиците и клиента.

Прочетете я!

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Ползата от бизнес анализа

Майк Рам — Tue, 02 Dec 2008 09:22:44 +0000

Бизнес анализът е като проджект мениджмънта – важна, но незабележима дейност, когато е свършена добре. Забелязва се само, ако има проблеми, защото тогава проблемите са големи.

Guy Beauchamp е написал чудесна статия, посветена на смисъла и ползата от бизнес анализа в един проект.

Добрият бизнес анализ, казва той, гарантира, че проектът реализира правилното решение и точно поради това, че е правилното решение, никой не забелязва колко пари, време и усилия са били спестени благодарение на точния анализ.

Прочетете я – има много стойностни идеи и хубави илюстрации.

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Кой познава бизнес процеса?

Петър Лефтеров — Wed, 22 Oct 2008 04:20:51 +0000

Днес прочетох статията „Elevating the Role of the Business Analyst” на Дейвид Хейт, публикувана в RQNG (изисква регистрация).
Една от тезите вътре ми направи голямо впечатление – а именно негово наблюдение, че бизнесът постепенно губи актуална информация за детайлните правила на своята работа и разчита на ИТ отделите да ги поддържат.

Опитвайки се да формулира изисквания за промени по системите, на бизнеса му става все по-трудно да ги дефинира добре, тъй като не знае каква е настоящата ситуация. Това твърдение напълно съвпада с действителността, която виждам.

Когато събирам детайлна информация за настоящия бизнес процес, невинаги намирам такава при съответните представители на бизнеса. Съответно, налага се да търся тази информация в структурите именно на ИТ, на места, където тя по принцип не би трябвало да се намира.

Бизнесът, от своя страна, не изглежда притеснен от тази тенденция, като дори открито се обръща към мен да проверя в рамките на ИТ какви бизнес правила в момента са заложени в системите, за да преценят как искат да ги променят. Маркетингът иска точна информация какви продукти продава компанията, а продажбите искат точна информация при какви условия даден продукт може да бъде продаван в момента и т.н. Разбира се, те имат най-важната част от тази информация, нужна им ежедневно, но недостатъчно пълна и централизирана за да се планира цялостна промяна.

Какви са вашите наблюдения? Можете ли да потвърдите тази тенденция?

Ето още няколко въпроса, по които бих искал да узная вашето мнение:

Ако сте ИТ специалист, случва ли ви се да знаете повече за бизнес процеса от отговорните за него?
Ако сте представител на бизнеса и утре ИТ отдела бъде изцяло заменен, мислите ли, че можете да формулирате детайлно обяснение към новите специалисти как работите в момента и как искате това да се промени?
Смятате ли, че отлива на знание за процесите от бизнес специалистите към ИТ представлява риск за организацията?

Гласувайте за тази статия в Svejo.net: Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се за съдържанието му чрез RSS feed или по имейл.