Домовленості на «березі». Як захистити себе від роздування бюджетів на розробку сайту
Іноді ризики закладаються на старті, а інколи у нагоді стануть короткі та зрозумілі ітерації
У статті Сергій Колозенко, фаундер і CEO Megasite, компанії з розробки сайтів із гарантіями термінів та якості, ділиться досвідом і практичними порадами, як уникнути втрати контролю над бюджетом у розробці сайту і чому ключові домовленості варто фіксувати ще на старті проєкту.
Головна причина виходу бюджету за межі
У більшості проєктів логіка виглядає однаково. На старті клієнт формує запит на сайт із певним функціоналом, потім погоджується коротке технічне завдання, визначається обсяг робіт і фіксується вартість. Після цього підписується договір і починається робота. Далі на базі короткого ТЗ підрядник пропрацьовує детальне технічне завдання по всьому функціоналу. Описується, як має працювати, логіка сайту, структура, прототипи і розташування елементів. І вже на цьому етапі іноді з’являється момент, коли клієнт згадує, що щось не врахували або не проговорили на старті.
У процесі роботи з’являються додаткові функції, інтеграції або деталі, які не були закладені спочатку. Це напряму впливає на вартість. Якщо частину функціоналу не проговорили на старті і вона з’являється вже під час детального опрацювання, бюджет починає зростати. У деяких випадках це може збільшити вартість на 50–100 відсотків.
Сергій Колозенко, фаундер і CEO Megasite, компанії з розробки сайтів із гарантіями термінів та якості
Фіксація бюджету і зміна домовленостей у процесі
У MEGASITE ми працюємо наступним чином: одразу домовляємося, який обсяг робіт виконуємо за конкретний бюджет, і якщо змінюються умови або обсяг задач, відповідно змінюється і вартість.
Наприклад, якщо потреби замовника зростають на 30 відсотків, ми спочатку виконуємо все, що передбачено договором, і здаємо цю частину роботи. Після цього або укладаємо новий договір, або підписуємо додаткову угоду, де фіксуємо новий функціонал, обсяг робіт і вартість. Якщо замовник хоче більше, ніж було узгоджено на старті, це вже новий обсяг робіт. У такому випадку не можна просто змінити ціну в процесі. Спочатку виконуються попередні зобов’язання, а далі робота продовжується на нових умовах.
Такий формат дозволяє зберігати контроль над бюджетом і уникати конфліктів у процесі роботи.
Головний інструмент захисту бюджету клієнта від непередбачуваних витрат
Технічне завдання – це основа всього проєкту і головна точка опори для обох сторін. Воно задає логіку роботи, структуру, функціонал і інтеграції, від яких залежить результат. Як і в будівництві, спочатку створюється детальний план, і тільки після цього починається реалізація, так само і в розробці сайту.
Якісне технічне завдання дозволяє уникнути непорозумінь і захищає обидві сторони в процесі роботи. Саме тому цьому етапу потрібно приділяти час і ресурси з боку і замовника, і команди розробників, адже така робота не може бути безкоштовною.
Здебільшого клієнти приходять або без технічного завдання, або з короткими нарисами. Краще, коли є хоча б базове бачення. На його основі можна сформувати детальне професійне ТЗ і далі працювати системно. Якщо ж немає нічого, виникають ті самі ситуації, про які вже йшлося раніше. Щось забули, щось не врахували, і в процесі це призводить до зростання бюджету.
Як у Megasite ми прораховуємо ризики складної розробки ще до старту
Найчастіше додаткові витрати виникають у всьому, що пов’язано з бекенд-розробкою, додатковим функціоналом і інтеграціями. Якщо говорити про технічне завдання чи дизайн, їх легше оцінити і спрогнозувати наперед. Натомість складна розробка і функціонал можуть змінюватися в процесі. Логіка роботи може виглядати однією на старті, а після обговорення з клієнтом змінюватися, і це напряму впливає на вартість.
У простіших проєктах, які займають до двох-трьох місяців, ми працюємо за фіксованим бюджетом. При цьому заздалегідь враховуємо можливі відхилення і закладаємо певний відсоток ризику. Це дозволяє не переглядати бюджет і не підписувати додаткові угоди при незначних змінах.
Якщо говорити про великі проєкти, які тривають від чотирьох до шести місяців і більше, ми працюємо по спринтах. Робота ділиться на окремі етапи тривалістю два-три тижні. Кожен етап оцінюється окремо, після виконання клієнт приймає результат і оплачує його. Якщо змінюється функціонал або бачення, ми переоцінюємо обсяг робіт у межах наступного етапу.
Тому підхід залежить від масштабу проєкту. В одних випадках ми закладаємо ризики на старті, в інших працюємо короткими і зрозумілими ітераціями без додаткових запасів.
Communication is key
А ще – чітке ТЗ і кастомний підхід до кожного проєкту. Саме так у Megasite ми будуємо роботу з клієнтом: детально проговорюємо функціонал, фіксуємо домовленості і лише після цього переходимо до реалізації. Бо в розробці немає «дешевих» рішень. Є лише ті, які на старті здаються дешевшими, але згодом обходяться значно дорожче.