Такий проєкт може здаватися дуже технічним, і у фазі девелопменту це дійсно так. Але усе змінюється на етапі приймання робіт, а він присутній навіть у проєктах, які обрали гнучкий підхід до розробки з регулярними демо клієнтам. Тому що допоки повний реверс коду не завершено, інкременти, які постачає команда, не можуть вважатися фінальними. І тільки коли ціла система готова і інтегрована, можна вести мову про приймання робіт.
Приймати систему, швидше за все, будуть бізнес-користувачі (експерти, які користувалися попередньою системою або тестували її / впроваджували / писали інструкції). Їх завдання - переконатися, що система робить те, що від неї очікується. Однак ця категорія користувачів, цілком ймовірно, може мати дуже поверхневе уявлення про систему, її складові та зв'язки. Можливо, такі користувачі не зможуть вручну перерахувати якісь показники (адже вони давно довіряють старій системі). І навряд чи вони погодяться на перехід в фазу продакшн, поки не упевняться у коректній роботі нової системи.
При цьому саме бізнес-користувачі можуть дати інформацію про бізнес задачі системи. Розповісти, чого в старій системі не було, і з цим мирилися, а в новій -очікують, навіть якщо не говорять про це. Або ж якісь функції старої системи надавав, наприклад, термінал, і, хоча для нього немає вихідного коду, клієнт вважає його частиною системи і очікує на всі його бенефіти у постачанні.
Також необхідно виявити очікування щодо нефункціональних вимог. І відповісти на питання, чому в деяких випадках було зроблено саме таким чином. Це більше стосується технічних експертів, але у клієнта їх може не бути. В таких ситуаціях ми змушені обмежуватися роботою з бізнес-експертами.
Що робити.
Проактивно залучати бізнес експертів до роботи над новою системою. Запитувати бізнес-сценарії, пояснення того, навіщо потрібна сама система і її підсистеми, звіряти знання всіх експертів між собою і з кодом (можливо, уявлення деяких експертів про систему неточні), працювати над формуванням спільного бачення системи.
Якщо старою системою користувалися довго або вона критична для бізнесу, важливо психологічно готувати користувачів до переходу на нову систему, підкреслювати її переваги (наприклад, більшу стабільність), плекати впевненість в новій системі, будувати свою роботу з фокусом на те, як новинку зможе прийняти бізнес користувач.
Але як можна переконати клієнта, що система виконує ті самі задачі з такою самою ефективністю, як і попередня?