Доверие клиента: почему оправдываться за часы — уже проигрыш
Если на встрече заказчик разбирает каждую строчку оценки и спрашивает, почему тут 15 минут, а не 10, — значит, доверия нет. Я собрал семь правил, которые помогают вернуть доверие клиента: объяснять без посредника, отчитываться каждую неделю, работать по фиксу и потом переходить на T&M, встречаться офлайн.
Сидите на встрече и разбираете каждую строчку:
— «почему тут 15 минут, а не 10????»
— «что сложного в установке модуля??? куда там 5 часов»
Вы оправдываетесь за каждые полчаса. Игра в кошки мышки, где и кошка и мышь уже проиграли.
Как вернуть доверие клиента: что мы делаем
1. Заказчик спросил про 15 минут — значит, его это волнует. Разберись, объясни, покажи. Без увиливания и «да мы тут ерундой не занимаемся».
Когда доверие заказчика не построить
2. Со всеми не сработаться. Есть те, кто не умеет доверять совсем.
Я как-то на первом звонке 30 минут объяснял, почему обновлении версии занимает 10 часов, а не час: «там же пару кнопок нажать, вы же проффессионал». После 8 часов диалогов пришлось отказаться от работы. Позже мы в отзывах на хх.ру узнали что заказчик терроризирует сотрудников.
Так же есть и подрядчики, которые настолько странно себя ведут, что им патологически нельзя довериться.
3. Убери посредника. Да проджект договорится лучше, ок. Но почему задача стоит столько — объясняет тот, кто делал. Без испорченного телефона. И да, разработчики тоже умеют нормально презентовать решения.
Еженедельные отчёты для заказчика
4. Отчитывайся каждую неделю. Когда работа видна каждую неделю. Становится понятно, что работали над безопасностью и ловили корнер-кейсы, а не просто 40 часов в задачу напихали.
Fix price или Time and Material
5. Работай по фиксе. Дороже для всех, зато спокойно: за эти деньги — вот этот функционал. Доверие появилось — переходите на T&M.
6. Оффлайн встречайся. Найдите бюджет раз в год прилететь к заказчику и поговорить очно. Про совместные рестораны, бани молчу, хотя и это хорошо. Но очень сложно доверять квадратику в зуме.
7. Спрашивай зачем. Искрене старайся сэкономить бюджет и быстрее решить задачу. Если видишь, что просят фигню — скажи об этом. И да, дело бывает неблагодарное. Могут и нафиг послать, а ты старался, но иначе ты просто руки, а рукам не доверяют.
Есть совет «не работайте с мудаками» — это плохой совет, лучше разберитесь почему на той стороне возникло недоверие и что вокруг не мудаки, а такие же замученные люди со своими проблемами.
Откуда берётся недоверие к оценке в часах
Заказчик видит в смете строку «установка модуля — 5 часов» и не видит, что за ней стоит. Для него это пара кнопок в админке. Для разработчика — проверка совместимости с версией CMS, настройка, перенос на тестовый стенд, прогон сценариев, выкладка на прод и откат, если что-то сломалось.
Вторая причина — прошлый опыт. Если предыдущий подрядчик оценил задачу в 10 часов, а списал 30, следующую смету будут читать с лупой. Третья — посредник: менеджер пересказывает слова разработчика своими словами, по дороге теряются детали, и ответ звучит как отговорка.
Проверка каждой строки — симптом. Лечить надо прозрачность.
Как объяснить заказчику, из чего состоит оценка
Самый частый спор — о том, почему задача на одну кнопку стоит день. Помогает декомпозиция: оценка разбивается на этапы, и у каждого этапа своя цифра. Тогда обсуждают не «почему так дорого», а конкретный пункт.
- Анализ и уточнение требований: вопросы, сценарии, согласование.
- Разработка: сам код, миграции базы, настройка интеграций.
- Код-ревью: второй разработчик читает изменения перед слиянием.
- Тестирование: позитивные сценарии и корнер-кейсы, регресс соседних функций.
- Выкладка: сборка, деплой, проверка на проде, план отката.
- Документация и передача: описание изменений для поддержки.
Трёхточечная оценка вместо одной цифры
Для крупных задач я предпочитаю диапазон. Метод PERT считает ожидаемый срок по формуле (O + 4M + P) / 6, где O — оптимистичная оценка, M — наиболее вероятная, P — пессимистичная. Задача с оценками 4, 6 и 14 часов даёт 7 часов ожидания.
Диапазон честнее точной цифры. Он сразу показывает заказчику, где сидит риск, и даёт повод обсудить, как его снять до старта работ.
Fix price или Time and Material: сравнение моделей
Модель оплаты влияет на доверие сильнее, чем кажется. При фиксе спорить о часах бессмысленно: заказчик платит за результат, а риск перерасхода несёт подрядчик. Поэтому фикс дороже: в цену закладывается буфер на неизвестное.
| Параметр | Fix price | Time and Material |
|---|---|---|
| Что фиксируется | Объём функционала и бюджет | Ставка часа, объём гибкий |
| Кто несёт риск перерасхода | Подрядчик | Заказчик |
| Цена для заказчика | Выше из-за буфера на риски | Ниже, оплачиваются фактические часы |
| Изменения по ходу | Через допсоглашение и переоценку | Через бэклог, без пересогласования договора |
| Когда подходит | Первый проект, понятное ТЗ | Долгая работа, доверие уже есть |
Когда переходить с fix price на T&M
Сигнал простой: заказчик перестал разбирать сметы построчно и спрашивает про сроки, а не про часы. Обычно это происходит после двух-трёх сданных этапов. Переход стоит закрепить в договоре: ставка, лимит часов в месяц, формат отчёта и порог, после которого нужно согласие на перерасход.
Еженедельный отчёт: что в нём показывать
Отчёт раз в неделю работает, только если его можно прочитать за пять минут. Таблица из Jira на 200 строк никому не помогает.
- Что сделано за неделю — по задачам, человеческим языком.
- Сколько часов ушло и сколько осталось по оценке.
- Что пошло не по плану и почему: найденный баг, внешний сервис, уточнение требований.
- Какие решения нужны от заказчика и к какому сроку.
- План на следующую неделю.
Демо вместо таблицы часов
Короткая демонстрация на 15 минут убеждает лучше любого отчёта. Заказчик видит работающую функцию, задаёт вопросы разработчику напрямую и понимает, куда ушли 40 часов: на обработку ошибок платёжки, на права доступа, на граничные случаи.
Ошибки подрядчика, после которых доверие заказчика не вернуть
Любой из этих пунктов выглядит мелочью. Вместе они превращают проект в ту самую игру в кошки-мышки, где каждые полчаса приходится защищать.
- Молча превысить оценку и сообщить об этом в конце месяца.
- Отвечать на вопрос о сроках общими словами без даты.
- Прятать разработчика за менеджером, когда нужен технический ответ.
- Делать задачу, смысл которой непонятен, не задав ни одного вопроса.
- Спорить о каждом замечании вместо того, чтобы показать, как устроено решение.
Вопросы и ответы
Как завоевать доверие заказчика в разработке?
Объяснять оценку честно и без увиливания, давать слово тому, кто делал задачу, отчитываться каждую неделю и хотя бы раз в год встречаться с заказчиком очно. И спрашивать, зачем нужна задача: иначе ты просто руки, а рукам не доверяют.
Что выбрать: fix price или time and material?
Пока доверия нет, работайте по фиксу: дороже для всех, зато спокойно — за эти деньги вот этот функционал. Когда доверие появилось, переходите на T&M.
Что делать, если заказчик не доверяет совсем?
Есть люди, которые не умеют доверять. Однажды после 8 часов диалогов мне пришлось отказаться от работы. Но чаще стоит разобраться, почему на той стороне возникло недоверие.