Договір на розробку – agile, waterfall чи out staff?
Програміст програмує, замовник платить. Що ж в цьому складного? Навіщо ті договори, якщо і так все зрозуміло. Кхм… можливо, десь в ідеальному світі, це і спрацювало б, але в наших буремних буднях все не так просто.
Для врегулювання відносин між компанією розробником програмного забезпечення укладають договори, які закріплюють домовленості на папері, щоб, якщо раптом що – «а-та-та, дивись пункт 5, підпункту 6, статті 9 розділу 5» 🙂
З одного боку, максимально детальні договори, які передбачають всі можливі ситуації, які можуть статись під час розробки та після неї, це добре, але ж чи є сенс переписувати кодекси в договір? Ба більше, в максимально детальних договорах іноді забувають про ключові пункти. З іншої сторони, без договору, або з «договором на серветці» у випадку конфлікту інтересів в суді буде не так-то просто обом сторонам. Якщо цікавлять такі спори, зокрема щодо розробки веб-сайтів – можете почитати нашу цікаву статтю на цю тему.
Який тип договору на розробку софту обрати?
Це питання, звісно, не таке серйозне як вибір мови програмування для програміста – початківця, але все ж серйозне.
Waterfall
Отже, чим характерні waterfall договори?
В таких договорах чітко вказується технічне завдання, яке, зазвичай, узгоджується Сторонами у Додатку та відразу підписується. Бувають кейси, коли Замовник підписує таке технічне завдання, навіть не читаючи його, а потім, коли результат не відповідає очікуванням, виявляється що в самому технічному завданні також вказано зовсім не те, що хотів би бачити Замовник. Доброю порадою для Замовника, який не розуміється на технічних нюансах і для якого те технічне завдання виглядає наче ієрогліфи, буде проконсультуватись з іншим незалежним розробником перш ніж затверджувати технічне завдання на предмет того, чи відповідає воно його очікуванням. Саме відповідність технічному завданню в судовій практиці часто стає предметом експертизи і вирішальним у спорах про неякісне надання послуг з розробки програмного забезпечення.
Agile
Добре, з цим зрозуміло. Чіткі умови, точне ТЗ, конкретні строки, конкретні суми. А що це за диво – agile договір? Як це можна зробити договір на методологію розробки? Маячня. Не зовсім. Логіка все ж є. В цьому договорі закріплюються основні лейтмотиви ідеї та концепції гнучкої розробки – а саме, постійна співпраця між Замовником та Виконавцем.
Ба більше, вони скоріше добрі партнери ніж Клієнт та підрядник. А чи доцільно в цьому договорі розписувати всі ці юзер-сторі, бек-лог, сторі борд, ретроспектива, маніфесто? Цікаво, як на все це подивиться суд, якщо раптом щось. В agile договорі, в українських правових реаліях у будь-якому випадку мають бути істотні умови, характерні для договорів розробки софту. Предмет договору, ціна, строки і ті умови, які будуть визначені як істотні сторонами. Всі детальні умови комунікації між Сторонами можна розмістити у відповідному розділі – «Взаємодія Сторін». Калькуляцію вартості конкретних юзер сторі можна також розписати, так само як і спринти – етапи в рамках загального строку надання послуг.
Такі види договорів набирають все більшої популярності серед розробників та замовників, адже досить часто процес розробки є довготривалим і умови ринку, під який створюється продукт змінюються. Саме адаптивність до можливих змін, постійна співпраця і націленість обох сторін на успішний реліз продукту є основною перевагою agile договорів.
Out staff
Ще одним варіантом урегулювання відносин може бути out staff договір. В цьому випадку Замовник отримує у своє розпорядження конкретні години конкретних спеціалістів зі скілами, які описані в Договорі. Такі спеціалісти надають послуги в межах заявлених навиків. При цьому, роботу таких спеціалістів може координувати менеджер, години якого також продаються в рамках аутстаф договору. Такий варіант підходить для досвідчених Замовників, або тих, хто має розуміння у сфері розробки софту, і відповідно, зможе отримати користь саме від такого алгоритму роботи.
В таких договорах фіксуються кількість годин конкретних спеціалістів, вартість таких годин, в залежності від спеціалізації та навиків осіб, що залучені.
Same, but different (однакове, але інакше)
Звісно, весь цей поділ договорів на розробку софту на waterfall договори, agile контракти та аутстаф угоди є досить умовним. Ключові, на нашу думку, відмінності були вказані вище і в залежності від конкретного кейсу та суті правовідносин можна обрати потрібний формат. А ще – можна розробити певний mixed agreement, який буде включати елементи всіх трьох договорів 🙂
У будь-якому випадку для Замовника важливо отримати кінцевий результат та всі виключні майнові авторські права на нього. Ба більше 🙂 Це все Замовнику хочеться отримати за зрозумілу плату та у визначений строк. Для розробника ж важливо буде зрозуміло і чітко виписати свої обов’язки та виконавши їх, отримати оплату, а також не вказати в договорі того, що гарантувати Виконавець не може. Звісно, це лише верхівка айсбергу і в майбутніх стрімах та статтях ми більш детально зупинимось на конкретних аспектах таких договорів.
Якщо ж маєте конкретне питання з цього приводу, або ж хочете провести тест на адекватність 🙂 та підводні камені для Вашого договору на розробку софту – клікайте на контактну форму.