Препоръчано четиво: Workflow, Scrum, честност и продуктивност
Малко позабравих тази рубрика, но се понатрупаха интересни материали, които са достатъчно големи по обем, за да не мога да ги разказвам всеки поотделно. Поради това ви ги предлагам за самостоятелно четене със съвсем кратък анонс.
Steve McConnell ни информира от страниците на своя блог, че има публикувани нови white papers на сайта на неговата фирма – Construx. МакКонъл е известен като критик на модерните напоследък “гъвкави методологии”, затова мисля, че документите, посветени на успешното внедряване на Scrum и оптимизирането на гъвкавите процеси, биха били особено интересни за вас. Разбира се, обновената версия на неговия фундаментален труд за класическите грешки, е просто задължително четиво. Всички white papers можете да намерите на адрес: www.construx.com/whitepapers.
Mike Griffiths пък е публикувал в своя блог един много детайлен анализ на измеренията на високата продуктивност. Той твърди, че размерностите са три:
- Талант (владеенето на някое полезно умение)
- Страст (мотивацията да свършиш дадена работа)
- Възможност (наличие на време, което да посветиш на нея)
Статията е дълга, но е интересна и е обогатена с обилно количество тримерни (!) графики, които поясняват мисълта на автора.
Категории: Бизнес анализ, Препоръчано четиво, Управление на проекти | Няма коментари
Ежедневието ми на бизнес аналитик
Прави ми впечатление че когато говоря за бизнес анализ хората често имат доста различна представа какво означава това. И колкото по-дълбоко изпадам в описание какво е бизнес анализ, толкова по-недоверчиво ме гледат. 
Затова реших да напиша нещата които реално върша в рамките на работния ден, като се надявам да помогне на заинтересованите да си изградят представа. При други аналитици е различно, но обикновено има някакво сходство, за да е дисциплината една и съща.
1. Документиране – най-известната и обикновено най-досадната дейност на бизнес аналитиците. Проблемът, който се налага да избегна тук, е от 5 души екип по проекта и 3 поръчителя да има 15 различни представи какво точно трябва да се свърши. Софтуерната спецификация е средство за това, но не единствено и често недостатъчно надеждно.
2. Описание на процеси – не се занимавам с описание на процесите на организацията. Описанието на процеси в моя случай е в много по-ограничен обхват – когато променим системите неизбежно някой ще промени начина си на работа. Това, което трябва да опиша, е как се вършат нещата сега и как ще се вършат след промяната на системите. Целта е да илюстрирам на програмистите каква всъщност е целта на разработката, която правят. Също така да илюстрирам в детайли на “бизнеса” какво се опитват да постигнат.
Категории: Бизнес анализ, Гост-автори | 4 коментара
Бизнес изискванията са пълни глупости!
Това твърди Steve Yegge в своя провокативен пост, озаглавен по този начин – Business Requirements are Bullshit! Статията е дълга и изпъстрена с много примери от различни сфери на бизнеса, но основната идея е проста и страшна:
Не можете да извлечете бизнес изискванията за един продукт. Каквито и методи да ползвате, на края клиентът пак няма да е доволен.
Това си звучи направо страшно. За какво се пънат толкова много специалисти да правят софтуер, щом така или иначе клиентът няма да го хареса? Разбира се, тук целта на автора е просто да ни провокира и да размърдаме мозъците си. Затова той предлага и своето решение на този проблем, което, естествено, отново е доста радикално:
За да направиш успешен продукт, трябва да го правиш за себе си. Тогава няма да има нужда да “събираш изисквания”, защото изискванията са в главата ти. Когато правиш нещо за себе си, ти го правиш с желание, разбиране и страст и то върши перфектна работа. Който има специални изисквания, да си направи продукта сам!
Статията е забавна и сериозна едновременно. Едва ли всички хора могат да станат програмисти и да си програмират сами всички бизнес приложения, но пък проблемите, които авторът поставя, са си сериозни и до ден днешен никой не е успял да измисли решение, което да ги отстрани напълно. Всичко, до което е достигнала професията на софтуерния разработчик, е само едно малко приближение до идеалния вариант и търсенето все още продължава.
Прочетете статията тук. След нея има и огромно количество коментари, някои от които също заслужават по-голямо внимание.
Гласувайте за тази статия в Svejo.net:
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се за съдържанието му чрез RSS feed или по имейл.
Категории: Бизнес анализ, Разработка на софтуер | 2 коментара
Що е бизнес анализ?
Google Knol започна бързо да набира скорост и макар на мен лично да ми е малко странен като визуален интерфейс, там могат вече да се намерят доста полезни материали.
Една хубава статия, на която попаднах, е написана от Kevin Brennan (вицепрезидент, Body of Knowledge, IIBA) и в нея авторът доста изчерпателно е посочил същността на професията, ролите, които един специалист по бизнес анализ може да изпълнява в един проект или в една организация, необходимите знания и умения за пълноценно реализиране в професията, както и различни пътища, по които може да се развие кариерата на един бизнес анализатор.
Авторът цитира официалната дефиниция на дисциплината, дадена от Международния институт по бизнес анализ (IIBA):
Бизнес анализът е съвкупност от задачи и техники, използвани за общуване между различните заинтересовани лица (stakeholders), за да бъдат разбрани структурата, политиките и операциите на една организация, и за да се предложат решения, които да помогнат на организацията да постигне своите цели.
и по-нататък тълкува тази дефиниция.
Срещата на бизнес анализаторите – какво се случи и какво следва
Представям ви открито писмо на Милена Комитска – организатор на срещата на бизнес анализаторите за учредяване на българската секция на Международния институт по бизнес анализ – до участниците в нея. Писмото дава резюме на събитието и обяснява какви са следващите стъпки за официалното учредяване на българската секция на IIBA.
Срещата на 26-ти юни с цел представяне на предложението за учредяване на българска секция на Международния институт по бизнес анализ вече е факт. Обратната връзка, която получихме още на място, ни дава основание да я определим като едно успешно събитие, за което бихме искали още веднъж да благодарим на всички за проявената активност и интерес.
Повече за това как протече самата среща (както и снимки) са налични на сайта http://sofiabg.theiiba.org/, който ще продължим да поддържаме и развиваме с учредяването и развитието на секцията.
Категории: Бизнес анализ | Няма коментари
Първа среща на бизнес анализаторите в България
На 26.06.2008г. (четвъртък), от 18.30ч., в Илиев център – София, ще се проведе първата среща на бизнес анализаторите в България, на която ще се представи инициативата за формирането на българска секция на IIBA – Международния институт по бизнес анализ.
Инициативата за създаване на българска секция на IIBA е произлезе от шепа ентусиасти и е мотивирана от желанието им бизнес анализаторите в България да се обединят в професионална общност, която да помага за споделянето на знания и професионален опит, както и за утвърждаването на бизнес анализа като значима и престижна експертна дейност в България.
Щастлив съм, че бях поканен да се включа в организацията на това мероприятие, защото съм дългогодишен радетел за признаването и утвърждаването на професията на бизнес анализатора у нас, както и за създаването на професионални общности на хората, работещи в областта на софтуерното производство.
Ще се радвам да се срещнем с всички, които пряко или косвено са свързани с професията бизнес анализа и които споделят идеята за създаване на такава професионална общност у нас.
Българската секция на IIBA все още не е учредена, но вече си има собствен сайт (http://sofiabg.theiiba.org/), където можете да следите за актуална информация, а оттук можете да изтеглите официалната покана за срещата.
Заповядайте!
Категории: Бизнес анализ | 1 коментар
Първи гост-автор в PM Stories – Петър Лефтеров
Миналата седмица на страниците на PM Stories се появи първата статия, написана от гост-автор – Трябва ли анализът да е “тромав”? от Петър Лефтеров.
Петър е бивш програмист и състезател по информатика, завършил Факултета по Математика и Информатика към СУ „Св. Климент Охридски”. По-рано се е занимавал с разработка на приложения с ASP .NET и Delfi. От две години се е фокусирал основно върху бизнес анализ на софтуерни проекти. Сегашната му позиция е на старши бизнес аналитик в IT отдела на Българска Телекомуникационна Компания.
През свободното си време води лекции по бизнес анализ и софтуерни технологии в мениджмънта в Стопански Факултет на СУ. Активен участник е в Движение Български Великден, на което е и действащ председател.
С първата статия на Петър слагаме началото на една нова фаза в развитието на блога, с което вярвам, че той ще стане по-богат на информация и по-интересен за читателите, интересуващи се от проблемите на софтуерното производство и управлението на проекти.
Приканвам всеки, който има интереси в тази област и който смята, че има какво да сподели със своите колеги, да заповяда на страниците на PM Stories и да стане един от нашите автори. Така заедно ще създадем един център, който да фокусира интересите на професионалната общност в България. Заповядайте! Свържете се с мен чрез страницата за контакти и аз ще ви отговоря незабавно!
Гласувайте за тази статия в Svejo.net:
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл.
Трябва ли анализът да е “тромав”?
Търсейки интересна тема за бизнес анализ попаднах на дискусия по тема, която често съм обсъждал и аз с колеги. В своята статия Do we need Agile Business Analysys? Крейг Браун задава въпроса дали Agile не прави бизнес аналитика като позиция излишен, което провокира добър отговор от професионалист съчетаващ двете.
Според мен отговорът зависи от това как възприемаме бизнес аналитика като задължения и позиция. И с каква цел организацията е намерила такава позиция за нужна.
Много организации и ИТ фирми приемат бизнес аналитика като позиция, която придава тежест. Независимо дали си ИТ фирма бореща се за проекти или ИТ мениджър, желаещ да покаже професионализъм, винаги е от полза да имаш хубав, подреден бизнес анализ, завършващ с красив, голям документ с много диаграми, носещ гръмкото название Business Requirements Specification. Това показва че си сериозен. В тази ситуация бизнес анализа се налага да е бюрократичен, бавен и негъвкав, по простата причина, че той е създаден с тази мисъл и с тази цел.
Не мога да отрека, че за много колеги тази идея е привлекателна и дори признавам, че в много случаи именно бизнес аналитиците се явяват основен адвокат на бюрокрацията. Това обаче е черта на някои организации и хора, прилагащи бизнес анализ – не на самата дисциплина.
Техники за събиране на изисквания
Наскоро ми попадна една статия, озаглавена 10 техники за събиране на изисквания. Tom Mochal е много авторитетен експерт в областта на проджект мениджмънта и аз много ценя неговото мнение, но някои от нещата, описани в тази статия ми изглеждат съвсем тривиални, като обсъждане с един човек, обсъждане с двама човека и обсъждане с 3-4 човека.
По-интересно за мен беше това, че той посочва някои техники, които ми се струва, че не са толкова популярни, а според мен са изключително ефективни. Затова реших да се спра на тях и ги разгледам по-детайлно.
Задължителни въпроси при формулиране на изискванията към един софтуерен продукт
Един от ключовите проблеми при разработването на един софтуерен продукт са непълните или неясни изисквания, зададени от клиента. Софтуерните разработчици са хора с много силно развито аналитично и детайлно мислене и имат нужда от точно и ясно обяснение какво трябва да се направи при всяка една възможна ситуация. Или, казано на програмистки език – какво трябва да се случи при всяко едно разклонение на if оператора.
Клиентите пък, са хора, които в общия случай не притежават това мислене и често пропускат да опишат ситуации и варианти, които за разработчиците са важни, а за тях са нещо тривиално и подразбиращо се. Добро решение в този случай е намесата на бизнес анализатора, който умее да говори и двата езика и знае как да зададе на клиента онези въпроси, които вълнуват програмистите, но на неговия език.
Така във функционалната спецификация влизат не само нещата, които клиентът изрично е поискал и обяснил, но и нещата, които са важни за разработчиците от техническа гледна точка, и без които продуктът не може да работи нормално.
-
RSS абонамент
Препоръчвам ви
Връзки
Авторски права
-
Admin
