Загальний підхід до оцінки аутсорсингу розробки програмного забезпечення в PNN Soft

Стратегія аутсорсингу ПЗ – Прийняття рішень. Вступ

Стаття написана з метою допомогти спонсорам і менеджерам ІТ-проєктів в ухваленні рішення щодо вибору стратегії аутсорсингу для компанії, відповівши на такі запитання:

• Правильна оцінка витрат і порівняння з внутрішнім розвитком;
• Оцінка ризиків та їх вплив на остаточну ціну;
• Вибір постачальника програмного забезпечення;
• Реорганізація внутрішньої роботи. 

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

Перш ніж братися за будь-яку діяльність аутсорсингу було б добре підготувати власний план реалізації. Будь ласка, забудьте все про зовнішні яскраві пропозиції аутсорсингу від компаній, які протягом одного місяця за 499 доларів нададуть вам пошукову систему «Вбивцю Google». Таким чином, навіть найважливішої ідеї недостатньо: робіть усі можливі дії, такі як мозковий штурм, плануйте роботи та оцінювання зусиль із вашими довіреними партнерами. Підготовка всіх планів базується на доступних або віртуальних ресурсах. Переконую вас у тому, що це не має бути точний остаточний план, розглядайте його як наближений початок, що використовуватиметься для порівняння та оцінки зовнішньої пропозиції.

Тепер у вас є не тільки яскрава ідея про новий мегапроєкт, а й первісна оцінка планованих кроків, ресурсів і дій.

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

Тож можна взяти будь-який проєкт і спробувати заповнити дані в цифрах для внутрішньої розробки, де кожне завдання має супроводжуватися роллю.

Пропоновані ролі:

• Спонсор проєкту, [PS]
• Менеджер проєкту (внутрішній), [PMd]
• Системний архітектор (внутрішній), [SAd]
• Розробник (внутрішній), [Dd]
• Тестувальник (внутрішній), [Td]
• Менеджер проєкту (віддалений), [PMr]
• Системний архітектор (віддалений), [SAr]
• Розробник (віддалений), [Dr]
• Тестувальник (віддалений), [Tr]

У більшості випадків перерахованого вище достатньо для першого оцінювання.