Най-добрият project management процес
Glen Alleman от блога Herding Cats ни дава храна за размисъл, дефинирайки критерии, по които да изберем процеса и методологията, с които да управляваме своите проекти. Независимо дали ползвате най-строгите методи на Министерството на отбраната или управлявате проекта си “гледайки на боб”, казва Глен, вашата методология трябва да може да даде смислен отговор на следните два въпроса:
- Колко дълго ще чакате, преди да разберете, че сте закъснели, надхвърлили бюджета или извън техническата спецификация?
- Какво ще направите, за да се върнете в състояние, приемливо за всички участници?
Ако процесът, който следвате, или врачуването с карти или боб не могат да дадат смислен и измерим отговор на тези въпроси, значи в действителност въобще не управлявате проекта.
Доста радикално, но пък изключително практично твърдение, с което не мога да не се съглася. А вие как мислите?
Гласувайте за тази статия в Svejo.net:
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл.
Категории: Управление на проекти | 1 коментар
Предимства и недостатъци на малкия екип
Във връзка с темата за размера на екипа, попаднах на един интересен пост в PM Hut, в който авторът под формата на интервю със себе си (малко шизофренично, но все пак интересно) представя своите съображения относно предимствата и недостатъците на един малък екип пред по-голям такъв.
Преди всичко, много е важно да се разбере, че малкият екип не е просто количествено различен от големия, той е и качествено различен. Авторът прави едно доста добро сравнение на малкия екип с джаз бенд, а на големия – със симфоничен оркестър. Джаз бендът не е малък оркестър, който иска да порасне – той просто е друга музикална структура.
Ако се опитате да дирижирате джаз квартет като симфоничен оркестър, ще получите лош джаз. Оставете филхармонията да импровизира като джем сешън и ще получите хаос.
Не, че малкият бенд не свири по правилата – просто ги интерпретира по различен начин. Изводът в проектната организация е аналогичен – и малкият, и големият екип трябва да се управляват по някакъв процес, но те са различни в двата случая. Както се казва по американски – one size doesn’t fit all.
Категории: Работа в екип, Разработка на софтуер, Управление на проекти | Няма коментари
Ако “Властелинът на пръстените” беше проект…
… кой щеше да е проджект мениджъра?
Този въпрос разглежда Diane Ellis в блога PM Hut и той звучи съвсем разумно. Приключението, което предприемат главните герои има всички характеристики на един проект:
- Имат ясна цел и задачи
- Имат екип от хора (и не само), които имат ясно изразени (макар и неизказани) роли
- Всички членове на екипа трябва да работят заедно, за да постигнат набелязаната цел
- Има ясно определен краен срок, в рамките на който целта трябва да бъде постигната
ОК, имаме проект, но кой е мениджърът? Преди да решим кой е шефа на проекта, авторката ни припомня какви са неговите основните задължения:
- Носи изключителната отговорност за успеха или провала на проекта
- Изготвя план и бюджет на проекта
- Осигурява ефективни ресурси за проекта
- Следи за изпълнението на плана и бюджета
- Управлява качеството на работата, рисковете и проблемите
- Управлява ежедневните задачи
- Комуникира статуса на проекта с основните заинтересовани лица (stakeholders)
Категории: Работа в екип, Управление на проекти, Хумор | 3 коментара
Най-добрия начин да мотивирате своя екип
Bas de Baar постави този въпрос в своя блог Project Shrink и помоли своите читатели да предложат своите отговори. Аз винаги съм смятал, че мотивираният екип е най-важният фактор за успеха на един проект, но никога не съм имал “готова рецепта” за това как да мотивираш един екип. Всъщност знам много неща, които могат да подкопаят мотивацията на екипа и доверието във вас, много класически грешки, които можете да направите, но наистина нямах отговор на този въпрос досега и се наложи доста да помисля над него преди пред мен да изплува отговор, който да мога да споделя и с вас.
Дайте възможност на хората от вашия екип да бъдат креативни!
Категории: Лидерство, Работа в екип | 5 коментара
Числата на Дънбар и размера на софтуерния екип
R. I. M. Dunbar е бил антрополог в University College of London и на базата на изследвания на хора и примати е стигнал до извода, че максималния брой контакти, които човек може да поддържа активно в съзнанието си, е приблизително 150. Т.е. всяка една група може да бъде витална и да оцелее, ако има по-малко от 150 члена. Историята показва, че по-големите групи започват да се делят на по-малки щом броят на членовете им започне да надвишава това число. Оттук числото 150 започва да се нарича “числото на Дънбар”.
Christopher Allen разказва много обширно в своя блог за теорията на Дънбар и всички последвали изследвания след това. Той отива доста по-далеч в своите разсъждения, разглеждайки ефективността на софтуерните екипи и се опитва и там да намери някаква закономерност между броя на техните членове и ефективността на комуникацията и производителността.
Моят опит показва, че най-малкият размер, при който групата е жизнена, е някъде между 5 и 9 човека.
Категории: Анкети, Работа в екип, Разработка на софтуер | 7 коментара
Как не се прави презентация
В света на информационните технологии се провеждат много конференции, семинари и срещи (както и в другите области от живота, разбира се), в които технически специалисти споделят своите знания и опит. За съжаление, изкуството на презентацията често се подценява и се получават сериозни издънки или просто ужасно скучни лекции.
Ето един пример от една конференция, където презентациите на няколко представители на Microsoft са заснети в едно филмче:
Гласувайте за тази статия в Svejo.net:
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл.
Категории: Курсове и семинари | Няма коментари
Колко служители на Microsoft са необходими, за да се смени една крушка?
Попаднах на една статия от 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 полагаме неимоверни усилия за да не допуснем издаването на недопечен софтуер”, допълва той.
Категории: Разработка на софтуер | 4 коментара
Кой тества вашия продукт? Резултати от анкетата
Оказа се, че тази анкета нещо съм я забравил и стои от много време на сайта, а няма особена активност по нея. Дали въпросът не е интересен или просто който е имал мнение вече го е дал – не знам. Но времето на тази анкета изтече, а имам и други въпроси, които искам да ви задам, затова я затварям и обявявам резултатите.
Въпросът беше: Кой тества вашия продукт? Общо гласувалите в анкетата са 66 човека, като разпределението на отговорите е следното:
- Тестери – членове на проектния екип (36%, 24 гласа)
- Отдел по качеството във фирмата (23%, 15 гласа)
- Програмистите (23%, 15 гласа)
- Клиентът (18%, 12 гласа)
Категории: Анкети, Разработка на софтуер | 1 коментар
-
RSS абонамент
Препоръчвам ви
Връзки
Авторски права
-
Admin
