На яких умовах стартапу або бізнесу співпрацювати з розробниками
Віра Мошко, менеджерка проєктів, 04 вересня 2023
«Хто відповідає за збільшення бюджету на 30% у процесі розробки та має зазнати збитків?»
«Або за те, що заплановані та реалізовані функції виявилися непотрібними користувачам?»
«Як швидко мають бути виправлені помилки та відновлена робота застосунку, якщо виникли проблеми?»
Насправді на ці питання немає однозначних відповідей. Усе залежить від того, як домовилися клієнт та розробники, який формат співпраці вони обрали. Обраний формат визначає зони відповідальності кожної зі сторін.
В ідеальному світі очікуваннями клієнта керує компанія-розробник. Особливо, якщо клієнт отримує свій перший досвід і не знає, як побудований процес. У реальному світі подібні питання можуть вирішуватися через конфлікти. Наприклад, якщо замовник вважає, що підтримка зробленого продукту є відповідальністю розробника, а розробник має витратити на це додаткові ресурси, які не входили до вартості, зафіксованої у договорі.
Узгоджені зони відповідальності допомагають не тільки уникнути зайвих суперечок, але й отримати кращий результат. Якщо клієнт несе відповідальність за визначення того, що має бути зроблено в продукті, варто йому про це знати й приділити цьому увагу: краще вивчити користувачів та їхні потреби або найняти додаткового спеціаліста. Іноді клієнт може потрапити в ситуацію, коли підрядники сумлінно виконували його задачі, але продукт вийшов некорисним та нецікавим. Клієнт вважав, що спеціалісти згодні з його рішеннями і повідомили би, якщо він щось робить не так. Натомість маркетингова частина не є компетенцією команди розробки і вони просто неспроможні оцінити чи вірно клієнт керує продуктом.
Поширені формати співпраці
На ринку існує чотири найбільш поширених. Кожен формат визначає розподіл відповідальності й ризиків між клієнтом та підрядником.
- Fixed Price — фіксована вартість.
- Time & Material — розрахунок за витрачені за фактом ресурси.
- Cost Reimbursable (Outstaffing) — «лізинг» окремих розробників або команди.
- Service Level Agreement (SLA) — сервіс підтримки працюючих проєктів.
Fixed Price
Можливість для клієнта зафіксувати в договорі вартість розробки, терміни та повний перелік усього, що має бути зроблено в продукті.
Клієнт має бути готовим до ретельного опрацювання технічного завдання, розробки прототипів, визначення всіх вимог. Пройти окремий етап дослідження, який може зайняти від двох місяців до півроку і навіть більше, залежно від розміру проєкту.
Кому підходить
Клієнт чітко розуміє, що він хоче отримати в результаті, вимоги до продукту не будуть змінюватися в процесі. Або зміни будуть незначними. Сам процес внесення змін буде вимагати часу на дослідження нових вимог, розробку прототипів та додаткову оцінку, яка має бути зафіксована у додатку до договору.
Відповідальність
Відповідальність за визначення того, що має бути зроблено в продукті, несе клієнт. Компанія збирає вимоги до продукту з клієнта або з джерел, які надає клієнт. Виключення, коли маркетингову функцію (дослідження користувачів, ринку та визначення ключової цінності) бере на себе підрядник. Але це узгоджується окремо.
Розробники самі визначають склад команди, рівень спеціалістів та обирають методології для роботи над проєктом. Технічні рішення також залишаються на стороні розробників.
Ризики
Ризики за виконання умов (дотримання узгодженого бюджету, термінів та якості) повністю несе компанія-розробник. Якщо у процесі виявиться, що деякі функції були недооцінені, то збитки несе підрядник. Тому у ціну можуть закладатися ризики — визначений компанією відсоток від загальної вартості проєкту.
Гарантія
Проєкт завершується передачею продукту клієнтові. Наприклад, публікацією застосунків. Клієнт може узгодити гарантійний термін, упродовж якого розробники безкоштовно виправляють дефекти та помилки, якщо такі виникнуть. На розробку додаткових функцій та підтримку підписується окрема умова.
Як розраховується бюджет
Загальна кількість годин, необхідна для розробки продукту, помножена на рейт (вартість години).
Зазвичай точна оцінка надається після етапу дослідження, коли чітко прописане технічне завдання та розроблені прототипи або дизайн.
Time & Material
Цей формат дає клієнтові більше гнучкості та впливу на процес розробки. Не передбачає великих витрат часу на збір та опрацювання всіх вимог. Часто бюджет, терміни та набір запланованих функцій дуже умовні, або фіксується тільки один з критеріїв.
Кому підходить
Клієнт загалом розуміє, яким має бути продукт, але не має потреби у чіткому плануванні розробки на місяці вперед, хоче рухатися поступово, мати можливість гнучко вносити зміни, наприклад, відмовлятися від запланованих функцій та додавати нові.
Усі частини (спрінти) опрацьовуються та плануються поступово. Клієнт отримує проміжні результати та вирішує, що робити далі.
Відповідальність
Рішення щодо продукту можуть прийматися сумісно, або можуть бути залучені додаткові спеціалісти до команди. Клієнт може впливати на склад команди, рівень досвідченості розробників та методології розробки.
Ризики
Ризики розділені навпіл. Розробник може надати орієнтовні терміни та вартість, але не зазнає збитків, якщо вони виявляться більшими, ніж очікувалося. Натомість, клієнт може відмовитися від співпраці, якщо розрив між початковою оцінкою та фактичними витратами буде надто великим.
Проєкт може завершитися в будь-який момент, згідно з рішенням клієнта. Клієнт та розробники можуть домовитися про термін відмови від співпраці. Наприклад, за один або два місяці клієнт має попередити компанію-розробника, що він призупиняє роботу.
Як розраховується бюджет
Визначається склад команди та залученість кожного з її членів. Наприклад, розробник може бути залученим на повний місяць або на 80 годин упродовж місяця.
Для визначення місячного бюджету, рейт (вартість години) члена команди множиться на кількість годин, яку він має бути залученим у проєкт. Розраховується для кожного спеціаліста та сумується по команді.
Клієнт та розробник можуть узгодити приблизну кількість місяців на розробку продукту.
Cost Reimbursable (Outstaffing)
«Лізинг» команди розробки або окремих розробників.
Кому підходить
У клієнта вже є технічна команда, але ситуативно не вистачає спеціалістів або швидко потрібно розширити команду.
Відповідальність
Клієнт повністю керує проєктом та несе повну відповідальність за розробку продукту, бюджет, терміни та якість.
Виконавець відповідає за пошук людей, їхнє навчання та надає умови для роботи, наприклад, робоче місце й техніку. Зазвичай відпустки та лікарняні оплачує виконавець, але дати узгоджуються з клієнтом.
Проєкт може завершитися в будь-який момент, згідно з рішенням клієнта.
Як розраховується бюджет
Оплачується кількість відпрацьованих годин кожного члена команди, згідно з узгодженим рейтом (вартістю за годину).
Services Level Agreement
Сервіс підтримки працюючих проєктів.
Кому підходить
Клієнт має продукт, який пройшов фазу активного розвитку, вимагає надійної роботи та впровадження постійних невеликих покращень. Або для клієнта важлива швидкість реакції та виправлення помилок у визначені терміни.
Відповідальність
Договір на підтримку може передбачати базовий набір сервісів: моніторинг проєкту, внесення невеликих покращень у межах бюджету, регулярне оновлення бібліотек, перехід на сучасніші технології, щоб запобігти проблемам у майбутньому. Якщо є запит на більші зміни, не передбачені умовою, він розраховується окремо.
Клієнт та компанія-розробник визначають у який спосіб буде реалізована підтримка. Наприклад, звернення користувачів потрапляють безпосередньо до розробників, вони відповідають за їхню пріоритезацію та виконання. Або замовник відповідає за обробку звернень та передає розробникам тільки визначені ним зміни, які необхідно впровадити.
Ризики
Може регламентуватися швидкість реакції на помилки. Наприклад, для деяких продуктів з медичної або державної галузі є важливою надійна та безперебійна робота. Від цього можуть залежати життя або безпека. Навіть, якщо щось сталося вночі, це має бути виправлено миттєво.
Швидкість реакції також може регулюватися впливом інцидентів (багів). Якщо вплив на роботу системи високий, то має бути виправлено, наприклад, упродовж години, якщо низький — упродовж доби. Ризики за виконання визначених умов повністю несе компанія-розробник. Можуть бути передбачені штрафи, якщо не дотримано швидкості реакції та часу виправлення помилок, зафіксованих у договорі.
Як розраховується бюджет
Оплата тарифікується помісячно.
Кожен з запропонованих форматів є орієнтиром для визначення зон відповідальності. Усе залежить від контексту проєкту та його потреб. Головною ціллю є синхронізувати очікування та чітко зрозуміти, хто на що впливає та за що відповідає. Це не тільки про відносини між клієнтом та командою з розробки, а й про результат, який вони отримують від співпраці.
Формати співпраці можуть змінюватися в процесі взаємодії. Перша версія продукту може бути розроблена за фіксованою оцінкою, а його розвиток відбуватися за Time & Material, щоб отримати більше гнучкості та швидше впроваджувати зміни. Якщо продукт проходить фазу активного розвитку та вимагає тільки підтримки й моніторингу, то можна змінити формат на Services Level Agreement.