|
 Хотя существует столько техник управления проектами, сколько и руководителей, существуют также две известные методологии производственного цикла, которые до сих пор часто обсуждаются в кругах руководителей проектов - гибкая (Agile) и водопадная (Waterfall) методологии. Развиваясь в своей сфере деятельности, я частенько изобретал некоторые аспекты успешного проекта. В последнее время, чтобы справиться с необычайно усложненными нуждами со стороны клиентов, я пришел к открытию "мощного" процесса управления проектом, который улучшит не только способ предоставления продукта, но и качество самого продукта по его выполнению. Я предполагал, что существует способ объединить лучшие качества разработки по водопадной схеме с принципами гибкой разработки, которые делают ее исключительной.
Водопадная модель заключается в структурировании, управлении и продвижении разрабатываемого продукта в в пределах ограниченных циклов проекта. Такой подход пригоден в случае, когда у вас есть доступ к бесконечному количеству ресурсов и когда определенное время назначено отдельным ступеням каждого этапа проекта. Гибкая модель отличается тем , что дополнительные действия и время даются команде разработчиков для того, чтобы они повторно применили цикл разработки несколько раз до того момента, когда определенный уровень удовлетворенности будет достигнут. Такой подход нелегко реализовать в случае, если вы делите ресурсы при работе, или же когда у вас нет возможности изменить бюджет или сдвинуть дату выпуска продукта. Важно понимать то, что мои описания двух методов довольно-таки просты и лишь освещают основные различия - для данной статьи стоить отметить именно их. Я советую всем читателям исследовать более детально каждый метод. У каждой из методологий есть свои преимущества, при этом они часто считаются взаимоисключающими друг друга. Но все же можно поспорить и сказать, что некоторые элементы обоих методов могут быть объединены в один единственный процесс для получения лучших результатов. Имея это в виду, я предложил немного переработанный процесс своей команде разработчиков - в нем итерации могут быть приспособлены под нужды, но при этом график предусматривает время и положение в процессе. Для того, чтобы данный подход можно было бы применять, усилия множества руководителей отделов (к примеру, отделы по работе с информацией, дизайном интерфейса и технической разработкой) должны быть произведены одновременно, тем самым команда разработчиков сможет предоставить комплектующие в качестве единого элемента. Таким образом предложения каждого участника будут отображать итерации, которые обычно происходят в виде передачи комплектующего продукта из одного отдела в другой. В итоге вы получаете более контролируемый цикл разработки, где итерации все же могут быть приспособлены. По-моему, качество комплектующих будет выше в случае, если компетентность каждого руководителя может быть объединена в единый выходной результат. Такой стиль сотрудничества также выльется в большую степень понимания практической сферы в среде команды - это создаст долгосрочную совместную деятельность, которая поможет индивидууму учитывать различные точки зрения, даже когда ему приходится работать в одиночку. Такой подход может показаться небольшим отклонением от стандартной процедуры, но факт того, что эксперты в различных сферах соберутся и выработают один элемент вместе, говорит о том, что способ мышления будет значительно изменен. Этот метод сдвинет традиционные агентства подальше от стандартного цикла разработки, и направит их в сторону более продвинутого, коллективного сотрудничества. Поскольку совершенствование теперь движется в сторону простоты использования, дизайна интерфейса и технической функциональности, то такой стиль разработки будет вскоре более востребован. Gina Lijoi
|
