Pull to refresh

Гибие методологии разработки в проектно-конструкторских работах

В этой статье пойдет речь о подходах к планированию работ проектно-конструкторского отдела при разработке нового продукта.

Классическая схема.


В классической схеме процесс планирования работ и процесс разработки имеют четкие временные границы. Обычно процесс планирования ведется до разработки. По окончании планирования появляется “сетевой график работ” на каждый месяц, по которому начинается процесс разработки изделия проектно-конструкторским отделом. Видов сетевых графиков существует не так много — это в основном PERT и GANTt. Сроки в сетевом графике, как правило, декларативные и ничем не подкреплены, что создает некоторый мнимый простор при выполнении работ в процессе разработки проектно-конструкторским отделом. На самом же деле сроки в сетевом графике согласованы с заказчиком, и исполнитель вынужден соблюдать их, иначе срыв ключевых сроков разработки может грозить закрытием проекта в целом.
image
Разработчиков в классической схеме никто не спрашивает, и руководитель проекта просто спускает сроки выполнения по каждой работе до разработчиков. Со стороны выглядит это так, как будто руководитель проекта раздает всем по своеобразной удочке (инструменту) и говорит: “Ловите пока карася. К концу месяца нужно наловить 2 тонны”. В течение месяца руководитель проекта проводит совещания, на которых ему отчитываются кто, сколько тонн и какого вида рыбы выловил. В конце месяца руководителю проекта спускают новый “уточненный” сетевой график работы, по которому заказчик хочет ловить не карася, а к примеру “рыбу-кабачок”. У “мудрого руководителя проекта” появляется шанс получить себе премию для покупки новой плазмы или нового современного внедорожника. Если ему повезет и будет хоть один, кто поймает “рыбу-кабачок”, тогда он заплатит премию себе и удачливому рыболову, а другим назначит штраф.
Такой режим работы вынуждает руководителя проекта брать часть задач по разработке на себя, а разработчики такого проекта постоянно задерживаются на работе, а иногда им приходится выходить в выходные дни, чтобы успеть в срок разработать геометрическую модель сборочной единицы или детали. Все это, как уже упоминалось мною выше, усугубляется еще и тем, что требования к конечному продукту могут поменяться, и тогда сетевой график корректируется, причём корректировка производится таким образом, чтобы не задеть ключевые сроки в проекте.
В такой схеме вся работа зависит от человеческого фактора, который играет ключевую роль. Человеческий фактор можно свести к минимуму путем введения автоматизированных систем планирования и разработки, что в сущности и делают многие, внедряя у себя на предприятия системы CAD, CAM, CAE, PDM, ERP, CRM, PLM и т.п. Однако базис в виде классической схемы, когда планирование и разработка имеют четкие временные границы остается неизменным. В результате разработчикам приходится поддерживать в актуальном состоянии геометрическую модель изделия и документацию на неё в каждой автоматизированной системе, а также постоянно поддерживать интеграцию систем, что в современных конкурентных условиях IT-рынка весьма проблематично. Заказчику в конечном итоге нужно лишь одно — это готовый продукт или налаженное производство. В классической схеме перечень документации, разрабатываемый исполнителем, всегда будет избыточен, по причине того, что ни у заказчика и ни у исполнителя нет полной уверенности в том, что цель будет достигнута, а значит нужно по максимуму документировать процесс, чтобы выявить на кого “свалить ответственность” за срыв сроков. Даже если конечная цель изначально будет сформулирована, как конкретная (Specific), измеримая (Measurable), достижимая (Attainable), реалистичная (Realistic) и ограниченная во времени (Time-based), в итоге после первого дополнительного требования у исполнителя может пропасть уверенность в достижимости конечной цели, а значит, будет срыв сроков и закрытие проекта.

Как же тогда сделать так чтобы заказчик не менял требования слишком часто, а исполнитель выполнил все требования заказчика в срок?


