Моделі ціноутворення і типи договорів в аутсорсингу IT послуг

  1. Time and material (T & M)
  2. Fixed price

Останнім часом аутсорсинг послуг зріс з досить простий концепції до складної сукупності різних варіантів і моделей. Визначення вартості таких послуг часом може викликати деякі складності і нерозуміння з боку замовника.

Світова практика виробила в цьому питанні три основні моделі ціноутворення, які ми і розглянемо нижче і зосередимо свою увагу зокрема на IT-сфері, де вони особливо широко використовується.

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

Нижче ми розглянемо кожен варіант, дамо рекомендації по вибору з описом плюсів і мінусів кожного з них.

У західній практиці і у нас останнім часом прийнято розрізняти наступні цінові моделі:

  1. Dedicated Team
  2. Time and material
  3. Fixed Price

Dedicated Team - це бізнес-модель, в якій обидві сторони взаємно погоджуються з робочим навантаженням і вимогам до проекту з зазначенням необхідної кількості часу, а аутсорсингова компанія надає IT-фахівців, що відповідають вимогам замовника, які повністю концентруються на його проектах Dedicated Team - це бізнес-модель, в якій обидві сторони взаємно погоджуються з робочим навантаженням і вимогам до проекту з зазначенням необхідної кількості часу, а аутсорсингова компанія надає IT-фахівців, що відповідають вимогам замовника, які повністю концентруються на його проектах. Замовник має повний управлінський контроль над проектом і командою, а виконавець виконує функцію рекрутера персоналу та адміністративної підтримки.

У цьому варіанті співпраці важко описати заключний етап, оскільки він може варіюватися в залежності від умов конкретного проекту.

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

Слід зазначити, що роль аутсорсера послуг зводиться до мінімуму після формування команди.

Клієнт керує процесом і приймає рішення по розробці проекту самостійно. Аутсорсингова компанія може допомогти йому тільки в певних організаційних питаннях.

Співпраця з даної моделі можна розділити на кілька етапів:

  • Клієнт визначає кількість і набір навичок потенційних співробітників;
  • Виконавець шукає IT-фахівців з відповідними знаннями і кваліфікацією;
  • Розробники збираються в команду і починають роботу;
  • Вони постійно працюють тільки для проекту клієнта, дізнаються його специфіку і бачать загальну ідею кожної окремої задачі;
  • Аутсорсингова компанія стає початковим посередником між новою командою і замовником, але з часом ця команда стає все більш прихильною його проекту і компанії клієнта в цілому. Члени команди стають частиною компанії клієнта, а інші співробітники дотримуються його корпоративної культури, стилю управління і методології проекту. Вони поділяють бачення компанії та дуже зацікавлені в досягненні бізнес-цілей компанії.

Коли слід вибирати цей варіант?

Якщо ви сумніваєтеся, чи підійде вам така модель співпраці з аутсорсером просто дайте відповідь на питання які побачите нижче. Якщо відповіді на них будуть позитивні, то такий спосіб співпраці для вас скоріш за все підійде:

  • Чи збираєтеся ви розробляти складний продукт?
  • Ви хочете особисто керувати процесом розробки?
  • Ви думаєте про розширення бізнесу в майбутньому?
  • Вам потрібна команда, яка працює виключно над вашим проектом?

Вам потрібна команда, яка працює виключно над вашим проектом

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

Переваги даної моделі

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

Але є і мінуси:

  • низька ефективність для короткострокових проектів;
  • дорожче моделі Time & Material і Fixed Price;
  • вибір членів команди може зайняти деякий час і відкласти початок проекту, в той час як під час розробки при використанні моделі Time & Material робота може початися протягом найближчого часу;
  • у виділених членів команди менше можливостей вивчати нові методики поза своєю області в проекті;
  • клієнт повинен відігравати активну роль в спілкуванні і переговорах і інвестувати багато часу в управління.

Time and material (T & M)

Що робити, якщо заздалегідь невідомо всі деталі проекту і неможливо передбачити всі деталі Що робити, якщо заздалегідь невідомо всі деталі проекту і неможливо передбачити всі деталі? Що робити якщо немає повного бачення кінцевого продукту і його особливостей реалізації, і якщо немає можливості розділити його на кілька дрібніших етапів. Тут вам на допомогу прийде модель T & M, яка дозволяє Вам більше контролювати прогрес розвитку і вартість кінцевого продукту.

У деяких випадках цей варіант може бути більш ефективний ніж звичайна модель фіксованої ціни (Fixed Price). Одним з найбільших переваг способу співпраці є приоритезация завдань для проектів розвитку.

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

Як зрозуміти, що вам підходить дана модель? Просто дайте відповіді на наступні питання. Якщо на всі питання ви можете відповісти «так» - то такий варіант співпраці з розробником можна розглядаються як реальний.

Отже:

  • Чи є концепція проекту досить необробленої, щоб точно оцінити всі деталі?
  • Вам потрібна велика гнучкість в процесі розвитку?
  • Ваша ідея пов'язана з новими технологіями, а не з повністю розвиненими ринками?
  • Ви маєте намір забезпечити прямий контроль над проектом і надати своїй команді конкретні матеріали?

Позитивні моменти: Позитивні моменти:

