4 ознаки, що команда і замовник по-різному розуміють слово «готово»

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

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

Показово, що цей розрив однаково добре відомий і командам, і замовникам окремо — просто кожна сторона зазвичай вважає, що проблема на іншому боці. Розробники скаржаться, що замовник «не розуміє, як влаштована розробка» і тому постійно незадоволений очевидно готовими речами. Замовники скаржаться, що команда «звітує про прогрес, який насправді не відчувається». Обидві скарги правильні одночасно, тому що описують той самий розрив з двох різних боків одного й того самого слова.

Ознака перша: «готово» для команди означає «код працює», а для замовника — «я можу цим користуватись»

Найпоширеніший розрив у розумінні слова «готово» — суто визначенням завершеності. Для розробника функціонал готовий, коли код написаний, протестований і не падає на очевидних сценаріях. Для замовника той самий функціонал готовий, коли він особисто може відкрити продукт і зробити те, що йому потрібно, без пояснень і без «це ще треба донастроїти». Між цими двома станами може бути ціла прогалина — відсутній зрозумілий інтерфейс, не підключені реальні дані, не написана інструкція, — і жодна з цих речей не входить у технічне визначення «готово», але прямо входить у замовницьке.

Розрив непомітний саме тому, що обидва визначення звучать однаково простим словом. Команда чесно репортує «готово» — і чесно має на увазі свою частину роботи. Замовник чує те саме слово і будує на ньому власні очікування, які ніхто явно не звіряв.

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

Ознака друга: демо показує процес, а замовник оцінює результат

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

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

Ознака третя: «готово на 80%» означає для команди і замовника абсолютно різні 80%

Третя ознака — оцінка ступеня готовності в процентах чи частках. Коли команда каже «готово на 80%», вона зазвичай має на увазі обсяг виконаної технічної роботи: скільки з запланованих задач закрито. Замовник чує ту саму цифру і уявляє собі 80% готового досвіду користування продуктом — тобто щось, що вже майже повністю відтворює фінальний вигляд і поведінку.

Проблема в тому, що ці дві шкали не лінійні одна відносно одної. Останні технічні 20% часто включають саме ту частину роботи, яка найбільше впливає на відчуття «завершеності» з погляду користувача, — обробку помилок, дрібні деталі інтерфейсу, крайні випадки. Тому «80% технічно» цілком може виглядати як «40% готового досвіду», і коли ця різниця раптово стає видимою наприкінці проєкту, замовник відчуває себе обманутим, хоча цифра, яку йому називали, технічно була правдивою.

Це той самий ефект, який добре відомий у будь-якій роботі, де основний обсяг часу йде не на створення, а на шліфування: перші 80% результату дійсно можна зробити відносно швидко, а останні 20% — ті, що відрізняють робочий прототип від продукту, яким можна користуватись, не думаючи про нього, — забирають непропорційно багато часу саме тому, що складаються з дрібних, малопомітних деталей, кожна з яких окремо здається незначною.

Ознака четверта: «готово» не супроводжується узгодженим способом перевірки

Четверта ознака — найпростіша для виявлення і водночас найчастіше пропущена. Коли команда репортує «готово», рідко хтось заздалегідь домовляється, як саме замовник має це перевірити: що конкретно він має відкрити, натиснути, ввести, щоб побачити результат. Без цього замовник або довіряє слову на слово (і розрив виявляється пізніше), або починає перевіряти навмання — тестує сценарії, які команда взагалі не мала на увазі, і знаходить «баги» там, де насправді просто не так користується продуктом, як планувалось.

Обидва варіанти шкідливі по-своєму. Перший відкладає розрив у розумінні на потім, коли виправити його дорожче. Другий створює хибне враження, що продукт менш готовий, ніж є насправді, і псує довіру без реальної на те причини.

Чому саме слово «готово» стає точкою розриву частіше за інші

Показово, що жодна із цих чотирьох ознак не пов’язана з нечесністю чи недбалістю жодної зі сторін. Команда і замовник використовують одне й те саме коротке слово, тому що воно зручне й швидке, — і саме ця зручність ховає під собою те, що кожна сторона вкладає в нього своє, специфічне для власної ролі значення. Довші, конкретніші формулювання («технічно реалізовано», «готово до показу користувачам», «готово до продакшену») природно розділили б ці значення, але в щоденній комунікації команди майже завжди скорочують до одного зручного слова.

Що можна змінити в самій комунікації

Перше — замінити слово «готово» на кілька окремих, явно названих станів: технічно реалізовано, готово до внутрішнього перегляду, готово до показу замовнику, готово до продакшену. Коли для кожного стану є окрема назва, сторони перестають плутати одне з одним те, що насправді є різними етапами.

Друге — до кожного демо додавати короткий, заздалегідь узгоджений сценарій перевірки: три-п’ять конкретних кроків, які замовник може повторити сам, а не покладатись на візуальне враження від показу. Це усуває розрив між «процесом, який показує команда» і «результатом, який оцінює замовник» — обидва тепер дивляться на той самий конкретний сценарій.

Третє — при оцінці прогресу в процентах одразу уточнювати, до чого саме відноситься ця цифра: до обсягу запланованих технічних задач чи до відчуття завершеності готового досвіду. Це різні шкали, і називати їх однією цифрою без уточнення — гарантований спосіб отримати розчарування на фінальному етапі, коли розрив між шкалами стає видимим найдорожче.

Короткий чекліст перед тим, як звітувати про готовність

Перш ніж написати замовнику слово «готово», є сенс пройти чотири пункти, симетричні до ознак вище:

• Чи зрозуміло, яке саме значення слова «готово» мається на увазі — технічна реалізація чи готовий досвід користування?
• Чи узгоджено заздалегідь, як саме замовник перевірить результат — конкретний сценарій, а не загальне враження від демо?
• Якщо називається відсоток готовності — чи уточнено, до якої саме шкали він відноситься?
• Чи є в замовника прямий і безпечний спосіб сказати «мені щось не подобається» одразу на демо, а не мовчки нести це враження до наступної зустрічі?

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