Чи хтось працював з www.siter.in.ua? Мій досвід співпраці як клієнта
Привіт, спільното.
Хочу порадитись і заодно поділитися своїм досвідом співпраці з підрядником по доопрацюванню інтернет-магазину на OpenCart.
Звернувся до команди для виконання технічного завдання (оптимізація швидкості, правки по SEO, робота з редіректами, зображеннями і т.д.). На старті все виглядало ок — погодили ТЗ, оцінили вартість, підписали договір, внесена передоплата.
Але в процесі виникло кілька моментів, які трохи вибили з колії:
— Частина задач, які були включені в ТЗ і договір (зокрема робота з редіректами), в процесі була винесена «за рамки» і запропонована як окрема робота.
— Після деяких змін на сайті з’явились побічні ефекти (проблеми з відображенням частини зображень, були нюанси з доступом до адмінки).
— Коли звернувся з проханням перевірити — отримав відповідь, що це або не їх зона відповідальності, або потрібно додатково оплачувати діагностику.
— По оплаті — позиція підрядника: оплачувати потрібно за виконані частини, навіть якщо весь обсяг ТЗ ще не закритий.
Зі свого боку розумію, що:
- обсяг робіт може змінюватись
- SEO-правки часто «розростаються»
- не всі речі можна одразу оцінити точно
Але трохи дивує момент, коли погоджений пункт потім не виконується, або коли після змін з’являються проблеми, і їх перевірка стає окремою платною задачею.
Тому питання до тих, хто працював з підрядниками (особливо по OpenCart / SEO-оптимізації):
- Це нормальна практика — в процесі виносити частину погодженого ТЗ в окремі роботи?
- Як ви зазвичай фіксуєте обсяг задач, щоб не було «розширення» посеред процесу?
- Хто зазвичай несе відповідальність за побічні ефекти після змін (типу зниклих зображень і т.д.)?
- Як правильно будувати оплату — за етапи чи за повністю завершений результат?
Буду вдячний за досвід і поради, бо хочу зрозуміти чи це нормальна практика, чи я десь не так вибудував процес.
5 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів1. Межі ТЗ та зміни обсягу робіт
- Винос задач за межі погодженого ТЗ є допустимим виключно в трьох випадках:
- в процесі реалізації виявляються технічні обмеження системи (CMS, модулі, архітектура), які об’єктивно не можна було передбачити заздалегідь;
- виконання погоджених задач призводить до логічного розширення обсягу робіт (наприклад, виконання погоджених задач може призводити до логічного розширення обсягу робіт у випадках, коли SEO-правки виходять за межі базових змін — мета-теги, тексти, атрибути, стандартні редіректи і вимагають втручання в структуру сайту, URL-архітектуру, логіку перелінковки, шаблони сторінок або інший функціонал, що потребує додаткової розробки).
В усіх інших випадках — якщо задача була явно зафіксована в ТЗ — її винесення в окремий бюджет є некоректним.з’являються нові вимоги, які не були зафіксовані на етапі погодження;
2. Фіксація домовленостей
Усі домовленості щодо обсягу робіт мають бути:
- чітко зафіксовані в договорі та технічному завданні (ТЗ);
- деталізовані до рівня, який дозволяє уникнути подвійного трактування;
- доповнені переліком:
— того, що входить у scope;— того, що не входить;
— можливих ризиків і залежностей.
Будь-які зміни в обсязі робіт повинні проходити через процедуру погодження (change request).
3. Відповідальність за побічні ефекти
Зона відповідальності визначається принципом:
👉 відповідає той, хто вносив зміни
До зони відповідальності підрядника відноситься:
- функціонал або елементи, які були змінені в рамках виконання робіт;
- побічні ефекти, що виникли після впровадження змін.
Не відноситься до відповідальності підрядника:- проблеми, які існували до початку робіт;
- збої сторонніх сервісів (хостинг, CDN, сторонні модулі);
- зміни, внесені клієнтом або іншими підрядниками паралельно.
Окремо варто зазначити:👉 SEO-спеціаліст не несе прямої відповідальності за технічну реалізацію, включаючи:
- обробку зображень;
- роботу шаблонів;
- серверну частину.
Це зона відповідальності розробника або технічної команди, яка виконувала відповідні зміни.4. Моделі оплати
Існує кілька робочих моделей, і кожна з них може бути ефективною залежно від цілей:
- Фіксована оплата за етапи (milestones)
— оплата після завершення і приймання конкретного блоку робіт;— оптимальна для проєктних задач.- Оплата за виконані роботи (time & materials)
— гнучка модель для складних або слабо прогнозованих задач.- Гібридні моделі
— базова оплата + бонус за досягнення KPI (трафік, позиції, конверсії);— мінімальне покриття витрат у разі відсутності результату.
5. Принцип вибору моделіОптимальна модель визначається через:
Основна рекомендація, яка вирішує більшість проблем заздалегідь, — працюйте маленькими ітераціями.
Якщо співпраця подобається — працюєте далі. Якщо не подобається — шукаєте іншого підрядника.
Таким чином, просто не виникатиме жодного з перелічених вами питань.
Дякую за пораду, але цього підрядника я знайшов в Телеграм каналі одного дуже авторитетного програміста, модулем якого користуються мабуть 99,9% відсотків продавців хто має сайт на opencart. І тут проблема в тому що виконавець не виконує того під чим підписався в договорі.
Дивлячись, що в договорі написано
В договорі якраз це зафіксовано.
Оплата поділена на 2 частини, і друга частина — після виконання робіт (п.3.2).
Також є пункт, що виконавець має виконати роботи згідно додатку (п.2.2.1), а в самому додатку прямо вказані задачі, включаючи виправлення редіректів.
Тобто по факту:
— редіректи входили в погоджене ТЗ
— але в процесі їх винесли «за рамки»
Тому і виникло питання по оплаті, бо частина погоджених робіт не була виконана.