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

Много организации и ИТ фирми приемат бизнес аналитика като позиция, която придава тежест. Независимо дали си ИТ фирма бореща се за проекти или ИТ мениджър, желаещ да покаже професионализъм, винаги е от полза да имаш хубав, подреден бизнес анализ, завършващ с красив, голям документ с много диаграми, носещ гръмкото название Business Requirements Specification. Това показва че си сериозен. В тази ситуация бизнес анализа се налага да е бюрократичен, бавен и негъвкав, по простата причина, че той е създаден с тази мисъл и с тази цел.

Не мога да отрека, че за много колеги тази идея е привлекателна и дори признавам, че в много случаи именно бизнес аналитиците се явяват основен адвокат на бюрокрацията. Това обаче е черта на някои организации и хора, прилагащи бизнес анализ – не на самата дисциплина.

(more…)

• Лидер. Има дълбоки технологични познания, както и опит в бизнес областта, която се автоматизира. Може да пише код ако се наложи. Активно участва в код ревюта и обсъжда технически проблеми с екипа.
• Мениджър. Има технически или бизнес произход, но е минал и специализирано обучение в управление на проекти. Познава добре механизмите и средствата на управление на проекти. Не се занимава с технически подробности, но участва в обсъждането на детайли по функционалността.
• Наблюдател. Високо квалифициран и сертифициран проджект мениджър, който е вещ в процедурите и правилата, но въобще не се занимава с производствения процес. Следи изпълнението на плана, но не участва нитов технически, нито във функционални дискусии.

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

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

(more…)

• Колко дълго ще чакате, преди да разберете, че сте закъснели, надхвърлили бюджета или извън техническата спецификация?
• Какво ще направите, за да се върнете в състояние, приемливо за всички участници?

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

Доста радикално, но пък изключително практично твърдение, с което не мога да не се съглася. А вие как мислите?

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

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

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

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

Не, че малкият бенд не свири по правилата - просто ги интерпретира по различен начин. Изводът в проектната организация е аналогичен - и малкият, и големият екип трябва да се управляват по някакъв процес, но те са различни в двата случая. Както се казва по американски - one size doesn’t fit all.

(more…)

… кой щеше да е проджект мениджъра?

Този въпрос разглежда Diane Ellis в блога PM Hut и той звучи съвсем разумно. Приключението, което предприемат главните герои има всички характеристики на един проект:

• Имат ясна цел и задачи
• Имат екип от хора (и не само), които имат ясно изразени (макар и неизказани) роли
• Всички членове на екипа трябва да работят заедно, за да постигнат набелязаната цел
• Има ясно определен краен срок, в рамките на който целта трябва да бъде постигната

ОК, имаме проект, но кой е мениджърът? Преди да решим кой е шефа на проекта, авторката ни припомня какви са неговите основните задължения:

• Носи изключителната отговорност за успеха или провала на проекта
• Изготвя план и бюджет на проекта
• Осигурява ефективни ресурси за проекта
• Следи за изпълнението на плана и бюджета
• Управлява качеството на работата, рисковете и проблемите
• Управлява ежедневните задачи
• Комуникира статуса на проекта с основните заинтересовани лица (stakeholders)

(more…)

Дайте възможност на хората от вашия екип да бъдат креативни!

(more…)

R. I. M. Dunbar е бил антрополог в University College of London и на базата на изследвания на хора и примати е стигнал до извода, че максималния брой контакти, които човек може да поддържа активно в съзнанието си, е приблизително 150. Т.е. всяка една група може да бъде витална и да оцелее, ако има по-малко от 150 члена. Историята показва, че по-големите групи започват да се делят на по-малки щом броят на членовете им започне да надвишава това число. Оттук числото 150 започва да се нарича “числото на Дънбар”.

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

Моят опит показва, че най-малкият размер, при който групата е жизнена, е някъде между 5 и 9 човека.

(more…)

Ето един пример от една конференция, където презентациите на няколко представители на Microsoft са заснети в едно филмче:

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

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

Попаднах на една статия от 2003 година, която досега ми е убягвала почти 5 години. Там проблемът започва с писмо на един потребител, който казва: “Трябва ми метод, който да извиква функцията ChangeLightBulbWindowHandleEx, но такъв няма. Толкова ли е трудно да го добавите? Това едва ли ще отнеме повече от 5 реда код!”

Авторът, Eric Lippert, отговаря: “Да, сигурно програмирането е към 5 реда и най-вероятно ще отнеме не повече от 5 минути, но ние в Microsoft не правим така, защото е непрофесионално“. И поставя въпроса: Колко хора действително са необходими за добавянето на един нов метод (или за смяната на една крушка ), след което дава подробен отговор:

• Един програмист да имплементира метода ChangeLightBulbWindowHandleEx за 5 минути.
• Един program manager да напише спецификацията.
• Един експерт по локализацията да прегледа спецификацията за локализационни проблеми.
• Един експерт по usability да прегледа спецификацията за проблеми по ползваемостта и достъпността (usability and accessibility).
• Поне по един програмист, тестер и ПМ да проучат потенциални слабости по сигурността.
• Един ПМ да добави модел на сигурността към спецификацията.
• Един тестер да напише тест план.
• Един тест лидер да актуализира програмата за тестване.
• Един тестер да напише test cases и да ги добави към нощните автоматични тестове.
• 3-4 тестери да се включат в инцидентното чистене на бъгове.
• Един technical writer да напише документацията.
• Един технически редактор да провери документацията за технически грешки.
• Един граматически редактор да провери документацията за граматически и правописни грешки.
• Един documentation manager да интегрира новата документация в съществуващите текстове, да актуализира таблиците на съдържанието, интекси и т. н.
• 25 преводача да преведат документацията и съобщенията за грешки на всички езици, поддържани от Windows. Мениджърите по преводите живеят в Ирландия (за европейските езици) и Япония (за азиатските езици). И двамата са доста сериозно отместени във времето от Redmond, така че общуването с тях си е доста сериозен логистичен проблем.
• Екип от старши мениджъри да координират действията на всички изброени дотук хора, да пишат чекове и да оправдават разходите пред своите вицепрезиденти.

Всяка една от тези дейност, казва Ерик, не отнема много време, но като ги събереш всичките, се получава един доста сериозен обем от работа, който е невероятно скъп. Но това е положението - няма майтап. “Ние от Microsoft полагаме неимоверни усилия за да не допуснем издаването на недопечен софтуер”, допълва той.

(more…)

Въпросът беше: Кой тества вашия продукт? Общо гласувалите в анкетата са 66 човека, като разпределението на отговорите е следното:

• Тестери - членове на проектния екип (36%, 24 гласа)
• Отдел по качеството във фирмата (23%, 15 гласа)
• Програмистите (23%, 15 гласа)
• Клиентът (18%, 12 гласа)

(more…)