«Неадекватний клієнт» — 4 патерни комунікації, які найчастіше створює сама команда, а не замовник

Мене звати Сергій Герус. Я консультую власників і керівників IT-компаній з питань перемовин і комунікації з клієнтами — переважно в аутстаф- та dev-агенціях, де пряме спілкування із замовником лягає не тільки на окремий відділ, а й на тімлідів, PM і самих розробників. І майже в кожній команді, з якою я працюю, рано чи пізно зринає одна й та сама фраза: «нам просто дістався неадекватний клієнт».

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

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

Патерн перший: вимоги, що постійно змінюються

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

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

Патерн другий: клієнт мовчить після дедлайну

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

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

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

Патерн третій: скоуп, що непомітно розповзається

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

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

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

Патерн четвертий: тиск на дедлайн від людини, яка сама змінила вимоги

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

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

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

Чому «складний клієнт» — зручний, але хибний діагноз

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

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

Короткий чекліст перед стартом проєкту

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

• Чи зафіксовано письмово, за яким критерієм сам замовник (і, за потреби, його власне керівництво) визначатиме, що результат відповідає очікуванням?
• Чи узгоджено заздалегідь, скільки часу є нормою для відповіді на пред’явлений етап роботи, перш ніж мовчання варто уточнювати прямим питанням, а не мовчки тлумачити?
• Чи переказав сам замовник своїми словами, що саме він розуміє під погодженим обсягом роботи, — а не тільки команда зафіксувала технічний скоуп своєю мовою?
• Чи з’ясовано, перед ким замовник особисto звітує за дедлайн проєкту, і які проміжні результати варто показувати саме цій стороні?

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