Замовник платить за годину незалежно від тривалості проекту розробки програмного забезпечення. Якщо клієнт хоче розробити будь-які додатковий функціонал, виконавцю платять тільки за час, витрачений його співробітниками на певний набір завдань. Основною перевагою для клієнтів є те, що з використанням моделі «Час і матеріали» їх змінюються вимоги легко впливають і коригують робочий процес виконавця. Гнучкість з моделлю «Час і матеріали» не обмежена. Крім того, використовуючи цю модель клієнт може бути впевнений, що отримує високоякісний і перевірений продукт.

Негативні моменти:

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

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

Для яких проектів підходить даний тип договорів:

  • Коли вимоги не є точними або специфікації не можуть бути чітко визначені;
  • Коли на перших етапах проект все ще є «сирим», і немає достатніх даних для правильної оцінки кінцевої вартості;
  • Коли клієнт має постійний потік завдань або поліпшень, але вони розкидані в часі і не можуть бути передбачені заздалегідь;
  • Коли обсяг проекту невідомий або реалізація поширюється протягом кількох місяців або навіть років;
  • Коли клієнт вимагає високого рівня гнучкості або запитів на зміну, часто з'являються в процесі розробки;
  • Коли клієнт хоче більш прямого контролю над процесом або надає певні ресурси, які можуть впливати на реалізацію проекту;
  • Коли проект пов'язаний з ринками, що розвиваються, новими технологіями або неперевіреними об'єктами.

Рекомендації для замовників Якщо ви хочете застосувати модель Time & Material, то ви повинні бути впевненими в реальності часу - «годин» яке вам виставляє в рахунку виконавець. Оскільки Ви платите тільки за годинник і супроводжуючі витрати, витрачені на проект, вам слід надати зручний і доступний спосіб відстеження і контролю реально витраченого часу. Для цього можна використовувати спеціальне програмне забезпечення - від електронних таблиць до спеціалізованих веб-додатків, які надають всі необхідні дані, відстеження часу і зв'язок для успішного рішення з управління проектами та звітності.

Fixed price

Fixed price

І тепер давайте перейдемо до самої і найефективнішою, на мій погляд, моделі. З назви можна здогадатися, що цей варіант має на увазі сплату фіксованої суми грошей за певний обсяг роботи.

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

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

Основні етапи робіт по цій моделі:

  • Замовник відправляє запит і вимоги до проекту.
  • Виконавець і замовник обговорюють всі деталі.
  • Виконавець відправляє комерційну пропозицію, графік платежів і розклад виконання робіт.
  • Обидві сторони домовляються і погоджуються всі моменти, підписується договір.
  • Виконавець надає повністю реалізоване рішення.
  • Клієнт схвалює проект.

Ключові моменти даного варіанту співпраці:

  • фіксований бюджет
  • Постійний обсяг проекту
  • Встановлений часовий інтервал
  • Можливий компроміс за якістю

Для яких проектів використовуються Для яких проектів використовуються

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

Як зрозуміти, що вам підходить ця модель?

Якщо ви сумніваєтеся, чи вибирати цей варіант просто дайте відповідь на питання нижче і якщо ви можете на них відповісти «так», то це те, що вам потрібно.

  • Чи можна повністю описати функціональність вашого продукту і етапи його реалізації?
  • Чи передбачається, що процес розвитку займе не більше декількох місяців?
  • Чи можете ви довіряти функції управління проектами представнику команди розробників?
  • Чи можна погодитися з умовами огляду робочого процесу?
  • Мала ймовірність того, що вам доведеться вносити будь-які істотні зміни в остаточну версію продукту?

Серед плюсів даної моделі можна виділити:

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

Але є і мінуси, а саме:

  • потрібен час і ресурси для повного і експертного визначення вимог, результатів і критеріїв прийнятності;
  • відсутність контролю над процесом реалізації проекту, участі персоналу і матеріальних витрат;
  • розробники рідко спілкуються безпосередньо з замовниками і не можуть обговорювати кожну проблему, а при використанні Waterfall робиться ще важче внесення змін після затвердження кожної стадії розробки;
  • можливі проблеми з якістю кінцевого продукту, оскільки проект управляється тільки виконавцем;
  • замовник повинен платити окремо за будь-які суттєві відхилення від початкових вимог проекту;
  • низький рівень запам'ятовування знань після реалізації проекту, оскільки команда розробників може розійтися після завершення проекту.

висновки

Яку модель співпраці вибрати вирішувати Вам, все буде залежати в основному від виду проекту та передбачуваності часу і витрат на цей проект. Для короткострокового розвитку з чітким описом функціональності і концепцією готового продукту метод фіксованої ціни буде найкращим вибором. Для довгострокового співробітництва і в разі, якщо ви збираєтеся змінити вектор діяльності, вибирайте дві інші моделі. І пам'ятайте, що система ціноутворення, яка добре зарекомендувала себе для конкретної організації і у певного виконавця, може не завжди бути кращим вибором для запуску вашого проекту.

Якщо ви знайшли помилку, будь ласка, виділіть фрагмент тексту і натисніть Ctrl + Enter.

Коли слід вибирати цей варіант?
Ви хочете особисто керувати процесом розробки?
Ви думаєте про розширення бізнесу в майбутньому?
Вам потрібна команда, яка працює виключно над вашим проектом?
Як зрозуміти, що вам підходить дана модель?
Вам потрібна велика гнучкість в процесі розвитку?
Ваша ідея пов'язана з новими технологіями, а не з повністю розвиненими ринками?
Ви маєте намір забезпечити прямий контроль над проектом і надати своїй команді конкретні матеріали?
Як зрозуміти, що вам підходить ця модель?
Чи можна повністю описати функціональність вашого продукту і етапи його реалізації?