Виправлення багів над проєктом - етап 3

Співпраця загалом була нормальною: виконавець на зв’язку, основний функціонал реалізовано.

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

Також строки виконання були суттєво зміщені від початково погоджених.

Рекомендую на старті чітко фіксувати критерії завершення задачі, підхід до тестування (особливо без staging) і що входить у виправлення після здачі.

Проєкт має нерівномірну якість кодової бази, що впливає на стабільність і передбачуваність змін.

Клієнт приділяє значну увагу якості та активно тестує продукт, однак очікування щодо результату не завжди були чітко зафіксовані на етапі постановки задач.

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

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

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

Оптимальний формат роботи — чітко описані вимоги, зафіксовані умови приймання і окремо погоджена підтримка після релізу.