Типи контрактів в аутсорсингу

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

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

АЛЕ чому важливо розрізняти різні види контрактів, на які вас наймають, звичайному ІТшнику?

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

Коротенько, про що розказав:

1. Time and Material (T&M):
Класичний продаж відпрацьованих годин працівником.

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

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

Рекомендації:
Вибирайте T&M для проектів із невизначеними або мінливими вимогами, або коли обсяг проекту не чітко визначений.

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

Плюси:
— Високий рівень контролю замовником над командою та проектом( може бути мінусом для аутсорсера, якщо є бажання продавати джунів по ціні сініорів )
— Розмір команди легко масштабується.
-Краще збереження знань і глибше розуміння бізнесу клієнта.

Мінуси:
— Вимагає значної участі клієнта в управлінні командою та розподілі ресурсів.
— Триваліший час нарощування, щоб зібрати правильну команду, так як замовник, як правило, приймає участь в процесі інтерв’ю і відсіює частину кандидатів.
— Більша відповідальність клієнта для забезпечення ефективності та продуктивності команди.

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

3. Fixed-Price (FP):
Виконання проекту за попередньо погодженими умовами, бюджетом, вимогами, сроками.
Структура оплати часто базується на етапах.

Плюси:
— Чітка та передбачувана вартість і терміни.
— Менша участь клієнта в щоденному управлінні проектом.
— Аутсорсер бере на себе більше ризику та відповідальності за виконання проекту( плюс для клієнта, мінус для аутсорсера ).

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

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

4. Managed Services (MS):
У моделі керованих послуг постачальник бере на себе повну відповідальність за надання певного набору ІТ-функцій або послуг, часто згідно з угодою про рівень обслуговування (SLA). Постачальник керує всім процесом, включаючи ресурси, інструменти та інфраструктуру.
Якщо в двох словах: це сервіс на вимогу, оплата за час/обсяг виконаних робіт.

Плюси:
— Постачальник бере на себе відповідальність за надання послуг і дотримання SLA( Service Level Agreement ).
— Дозволяє клієнту зосередитися на основній бізнес-діяльності, без необхідності тягнути власний ІТ відділ.

Мінуси:
— Менший контроль над ресурсами та процесами постачальника.
— Обмежена гнучкість у налаштуванні послуг.
— Потенційне блокування постачальника, якщо змінити постачальника важко, так званий вендор-лок.

Рекомендації:
Пропонуйте замовнику таку модель співпраці, якщо він хочете передати певні ІТ-функції чи послуги на аутсорсинг і зосередитися на своїй основній бізнес-діяльності, забезпечуючи незмінний рівень якості послуг.


5. Retainer Model:
У моделі Retainer клієнт погоджується сплачувати фіксовану щомісячну плату постачальнику за попередньо визначений набір послуг. Ця модель підходить для довгострокових відносин, гарантуючи, що постачальник готовий забезпечити постійну підтримку та обслуговування.
Дуже схоже на MS але на базі щомісячної фіксованої плати, а не по факту виконаних робіт.

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

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

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


6. Outcome-based Model:
Виконавець отримує винагороду на основі досягнення заздалегідь визначених вимірюваних результатів або ключових показників ефективності (KPI). Ця модель розроблена для узгодження інтересів постачальника з бізнес-цілями клієнта.
ВАРІАЦІЯ цього типу контракту може виглядати як створення продукту для стартапу за певний % акцій компанії.

Плюси:
— Сильний фокус на досягненні вимірюваних результатів.
— Компенсація постачальника прив’язана до успіху проекту, стимулюючи продуктивність.
— Заохочує інновації та ефективність постачальника.
— Потенційно найбільший прибуток саме за такими видами контрактів.

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

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

Детальніше по це, а також ще декілька цікавих тем у моєму свіжому випуску:<

00:00 — Початок, для кого це відео
01:56 — Time and Materials
06:21 — Dedicated team
10:16 — Байка про недобросовістного аутсорсера
11:22 — Fixed Price
16:32 — Managed Services
19:25 — Retainer Model
21:22 — Outcome-based Model
26:33 — Потенційно найбільш вигідні моделі контрактів для Аутсорсера
28:13 — Потенційно найбільш вигідні моделі для Замовника
29:34 — Чому менеджменту варто знати які існують типи контрактів і періодично їх переглядати

👍ПодобаєтьсяСподобалось8
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Напевно, ще потрібно було згадати Cost Reimbursement контракт.

Dedicated team, managed services теж часто(завжди?) рахуються через Time&Material.

Тому я б не відносив їх до тої самої категорії а розбив б на дві категорії — як платити (fixed, T&M) і тип послуги (тушка погодинно, тушка на фулл тайм на місяці, тімка тушок з менедженням найму і роботи, весь дев цикл з супортом і т.п.)

