🥰 Как я бы советовал строить отношения с заказчиками: 5 правил, которые работают
Ребята, сегодня без технической воды, увы и ах. Поговорим о том, без чего любой инженер, даже самый крутой, останется просто "тем парнем, который что-то там чинит". Я работаю с АБСОЛЮТНО разными заказчиками, из разных сфер, масштабов и прочее. У каждого свои тараканы, свои процессы и своё понимание IT-делов. Но за годы я выработал несколько простых правил, которые помогают строить нормальные, рабочие отношения.
🟣Правило №1: Говорить на языке заказчика Вы когда-нибудь объясняли врачу, почему его система не работает, на языке "у вас там кластер развалился, репликация упала, смотрите лог"? Я - да. И получил в ответ стеклянные глаза. По факту - никто не обязан знать твою профессиональную лексику, если это не его сфера.
Как я делаю сейчас:
- Вместо "слетел SSL-сертификат" - "ваш сайт временно недоступен, потому что закончился срок действия цифровой подписи, я уже обновил, ориентировочно через пару минут всё заработает". Суть: Переводишь техническую проблему на язык последствий и решений. Чтобы заказчик понял: а) что случилось, б) что ты делаешь, в) когда это исправят.
🟣Правило №2: Всегда предлагать альтернативу Не бывает так, что есть только одно решение. Даже если ты уверен, что твой вариант - лучший, заказчик должен чувствовать, что у него есть выбор. Пример из практики: Заказчик хочет обновить всё и сразу. Я говорю: "1) Можно сделать так - сейчас мы обновляем только критичные компоненты (это займёт 2 часа, минимальные риски). А остальное - поэтапно в течение недели. 2) Второй вариант - обновить всё за одну ночь, но тогда нужно согласовать время и остановить те сервисы - которые будет обновлять, сделаем всё за раз, но рисков больше". Заказчик выбирает, чувствует контроль над ситуацией. Даже если выбирает твой вариант - он выбрал его сам и это даёт ему большие "чувства".
🟣Правило №3: Не обещать того, что не можешь сделать Это, казалось бы, очевидно :) Но сколько раз я видел, как коллеги говорят "сделаем за час", хотя знают, что минимум три. А потом заказчик ждёт, не дожидается, начинает нервничать, эскалировать и т.д. Доверие теряется за один такой случай.
Как я делаю:
- Всегда закладываю буфер. Если реально 2 часа, то говорю 3-4. Если сделаю быстрее - заказчик будет приятно удивлён. Если что-то пойдёт не так - у меня есть запас времени.
- Если не знаю, сколько займёт - так и говорю: "Мне нужно посмотреть, я вернусь с ОС "такое-то время".
- Если задача сложнее, чем казалось - сразу предупреждаю: "Я нашёл нюанс, придётся потратить больше времени, давайте скорректируем сроки выполнения задачи". Честность всегда работает лучше, чем сорванный дедлайн. 🟣Правило №4: Признавать ошибки Мы все ошибаемся. Инженеры - особенно. Сложные системы, человеческий фактор, усталость и т.д. Важно не то, что ты ошибся, а то, КАК ты на это реагируешь. Пример: Я случайно применил конфиг к не тому серверу. Заказчик заметил. Вместо "это не я, там система сама слетела" я сказал: "Да, это я случайно применил настройки не на тот хост. Сейчас откатываю, через 10 минут всё вернётся. Извините, впредь буду внимательнее". Заказчик - "Ок, бывает". Всё. Никакого скандала и драммы. Потому что ты не прячешься, а признаёшь и исправляешь свою же ошибку.
🟣 Правило №5: Благодарить Казалось бы, мелочь. Но сколько раз я видел, как люди, да и я сам порой забываю сказать "спасибо" заказчику за то, что он вовремя предоставил доступ или за то, что предупредил о проблеме до того, как она стала аварией.
"Спасибо, что быстро прислали логи". "Спасибо за понимание, тогда мы переносили обновление". Людям приятно, когда их вклад замечают. Даже если этот вклад - просто "прислал логи". Это строит доверие и располагает к тебе.
🩷 Итог: что я вынес Технологии мы прокачаем. Сертификаты получим. А вот умение строить отношения - это то, что останется с тобой навсегда. И запомните: Заказчик - это не враг. Заказчик - это люди, компания - которые доверили тебе свою систему. И если ты не будешь забывать об этом - он будет возвращаться к тебе снова и снова.
