Клієнт просить «додати функцію»: як знайти справжню потребу

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

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

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

Короткий словник

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

Коротко: що робити, коли клієнт просить «додати функцію»

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

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

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

Запит-рішення чи запит-задача: як відрізнити за формулюванням клієнта

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

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

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

Питання, які ставлять до того, як малювати схему процесу

Три питання закривають майже всі прогалини, які інакше виявляються вже на запуску.

Який ризик потрібно перевірити

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

Якщо клієнт відповідає «ну, усе важливе», питання варто повторити на конкретних випадках з його ж роботи: візьміть два останніх договори й спитайте, який з них потребував фахової перевірки та чому.

Який матеріал потрібен фахівцям, щоб ухвалити рішення

Людина не може відповідати за рішення, якщо не бачить даних для нього. Фінансист дивиться умови оплати, знижку й історію розрахунків клієнта. Юрист дивиться умови договору та відхилення від стандартного шаблона. Якщо цих полів немає у формі, фахівці добиратимуть їх у переписці, і процес піде в обхід системи.

Яка версія документа підписується після правок

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

Висновок завжди належить конкретній версії документа. Якщо після правок система лишає попередній результат перевірки, повний набір етапів втрачає сенс: підписують уже інший текст, ніж той, який перевіряли.

Розкладаємо запит на три аспекти

Будь-який розмитий запит розкладається на три частини. Рамка робоча для узгодження договорів, для заявок із сайту й для запитів про штучний інтелект.

Класифікація ризику: від слова «ризик» до конкретних умов

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

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

Межі повноважень: хто і що саме перевіряє

Межі повноважень прибирають дві протилежні проблеми: дублювання, коли двоє перевіряють одне й те саме, і прогалини, коли щось не перевіряє ніхто.

• Фінансист. Відповідає за умови оплати, знижку, повернення коштів і кредитний рейтинг клієнта.
• Юрист. Відповідає за умови договору й відхилення від стандартного шаблона.
• Керівник напряму. Відповідає за рішення по суті угоди: чи варта вона тих умов, на які компанія йде.
• Адміністратор. Налаштовує процес і права доступу, рішень за фахівців не ухвалює.

Окреме правило: автор запиту не узгоджує сам себе. Воно виглядає очевидним, поки в системі не зʼявляється керівник, який подає заявку й сам її погоджує.

Відстеження відповідальності: хто ухвалив рішення і на основі чого

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

Як той самий метод працює на ШІ-запитах

Запити про штучний інтелект розкладаються так само, просто ризик у них інший.

«Додайте ШІ в чат»

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

Межі повноважень тут означають перелік тем, на які асистент відповідає сам, і перелік тем, де він передає діалог людині. Відстеження відповідальності означає збережену історію: що саме асистент відповів клієнту й на основі яких даних. Чому надійність такого процесу залежить від контролю, а не від вибору моделі, ми розбирали в матеріалі про три рівні контролю для ШІ-агентів.

«Автоматизуйте звіти»

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

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

Варіанти рішення і ціна кожного

Коли вимоги зібрані, залишається вибрати маршрут. Варіантів зазвичай три.

Послідовна перевірка: просто налаштувати, довго чекати

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

Одночасна перевірка: швидше, але потрібне правило для суперечливих висновків

Фахівці дивляться документ паралельно, і час очікування меншає. Натомість зʼявляється нова проблема: висновки повертаються не разом, і рано чи пізно вони суперечать один одному. Юрист каже, що умови прийнятні, фінансист каже, що строк оплати завеликий. Якщо правило про остаточне рішення не записане заздалегідь, паралельна перевірка просто показує конфлікт раніше.

Розгалуження за умовами ризику: різні маршрути для різних випадків

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

Третій варіант обирають частіше за інші, бо він єдиний відповідає на питання, які випадки справді потребують фахової перевірки.

Мінімальний робочий варіант: правила, які варто закласти одразу

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

• Автор запиту не узгоджує сам себе. Інакше правило повноважень існує лише на папері.
• Повернення на доробку вимагає вказаної причини. Без цього причини неможливо згрупувати, а отже й виправити.
• Зміна версії документа запускає перевірку умов заново.
• Прострочення спершу нагадує виконавцю, а потім передає рішення далі.
• Перевіряльника поза маршрутом додають тільки як виняток із вказаною причиною.

Чому висновок привʼязують до версії документа

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

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

Прострочення, відпустка, звільнення: кому переходить рішення

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

Чого свідомо не робимо в першій версії

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

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

Як зафіксувати домовленість письмово, щоб не починати заново

Після розбору запиту надішліть клієнту короткий документ: яку проблему закриваємо, які умови ведуть на фахову перевірку, хто що перевіряє, що в першу версію не входить. Одна сторінка. Через місяць цей текст заощадить вам зустріч, бо памʼять учасників розходиться швидше, ніж здається.

Такий документ корисний навіть тоді, коли клієнт не відповів на лист. Він фіксує момент, коли ви описали ціну рішення, і далі розмова йде про зміни до вже описаної домовленості.

Коли клієнт наполягає на своєму варіанті

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

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

Промпти для ШІ-асистента, які допомагають розкласти розмитий запит

ШІ-асистент непогано працює співрозмовником на етапі розбору. Своїх повноважень і доступних полів у вашій системі він не знає, тому чернетку перевіряє фахівець. Але витягнути з фрази клієнта питання, які ви забули поставити, він здатен.

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

Другий промпт стане в пригоді після зустрічі, коли нотатки є, а структури в них немає.

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

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

Як перевірити результат метриками після запуску

Намальована схема ще не результат. Результат видно на показниках за перші тижні роботи.

Що саме змінювати за кожним показником

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

За незадовільного результату наступним кроком не обовʼязково є нові перевіряльники в процесі. Частіше допомагає звузити умови, додати поля або перенести частину перевірок на момент подання заявки.

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