Робочий продукт

Однією з істотних умов для керованості промислового процесу є наявність окремо оформлених результатів роботи – як в остаточному постачанні так і проміжних. Ці окремі результати у складі загальних результатів робіт допомагають ідентифікувати, планувати і оцінювати різні частини результату Проміжні результати допомагають менеджерам різних рівнів відстежувати процес втілення проекту, замовник дістає можливість ознайомитися з результатами задовго до закінчення проекту. Більш того, самі учасники проекту в своїй щоденній роботі отримують простий і ефективний спосіб обміну робочою інформацією – обмін результатами.

Таким результатом є робочий продукт (work product) – будь-який артефакт, проведений в процесі розробки ПО, наприклад, файл або набір файлів, документи, складові частини продукту, сервіси, процеси, специфікації, рахунки і так далі

Рис. 7.1.

Ключова різниця між робочим продуктом і компонентой ПО полягає в тому, що перший необов'язково матеріальний і відчутний (not to be engineered), хоча може бути таким. Нематеріальний робочий продукт – це, як правило, деякий налагоджений процес – промисловий процес виробництва якої-небудь продукції, учбовий процес в університеті (на факультеті, на кафедрі) і так далі

Важливо відзначити, що робочий продукт зовсім не обов'язково є складовою частиною підсумкового постачання. Наприклад, налагоджений процес тестування системи не поставляється замовникові разом з самою системою. Уміння управляти проектами (не тільки в області програмування) багато в чому пов'язане з мистецтвом визначати потрібні робочі продукти, наполягати на їх створенні і в їх термінах вести приймання проміжних етапів роботи, організовувати синхронізацію різних робочих груп і окремих фахівців.

Багато методологій включають опис специфічних робочих продуктів, використовуваних в процесі, – CMMI, MSF, RUP і ін. Наприклад, в MSF це програмний код, діаграми додатків і класів (application diagrams і class diagrams), план ітерацій (iteration plan), модульний тест (unit test) і ін. Для кожного з них точно описаний зміст, відповідальні за розробку, місце в процесі і ін. аспекти.

Остановимся чуть детальнее на промежуточных рабочих продуктах. Компонента ПО, созданная в проекте одним разработчиком и предоставленная для использования другому разработчику, оказывается рабочим продуктом. Ее надо минимально протестрировать, поправить имена интерфейсных классов и методов, быть может, убрать лишнее, не имеющее отношение к функциональности данной компоненты, разделить public и private, и т.д. То есть проделать некоторую дополнительную работу, которую, быть может, разработчик и не стал делать, если бы продолжал использовать компоненту только сам. Объем этих дополнительных работ существенно возрастает, если компонента должна быть представлена для использования в разработке, например, в другой центр разработки (например, иностранным партнерам, что является частой ситуацией в оффшорной разработке). Итак, изготовление хороших промежуточных рабочих продуктов очень важно для успешности проекта, но требует дополнительной работы от их авторов. Работать одному, не предоставляя рабочих продуктов – легче и для многих предпочтительнее. Но работа в команде требует накладных издержек, в том числе и в виде трат на создание промежуточных рабочих продуктов. Конечно, качество этих продуктов и трудозатраты на их изготовление сильно варьируются в зависимости от ситуации, но тут важно понимать сам принцип.

Отже, підсумуємо, що проміжний робочий продукт повинен обов'язково мати ясну мету і конкретних користувачів, щоб мінімізувати накладні витрати на його створення.

Рис. 7.2.