Приймання проєкту в більшості замовників виглядає однаково. Розробник надсилає посилання й пише «готово». Замовник відкриває сайт чи систему, хвилин двадцять натискає на кнопки, знаходить кілька друкарських помилок, радіє, що головна сторінка виглядає як на макеті, і підписує акт. За місяць зʼясовується, що за сотні одночасних користувачів усе падає, що звіт для бухгалтерії рахує ПДВ неправильно, що в коді немає жодного тесту, а новий підрядник, якого покликали на доопрацювання, каже: «Це простіше переписати». Гроші вже сплачено, акт підписано, і розмова з першим виконавцем стає дуже незручною.
Я багато років перебуваю по обидва боки цього процесу: і здаю проєкти, і приймаю чужі на прохання клієнтів. І можу сказати, що приймання це не «потицяти в кнопки». Це останній момент, коли у Вас є важіль. Після підпису акта важеля немає.
Приймання як техогляд, а не тест-драйв
Коли Ви купуєте вживаний автомобіль, тест-драйв каже Вам дуже мало. Машина заводиться, їде, музика грає, кондиціонер дме. Усе, що справді важливо, ховається під капотом і під днищем: стан двигуна, іржа, сліди ремонту після аварії. Тому розважливі люди везуть машину на станцію техогляду, де механік піднімає її на підйомник і дивиться туди, куди покупець сам не зазирне.
Програмна система влаштована так само. Інтерфейс це кузов і салон. Він може бути бездоганним, а під ним може лежати архітектура, яка не витримає зростання, база даних без індексів, паролі у відкритому вигляді й код, якого не розуміє навіть його автор. Тест-драйв (клацнути по екранах) потрібен, але його недостатньо. Потрібен ще й техогляд.
Три рівні перевірки
Я ділю приймання на три рівні, і кожен відповідає на своє питання.
Перший рівень: приймальні тести, або UAT (User Acceptance Testing). Питання: чи робить система те, що було обіцяно? Тут Ви берете технічне завдання й проходите сценарії один за одним. Не «подивитися, як виглядає замовлення», а «створити замовлення на три позиції зі знижкою, оплатити частково, повернути одну позицію, перевірити залишок на складі й суму у звіті». Добрі сценарії пишуть заздалегідь, ще на етапі ТЗ, і тоді приймання перетворюється на чек-лист, а не на імпровізацію. Якщо сценаріїв у ТЗ немає, маю для Вас погану новину: приймати немає за чим, і суперечка буде про смаки.
Другий рівень: код-ревʼю. Питання: чи можна цю систему підтримувати й розвивати? Тут потрібен зовнішній експерт, не той, хто писав код. Він дивиться на структуру проєкту, якість коду, наявність тестів, документацію, безпеку. Він не чіплятиметься до стилю, якщо все інше гаразд, але одразу побачить, якщо вся бізнес-логіка живе в одному файлі на десять тисяч рядків. Це коштує грошей, але незрівнянно менше, ніж переписування за рік.
Третій рівень: навантажувальне тестування й перевірка відмовостійкості. Питання: чи витримає система справжнє життя? Двадцять користувачів на демо й тисяча в понеділок зранку це різні системи. Навантажувальний тест імітує реальний трафік і показує, де вузьке місце. Сюди ж належить перевірка резервного копіювання: не «бекапи налаштовано», а «ми відновили систему з бекапу на чистому сервері, і вона запрацювала».
Де губляться гроші
Бюджет на прийманні губиться не через злий умисел виконавця, а через розмиті домовленості. Найчастіші випадки з моєї практики такі.
- Немає критеріїв готовності. Якщо в договорі написано «розробити модуль продажів», то будь-який модуль продажів формально готовий. Критерії треба фіксувати сценаріями й цифрами: час відгуку, кількість користувачів, перелік звітів.
- Передоплата за все. Поетапна оплата з прийманням кожного етапу дає Вам важіль протягом усього проєкту, а не лише наприкінці.
- Код і доступи у виконавця. Якщо репозиторій, сервер і домен зареєстровано на підрядника, Ви приймаєте не систему, а обіцянку.
- Гарантійний період не обумовлено. Баги будуть, це нормально (я докладно писав про це в окремій статті). Важливо, щоб було записано, хто й у який строк виправляє помилки, знайдені після приймання.
Акт приймання це не подяка виконавцеві. Це документ, після якого Ваші претензії стають проханнями.
Як приймати проєкт завтра
Якщо проєкт уже на фініші, а Ви не закладали нічого з переліченого, не панікуйте. Зробіть мінімум. Попросіть у виконавця список сценаріїв, за якими він сам перевіряв систему, і пройдіть їх особисто. Додайте до них пʼять сценаріїв із Вашої реальної роботи, особливо тих, де беруть участь гроші. Переконайтеся, що код лежить у Вашому репозиторії й Ви можете увійти на сервер. Замовте незалежне код-ревʼю хоча б на кілька днів роботи експерта. І підписуйте акт лише після того, як виправлено все, що зупиняє гроші, а решту зафіксовано окремим списком зі строками.
Ми в Ingello проводимо такий аудит і для чужих проєктів, і, чесно кажучи, це одна з найкорисніших послуг, які ми робимо: часто два дні перевірки заощаджують клієнтові місяці майбутніх проблем. А у своїх проєктах ми закладаємо приймальні сценарії ще на етапі проєктування, щоб наприкінці не було сюрпризів ні в клієнта, ні в нас. Приймайте з розумом, колеги, і нехай під капотом буде так само гарно, як у салоні.