В классической схеме процессом планирования занимается опытный эксперт в области планирования проектов, который на основе своего опыта определяет перечень задач и их сроки. Я считаю, что всё это можно было бы и не делать опытному эксперту, потому как сроки выполнения задач, а также перечень задач необходимых для выполнения может определить и сама команда. Для этого эксперту со стороны заказчика нужно максимально подробно описать продукт в техническом задании и конечный срок, к которому нужен продукт и всё! Команда же под руководством руководителя проекта может сама провести планирование работ, выявить подводные камни, произвести декомпозицию задач, короче всю ту работу, что выполняет опытнейший эксперт.
“Проблема” состоит в том, что в этом случае каждый член команды знает конечную цель, она прозрачна и в каждый момент времени известно насколько команда далека от неё. “Мудрый руководитель проекта” не сможет включить в эту цель еще и свою мегацель: “покупка современного внедорожника”. Для того чтобы ему 100% успешно достичь своей мегацели ему нужно разделить процессы планирования и разработки, а списки задач выдавать порционно по мере возникновения “проблем”. В этом случае задача руководителя проекта сводится к тому, чтобы максимально отвести внимание команды от конечной цели проекта, и сфокусировать их внимание на решении точно в срок конкретных работ сетевого графика. Другими словами: “завалить команду рутинной работой”.

Схема работы с использованием гибких методологий разработки.


Принципиально иная схема работы — это схема работы с использованием гибких методологий разработки, где главным принципом является:
частые непрерывные поставки продукта ценного для заказчика.

Достичь этого позволяет в первую очередь прозрачность процесса планирования, когда каждый член команды знает конечную цель и участвует в формировании пула задач на следующие 1-4 недели, по окончании которых заказчик увидит первую версию реализации продукта с новой функциональностью. Обязанность руководителя проекта получить одобрение у заказчика или просто поставить его в известность по версии продукта с новой функциональностью, которая будет готова после завершения итерации. Все дополнительные требования, поступающие от заказчика, должны быть учтены при планировании командой пула задач в следующих итерациях.
Для того чтобы не сбиться с пути достижения конечной цели команда каждый день собирается для проведения 15-минутных митингов, на которых каждый член команды отвечает на три вопроса:
1. Что было сделано с предыдущего митинга?
2. Что будет сделано к следующему митингу?
3. Какие есть проблемы?

В случае, когда планирование ведется отдельно от разработки, ответ на второй вопрос дает руководитель проекта, впрочем, как и ответ на третий.
В конце каждой итерации (спринта) команда проводит демонстрацию продукта с новой функциональностью заказчику. После каждой демонстрации команда собирается отдельно от заказчика для проведения ретроспективы. Методик проведения ретроспектив масса, хочется отметить ретроспективу в стиле “PLUS/DELTA”, в которой каждый член команды высказывает 10 положительных моментов (PLUS) и десять моментов, которые заставили команду отклониться (DELTA) от достижения намеченной цели.
В схеме работы с использованием гибких методик разработки автоматизированные системы играют ключевую роль, позволяя получать по окончании итерации продукт с максимально проработанным новым функционалом. После каждой итерации продукт можно отправлять на технологическую проработку в CAE- или CAM- системах с целью дальнейшего запуска производства прототипа продукта для испытаний в условиях максимально приближенных к реальным. Таким образом, после каждой итерации происходит уточнение геометрической модели изделия и наращивание новых функциональных требований.

Сделаем выводы.


Попытки построить процесс разработки по классической схеме с использованием гибких методологий обычно терпят фиаско, и видя это многие руководители проектов в угоду своих “мегацелей” или просто автоматически следуя основополагающему принципу “разделяй и властвуй” отказываются от применения на практике современных знаний в области управления проектами.
Tags:
Hubs:
You can’t comment this publication because its author is not yet a full member of the community. You will be able to contact the author only after he or she has been invited by someone in the community. Until then, author’s username will be hidden by an alias.