Оптимизиране на процеса на разработка на софтуерен продукт (Организация на работата)

1. Оптимизиране на процеса на разработка на софтуерен продукт (Организация на работата) Пламен Ивков Игнатов М21425 Софийски Университет 28.05.2004

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

3. Досегашна йерархия • Структурата е плоска – Team Leader-a отговаря за всички member-и и съгласува тяхната работа. • Комуникация всеки с всеки

4. Недостатъци и проблеми на досегашната организация • Неефективно разпределяне на задачите и проектите. Възможност за появата на “много” натоварени и “не”натоварени member-и. • Цялата отговорност по спазване на графика и разработката на продуктите е отговорност само на Team Leader-a • “One man show”е често срещана практика – един човек отговаря за цялостната разработка на приложението – от началния план до внедряването • Възможности за грешки и забавяне на цялостното предаване на работещ проект

5. Недостатъци... (продължение) • Тромава организация при преразпределяне на задачите и проектите. • Липса на отделни екипи и/или хора за внедряване, тестване (QA екипи) и т.н. • При наличие на няколко проекта лесно се объркват приоритетите и степените на завършеност на проекта

6. Нова йерархия

7. Team/Project Leaders • Team Leader – Отговаря за цялостната политика по отношение на разработването и внедряването на софтуерните решения. За “външния свят”извън структурата, това е единствената точка за комуникация относно възлагане на проекти. Има връзка само с project leader-ите, но не и директно с project-member-ите • Project Leader – Ръководител на проекта. Отговаря за цялостната реализация на проекта.В общия случай избират project member-и за всеки нов проект

8. Project Members • Може да са както програмисти, така и QA, хардуерни или комуникационни специалисти • Решават задачите и проблемите, които се поставят от Project Leader-a

9. Отговорности на PL • Разбиване на проекта на по-малки задачи, които се разпределят между project member-ите. • Определяне на тежестта на съответните задачи • “Подходящ” избор на PM • Project Leader-ите следят за изпълнението на проекта и дали има забавяне от предварително зададените срокове за изпълнение • Елиминира се възможността за “свръх” натоварени екипи и “почиващи”. В някакъв смисъл се осъществява вътрешен Load Balancing • Взимат решения за промяна на заданието и начина на работа в зависимост от конкретната специфика

10. Отговорности на PM • Вечният проблем – правилна преценка на възможностите и трудността на задачата • Вътрешна комуникация в екипа • Това може да се осъществи, чрез web-базирана система за управление на съвместната работа (пример: GNU dotProject) • Стандартните начини – e-mail или offline

11. Структура • Динамична – PM може да преминават от един екип в друг, както и да учавствуват в повече от един екип (примерно за обучение) • Един член на екипа, може да е PM по един проект и да е PL по-друг проект.

12. Предимства • Всеки PM комуникира само със своя PL. По този начин се осъществява ефективно управление на проектите • По-удачна система за контрол на сроковете за изпълнение на възложените задачи. • Организация, която може да понесе по-голямо натоварване (брой проекти и т.н) • Ясно определена йерархия – информацията тече отгоре надолу и обратно, но не може да се прескачат нива

13. Примерна ситуация

14. Примерна ситуация (продължение) • След успешното приключване на проекта, всички участници получават премии и пият и/или пеят. 

15. Заключение • При работа на относително малък брой хора в екипа е трудно да се постигне добра вътрешна организация – тук flat подхода е единствено възможния. • При увеличаване броя на хората възниква въпроса за правилната структура и обособяването на отделни под-екипи. Запазването на flat структурата води до проблеми, свързани с ниска ефективност и лошо оползотворяване на налични ресурси.

16. Въпроси? 