Якщо ви клацнули на цю статтю, ви, мабуть, уже стикалися з моментами, коли пояснити щось клієнту було складніше, ніж налаштувати саму систему.
Аналітика демонструє:
- 86% працівників і керівників називають погану комунікацію головною причиною невдач на роботі;
- 53% співробітників кажуть, що неправильне спілкування напряму призводить до проблем у проєктах;
- 44% працівників звільняються через постійні непорозуміння та конфлікти.
Тож цей виклик треба долати. Нумо наповнюватись теорією та дивитись, яких практик дотримуватись, щоб аргументувати свою роботу впевнено.
Чи має DevOps-інженер спілкуватись із клієнтами
Часто панує думка, що DevOps — це лише про Docker-контейнери, налаштування CI/CD пайплайнів, моніторинг чи написання скриптів автоматизації.
Але DevOps-інженер не працює у вакуумі. Щоб продукт релізився швидко й не падав від напливу користувачів, він має постійно синхронізуватися зі своїми колегами. Налагодження цих містків всередині — це вже 50% успіху проєкту.
→ До речі, про те, як правильно побудувати спілкування всередині технічної команди, щоб ніхто нікого не випалював, ми вже детально розписали в нашій статті: Як ефективна комунікація будує успішні DevOps-проєкти.
А от що робити з клієнтами?
Тут може виникнути логічне обурення: «Зачекайте. Хіба презентації, захист бюджетів та розмови з бізнесом — це не робота СТО чи Project Manager? Чому я маю йти на мітинг і щось доводити людині, яка не відрізняє Kubernetes від кіберспорту?»
Звучить справедливо, але те, що DevOps-фахівець спілкується з клієнтом — абсолютно нормальна і навіть здорова практика. Ось чому так стається:
- PM чудово знає бізнес-цілі, але не знає технічних нюансів вашої архітектури. Якщо клієнт запитає: «Чому ми платимо за AWS так багато і чи можна це урізати вдвічі?», менеджер не зможе повноцінно пояснити ризики. Йому потрібне першоджерело — тобто ви.
- Коли бізнес інвестує великі гроші в інфраструктуру, йому важливо почути впевнений голос людини, яка цією інфраструктурою керує. Ваша присутність на зідзвоні додає компанії авторитету, а клієнту — спокою.
- Замість того, щоб тиждень пересилати листи за маршрутом Клієнт → PM → DevOps → PM → Клієнт, простіше зробити 15-хвилинний зідзвон і вирішити долю рефакторингу прямо зараз.
Тож розмови з клієнтами — це не додаткове навантаження, яке на вас скинули, бо менеджерам ліньки. Це ознака вашої зрілості як спеціаліста. Питання лише в тому, як не боятися цих мітингів і говорити так, щоб вас почули.
Найбільші помилки при комунікації з клієнтом
У більшості випадків комунікація ламається саме через якийсь із цих сценаріїв. Вони здаються непомітними для інженера, але для клієнта є червоними прапорцями.
1. Надлишок складного технічного сленгу
«Нам треба переписати Dockerfile, бо там забагато шарів, оптимізувати Kubernetes-маніфести, налаштувати Helm-чарти і розібратися з таймаутами в Іngress-контролері».
Чому це помилка?
Клієнт зрозумів приблизно нічого. Пам’ятайте, що (найчастіше) ви спілкуєтесь із нетехнічною людиною. А коли людина нічого не розуміє, то відчуває дискомфорт і захищається єдиним доступним способом — каже «ні».
Бізнес не повинен вчити архітектуру, щоб купувати ваші рішення. Його мова — це результати, ризики та цифри.
2. Залякування без пропозиції рішень
«Система зараз у дуже поганому стані, все нестабільно, сервери перевантажені, і будь-якої миті може все впасти — включно з базою даних і всіма користувацькими даними.»
Чому це помилка?
Емоційний тиск без чіткого плану дій викликає у клієнта лише роздратування або паніку. Замість того, щоб побачити у вас надійного інженера, він бачить людину, яка не контролює ситуацію.
Клієнт мислить категоріями «проблема → варіанти вирішення → ціна запитання». Якщо приносите проблему — одразу додавайте до неї план дій.
3. Аргументація «бо так правильно»
«Нам потрібно перейти з наявного рішення на нове, бо так буде краще і зараз так роблять усі».
Чому це помилка?
Будь-яке абстрактне «так треба» повинно мати фінансове або операційне обґрунтування. Наприклад, на скільки відсотків це зменшить ризик простою, скільки це зекономить грошей або що втратить клієнт, якщо залишиться на старому рішенні.
4. Приховування проблем до останнього
«Ми випадково перевищили бюджет на AWS на $2000 через невимкнені тестові сервери. Ми вже все вимкнули, просто рахунок прийде великий…»
Чому це проблема?
Помилятися — неприємно, але природно. І вам потрібно зрозуміти, що про ваш фейл і так рано чи пізно дізнаються. А от заплатити рахунок на $200/$800/$2000 менше — набагато краще.
Як долати супротив замовника та пояснювати складне
Коли клієнт каже «ні» або не розуміє ваших пропозицій, це не означає, що він налаштований проти команди чи проєкту. Найчастіше це звичайна захисна реакція на невідомість або страх перевищити бюджет.
Ось кілька типових сценаріїв та порад, як їх повернути у потрібне русло.
1. На проєкті потрібно щось змінити, але клієнт відмовляється
Замовник може бачити, що застосунок чудово виконує свої функції, тому щиро не розуміє, навіщо виділяти час та ресурси команди на умовну автоматизацію. Проте, якщо це не зробити, то за найменшого стрибка трафіку (наприклад, під час чорної п’ятниці) сайт впаде, а компанія втрачатиме тисячі доларів щохвилини, поки інженери підніматимуть усе вручну.
В такій ситуації важливо посунути складні технічні пояснення. Натомість подумайте, як пояснити це через призму бізнесу та фінансових ризиків. Наприклад:
- Замість: «Нам потрібно терміново переписати заплутану архітектуру і налаштувати нормальні CI/CD пайплайни, бо у нас величезний техборг і деплоїти кожну фічу стає дедалі важче».
- Скажіть: «Зараз ми випускаємо нову фічу за 3 дні. Якщо не зробити рефакторинг інфраструктури зараз, то за місяць розробники витрачатимуть на ту саму роботу тиждень. Ми або інвестуємо трохи часу в автоматизацію зараз, або потім постійно переплачуватимемо.»
2. Клієнт вимагає урізати бюджет, бо це дорого
Замовники дивляться на щомісячні рахунки від AWS і бачать там лише великі цифри, які хочеться скоротити для оптимізації витрат. Категорична відмова інженера може викликати підозру.
Дайте клієнту право вибору, але чітко перекладіть на нього відповідальність за наслідки. Наприклад:
- Замість: «Ми не можемо зменшити рахунок на $500, тому що нам потрібні всі ці сервери та резервні бази даних для забезпечення високої доступності системи».
- Скажіть: «Ми можемо оптимізувати витрати двома шляхами. Перший: вимикаємо тестові контури вночі — це збереже 15% бюджету без жодних ризиків для продукту.
Другий: відмовляємося від резервного сервера і економимо ще 20%, але якщо основний сервер ляже, сайт буде повністю недоступний кілька годин, поки я підніматиму все з нуля. Який шлях обираємо?»
3. Клієнт ігнорує ризики та методи їх уникнення
Замовник може вважати, що система безпечна, бо не зіштовхувався зі збоями (поки що). Тому рішення з моніторингом сприймається скептично, бо ви і так чудово без нього жили.
В такій ситуації марно лякати абстрактними хакерськими атаками. Спробуйте візуально зобразити, наскільки часто насправді відбуваються некритичні збої і наскільки більше часу йде на те, щоб їх помітити та полагодити
Приклад візуального порівняння:
- Сценарій А (Як ми живемо зараз): Стався мікрозбій (відвалився один платіжний шлюз) ➔ Пройшло 3 години ➔ Користувачі помітили баг і написали в саппорт ➔ Саппорт передав PM ➔ PM прийшов до DevOps ➔ DevOps 2 години перебирав логи вручну, щоб знайти причину. Разом: 6 годин на вирішення.
- Сценарій Б (Як буде з моніторингом): Стався мікрозбій ➔ Через 10 секунд система Grafana зафіксувала аномалію і скинула алерт у Slack ➔ DevOps одразу бачить конкретний графік, що впав, і за 10 хвилин виправляє проблему ще до того, як клієнти взагалі щось помітили. Разом: 10 хвилин на вирішення.
Швидкі поради для впевненості на зідзвонах
- Підготовка візуальних артефактів: заздалегідь малюйте прості схеми (наприклад, у Miro) або робіть скріншоти графіків, бо нетехнічні клієнти погано сприймають складну архітектуру на слух.
- Розробка компромісного «Плану Б»: завжди майте в запасі мінімальний варіант вирішення задачі на випадок, якщо клієнт заветує повноцінний спринт через брак часу чи грошей.
- Тайм-аут для складних відповідей: якщо замовник ставить каверзне фінансове чи бізнесове питання, не вигадуйте цифри, а спокійно візьміть годину на аналітику та перевірку конфігурацій.
- Фіксація підсумків: одразу після мітингу надсилайте у Slack короткий текст із погодженими рішеннями, щоб зафіксувати зону відповідальності та уникнути непорозумінь у майбутньому.
- Демонстрація проміжних результатів: показуйте користь від своєї роботи маленькими кроками (наприклад, «тепер білд збирається на 5 хвилин швидше»), щоб клієнт бачив динаміку, а не чекав фіналу місяцями.
Підсумуємо
Головний секрет успішних переговорів — ставити себе на місце клієнта. Доносьте кожну думку через його призму реальності, де головним є стабільність бізнесу, безпека й репутація та бюджет.
Проте пам’ятайте: на одних софт скілах далеко не заїдеш. Щоб впевнено захищати свої рішення перед замовником, потрібно впевнено керувати технічними навичками.
Якщо вашим хард скілам потрібен потужний апгрейд, прокачайте їх на курсах від ITEDU. Сильна технічна база у поєднанні з вмінням говорити мовою бізнесу перетворить вас із рядового виконавця на незамінного стратегічного партнера.