Сподіваюся кризис відправить у минуле більшість контрактів де виконувач отримує гроші за час і не відповідає за результат.
Замість цього з’являться компанії — аудитори, які будуть спеціалізуватися на ІТ. І у контрактах будуть величезні пенальті якщо аудитори помітять ознаки поганого виконання замовлення.
Аутсорсна галера як завжди налабала так-сяк і в продакшин. Аж тут клієнт звертається до аудиторів:
— Метрики коду роблять його важким для довготривалої підтримки — штраф.
— Тести не покривають усі випадки, деякі взагалі нічого не перевіряють (завжди проходять) — штраф.
— Знайдені кричущі вразливості безпеки (OWASP) — штраф.
— Архітектурне рішення погано масштабується, жере зайві ресурси — отже нагріває планету. Штраф та претензії від екологічних організацій.
— UI не придатний для людей з поганим зором чи іншими обмеженнями — суд, штраф, заборона.
— Нема локалізації на державну мову, на мови меншин — так само штраф і заборона.
— Приватні данні не захищені, вимоги GDPR не виконано — штраф і розслідування.
У підсумку аутсорсер повертає повний кошт проекта + додатково покриває збитки за втрачений прибуток.
Стандарти ІТ проектів стають упевнено наздоганяють будівництво. Мало написати код — треба ще довести що він відповідає усім нефункціональним вимогам.

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

А як що до того, що клієнт не хоче платити за якість?

точно не захоче платити за уявлення про якість якоїсь 3-ї компанії аудитора

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

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

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

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

Не могу представить себе подрядчика, который бы согласился работать на таких условиях.

А вы бы сами согласились участвовать в качестве подрядчика на таких условиях?

Что могу представить — так это когда двум подрядчикам поручают сделать прототип или proof of concept, платят обоим, а потом уже выбирают, кому из подрядчиков поручить продолжение проекта.

дам ТЗ двом підрядникам

наприклад вибор між ердоганом і лукашенкою?
питання — чому ви вибрали саме два, а не більше? + інші критерії

PS: хоча нижче он розібрали це

Повністю згодна. Просто є різні клієнти. Впевнена ви говорите про проекти з бюджетами від 200к. На жаль, на разі ми працюємо з бюджетами до 100к і там ми дуже важко конкуруємо з Азією.
Також є різні запити. Якщо ми говоримо про автомотив або про великі складні системи, то якість має бути на першому місці. Але якщо ми говоримо про стартапи та тестування гіпотез продукту на ринку, тут швидкість і бюджет більш приорітетні, і тут я з клієнтами повністю згодна і роблю все можливе, щоб знайти баланс між якістю і швидкістю.

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

Якщо ви зацікавлені в ± довгостроковій співпраці із замовником, раджу спробувати зробити щось для клієнта безкоштовно, поза скоупом. Ті ж юніт-тести або підняти СІ/CD якщо про це не домовлялися або документацію і т.д.
Після чого, презентувати це йому як «комплімент від шефа» і показати якийсь позитивний кейс, як ви зекономили час або знайшли баги відразу, а не після тестування і т.д. Якщо йому сподобається і оцінить — пропонувати розширення і вже виділяти на це додаткові час і гроші.
Якщо несподобається — шукати якийсь більш переконливий кейс як ваші юніт-тести врятували реліз або зробити ретроспективу якогось фейлу і показати, що наявність тестів могла б попередити це.

Ось в своєму відео декількамісячної давності я показував, як за допомогою ChatGPT3.5 генерувати код, писати тести, піднімати CI/CD пайплайни. Зараз вже є 4 версія, мав би бути ще кращий результат.
www.youtube.com/...​tch?v=xMfsodD7afs&t=2245s
Наведеним на відео способом ви витратите не дні чи тижні на безкоштовну роботу, а години.
Ідеально для стартапів та валідування гіпотез.

А як що до того, що клієнт не хоче платити за якість?

