Как я вычисляю трудного клиента ещё до старта проекта
Два года назад я взял проект, в котором с первого звонка было три признака, которые я уже умел распознавать. Взял, потому что деньги были хорошие, а я сказал себе: «Справлюсь». Четыре месяца спустя я выходил из этого проекта — нормально, без скандала, но с ощущением, что потратил время на работу, которую надо было не брать.
Не худший опыт, нет. Но именно после него появился чеклист.
Почему первый разговор — это уже техническое решение
Разработчики привыкли принимать решения в коде. Выбор библиотеки, архитектурный паттерн, когда начинать рефакторинг. Но самое дорогое решение в проекте принимается до первого коммита: берёшь ты этого клиента или нет.
Я закрываю риски, не тикеты. Это значит: перед тем как написать первую строчку кода, я пытаюсь понять, какие риски несёт контрагент. Не только технические. Поведенческие.
Первый звонок, первое письмо, сам бриф — это данные. Их можно читать.
Как звучит бриф трудного клиента
Есть несколько формулировок, которые я вижу в брифах регулярно. Они не всегда означают катастрофу, но всегда требуют уточнения.
«Нам нужно срочно» без объяснения почему. Дедлайн через два месяца на задачу, которая минимум четыре — это не требование, это проблема управления ожиданиями, которую клиент пытается переложить на подрядчика.
«Мы уже пробовали, не получилось». Бывает по-разному. Иногда предыдущая команда действительно работала плохо. Иногда — клиент сам сменил задачу в середине проекта, а потом объяснил провал подрядчику. Реакция на вопрос «что именно не получилось?» говорит больше, чем сам факт смены команды.
«Мы хотим переписать всё с нуля». Я слышу это про Bitrix-магазины регулярно. Иногда это правильное решение. Чаще — rewrite fever, за которым стоит не архитектурная необходимость, а усталость от системы. Я однажды отказался от $40K-контракта именно потому, что лог сервера за год не давал оснований для полного rewrite — только для точечного рефакторинга. Подробнее об этом в статье «Я отказался от $40K-контракта».
Три типа трудных клиентов — и что они пишут
За десять лет я вижу три повторяющихся паттерна.
Первый тип я называю «менялами». Это клиенты, у которых уже было два-три подрядчика на похожем проекте. В каждом случае «не справились» или «пропали». В письмах: «мы уже обожглись», «нам важна надёжность», «мы хотим долгосрочное сотрудничество». Последнее звучит как плюс — но в сочетании с историей частой смены команды это сигнал. Вопрос: почему предыдущие три партнёра долгосрочными не стали?
Второй — «знатоки». Они уже знают решение до того, как я начал изучать задачу. «Нам нужен headless на Next.js, Redis, вот список фич». Техническое задание сформулировано как список технологий, а не бизнес-задач. Беда не в том, что они читали про headless. Когда я скажу «эта архитектура не подходит для вашей ситуации» — они услышат «этот разработчик нас не понимает».
Третий — «ускорители». Проект нужен «ещё вчера», любое обсуждение архитектуры выглядит как трата времени. Узнаю по фразам «мы потом разберёмся с документацией», «давайте сначала запустим, а потом почистим». Технический долг создаётся не из-за плохого кода. Он создаётся из-за культуры «сначала запустим».
Первый звонок: я спрашиваю ради реакции, не ради ответа
На первом звонке я задаю три вопроса — и мне важна реакция, не ответ.
«Кто со стороны вашей команды будет финально принимать работу?» Если ответ занимает больше тридцати секунд, или если оказывается, что это несколько человек без единого ответственного — это риск. Согласования по кругу убивают скорость быстрее, чем любые технические проблемы.
«Что будет, если запуск сдвинется на месяц?» Хорошая реакция: конкретный ответ о последствиях, даже если они неприятные. Плохая реакция: «этого не может быть» или мгновенное давление. Когда клиент не может спокойно ответить на гипотетический вопрос о сдвиге — он уже не управляет рисками проекта.
«Как выглядит для вас успешный результат через шесть месяцев?» Этот вопрос делит клиентов на два лагеря. Первые говорят про бизнес-результаты: конверсия, скорость, меньше обращений в поддержку. Вторые говорят про фичи: «вот список, всё из него выполнено». Работать можно с обоими, но по-разному.
Мой чеклист из восьми пунктов перед подписанием
Я прохожу по этим пунктам перед каждым новым контрактом. Не все пункты с весом «красный флаг» — часть из них просто уточняющие.
- Есть ли единый человек, принимающий решения по проекту? Если нет — кто он и есть ли шанс с ним познакомиться до подписания.
- Было ли агентство или разработчик до меня? Если да — что произошло. Реакция на этот вопрос важнее ответа.
- Есть ли письменные требования, хотя бы в виде списка? «Мы всё объясним в процессе» — не подходит для проекта длиннее двух недель.
- Как они говорят о прошлом подрядчике? Если «бездари и мошенники» — я думаю, что скажут обо мне через год.
- Была ли у них реакция на стоимость — и какая? Торг не плохой знак. Плохой знак — когда цена воспринимается как оскорбление или игнорируется совсем.
- Понимают ли они разницу между «готово» и «запущено»? Я спрашиваю напрямую. Технический долг в деньгах — это разговор, который полезно провести до старта.
- Как быстро они отвечают на письма в фазе переговоров? Если ответа на вопрос нет три дня, это не забывчивость. Это темп работы.
- Есть ли у них опыт работы с подрядчиками по IT до этого? Первый цифровой проект требует другого уровня сопровождения. Это не страшно, но надо закладывать время.
Когда сигналы смешанные
Иногда два-три сигнала присутствуют, но у проекта есть настоящая ценность — интересная задача, честный бюджет, живое желание сделать хорошо. Я не отказываюсь автоматически от каждого клиента с красными флагами.
Я проговариваю риски вслух на первом звонке. Не как ультиматум, а как рабочий разговор: «Я вижу, что дедлайн жёсткий, и хочу понять, что произойдёт если мы не успеем». Реакция на этот разговор — сама по себе самый точный фильтр из всех восьми пунктов чеклиста.
Клиент, который готов обсуждать риски до подписания — другой клиент, чем тот, кто уходит от этого разговора.
Итог
Первый звонок — это не продажа. Это диагностика. Я не пытаюсь убедить клиента выбрать меня. Я пытаюсь понять, правильно ли я выбираю его.
Закрыть риск, а не тикет — это значит видеть, откуда приходят реальные потери. Иногда они приходят из плохого кода. Но часто они приходят из того, что проект с неправильным клиентом вообще был начат.