Письмо 06 - Организация работы над проектом

Упрощение администрирования проекта позволяет сделать качественные изменения в организации работ. Действительно, как уже отмечалось в пятом письме, при методе “waterfall” требовалось постоянное административное вмешательство для синхронизации работы различных групп разработчиков. Теперь все группы работают независимо и параллельно, ориентируясь на конечный результат, что позволяет говорить о процессной организации работы. Не существует никаких причин, по которым не следовало бы передавать право принимать проектные решения для любого уровня иерархии системы соответствующей группе разработчиков. Конечно, такая передача потребует от разработчиков большей творческой отдачи, большей квалификации и взаимозаменяемости, но при этом и работа становится более интересной. Таким образом, данный подход стимулирует повышение уровня подготовки и творческой самореализации разработчиков.

Изменения, связанные с развитием проекта, на каждом из уровней обсуждаются и принимаются внутри группы (пожалуй, теперь уже надо говорить – бригады) разработчиков. И задачей администрирования, в таком случае, является только контроль достижения цели проекта и проверка соответствия решений поставленным задачам. Роль руководителя проекта сводится к координации направлений развития проекта. Руководство проектом лучше переложить на координационный совет, в который могут входить войти архитектор системы, руководитель системы качества и руководители групп. Задачей совета является выработка и принятие стратегических проектных решений, согласование глобальных изменений, а также контроль сроков выполнения проекта.

Количество разработчиков в каждой из групп зависит от сложности уровня, на котором она работает. При завершении работ на одном из уровней разработчики могут и должны быть распределены по другим группам. Это одна из важнейших форм ротации, а ротация в любой форме способствует повышению мастерства разработчиков и созданию у них полной картины о создаваемой системе.

Заслуживает внимания и снижение конфликтности в коллективе разработчиков, по сравнению с традиционным методом последовательной разработки, типа “waterfall”. Устранение зависимостей одних групп разработчиков от других, с одной стороны, снижает аритмию работ, а самостоятельность принятия проектных решений группой, с другой стороны, возлагает всю полноту ответственности на группу и исключает перекладывание ответственности на другие группы.