А чи має клієнт платити за якість? От наприклад ви заходите до супермаркету, купили продукти і вам пропонують додатково «заплатити за якість». Це означає що якщо заплатите — то продавець гарантує що продукт якісний, не прострочений, не «палений», а якшо не бажаєш платити за якість — то ніяких гарантій. Далі — новобудова. Не захотіли додатково «платити за якість» — будинок може завалитися від будь — якого поштовху.
Чи можливо таке у реальному житті? Звичайно — НІ ! Бо існують закони і організації які захищають покупця. Йому не треба окремо «платити за якість» — тому що продаж неякісного товару вже злочин!
Коли на дико зростаючому ринку ІТ був хайп і бульбашка — клієнти були готові віддавати купу грошей навіть за відверте гівно. А якщо вони хотіли якість — то з них «драли 3 шкури» (і усе одно якість забезпечити не вміли).
Зараз бульбашка нарешті луснула! За HTML пейдж навіть недоїдений гамбургер не дадуть. «Вкладати» гроші у ІТ більше ніхто не буде. Будуть платити тільки за продукт, який вирішує проблеми бізнесу.
ІТ компаніям самим доведеться створити якусь організацію з якості, аби вижити із зхлопнутого ринку усіляких формошльопів ті інфо-циган. Більше не буде проектів розроблених індійськими школярами. Аби отримати замовлення доведеться довести свою кваліфікацію і якість продукту.

Згодна з вами, але і в супермаркеті є вибір. Якщо ви хочете сиру, ви можете купити сирний продукт за 5 гривень, а можете камамбер за 200 грн. І той, і той задовольняє ваші потреби в сирі. Проте якість різна, і від камамберу 100% не буде погано, а ось після першого не факт.

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

тести дуже важко вмістити в очікувані бюджети клієнтів

Це — було.

Все ж об’єм проекту регулюється контрактом.

Саме так. Тому через пів-року клієнти будуть приходити з типовими контрактами де закладене 100% покриття тестами, локалізація на усі мови, перевірка аудиторами, виправлення усіх багів — і усе за рахунок виконавця. А тільки як усе готово і перевірено — тоді оплата.
І навіть на такі контракти будуть тендери з голодних ІТ компаній!
Ринок вже перевернувся — тепер це ринок замовника, на якому ІТ компанії будуть згодні працювати за їжу.

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

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

Окрім того, будь-які формальні заборони можна обійти, або «порішати».

В ІТ, як і у всьому іншому, мають бути максимально прозорі правила гри аби «риночок порішав».
Якщо ваша компанія робить продукти краще ніж індуси чи пакистанці чи бразилійці чи мексиканці чи чехи, то кастомер з великою ймовірністю піде до вас, навіть якщо дорожче і довше.
Саме тому я намагаюся вчитися щодня сам і покращувати нашу українську ІТ індустрію загалом через донесення корисного матеріалу, свій ютуб канал та статті такі як ця.

Комент чому такий підхід буде працювати і навіть ВЖЕ працює на багатьох проектах:

Ти не повіриш, але прямо зараз я працюю на проекті, де таке вже є.
Мій поточний проект відноситься до Автомотіву і там дуже багато стандартів, регуляцій, правил, тому що це безпека.
Тачка, в якої гальма можуть відмовити через програмний збій(привіт Тесла focus.ua/...​na-bolshoy-skorosti-video ) НЕ ПОВИННА ВИЙТИ НА РИНОК, так само як і не повинен взлетіти літак який через програмний збій може впасти( привіт індуси які робили цей софт www.dw.com/...​така-737-max-8/a-48213254
)
Саме тому в автомотів є майже загальновизнаний стандарт ASPICE ( visuresolutions.com/...​k/blog/automotive/aspice ) який перевіряє правильність процесів, що в свою чергу суттєво збільшує ймовірність того, що ваш продукт буде зроблений як треба.
У нас( не прямо в мене, у замовника) прямо зараз проходить багаторівневий комплексний аудит від зовнішньої компанії яка оцінює відповідність стандартам і у випадку позитивного рішення, наш продукт зможе вийти на ринок, а у випадку негативного — блок допоки не будуть виправлені всі зауваження і пофіг на сроки та бюджети.

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

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

Стандарти ІТ проектів стають упевнено наздоганяють будівництво

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

Сподіваюся кризис відправить у минуле більшість контрактів де виконувач отримує гроші за час і не відповідає за результат.
У підсумку аутсорсер повертає повний кошт проекта + додатково покриває збитки за втрачений прибуток.

Тоді ціна на послуги буде Х10 від поточної)
Чи ти на зарплату будеш чекати поки весь проект приймуть?)

Вибирайте T&M для проектів із невизначеними або мінливими вимогами, або коли обсяг проекту не чітко визначений.

Далі можна не читати, інших видів проектів все одно не буває :)

Буває, що грошей явно не вистачить на довготривалий T&M, ось тоді починаються варіанти)

Time & Material у чистому вигляді ніколи взагалі не бачив.
Зазвичай так роблять із держ установами або великими ентерпрайзами де вхід тільки через тендер із чітким естімейтом. А ось тут якраз завищіти естімейт не вийде.
Тому часто домовляються про якусь базу типу головне заскочити, а потім подивимось і по ходу проекту робиться купа оплачуваних окремо ченж реквестів.

Підписатись на коментарі