Есть одна идея, с которой я долго не спорил: если работу можно сделать быстрее без потери качества, это преимущество. Заказчик получает результат раньше, исполнитель освобождает время, обе стороны выигрывают.
Один заказ на Kwork показал, что всё не так просто.
Мне поручили комплексный аудит Telegram-бота. Нужно было пройти продукт от первого экрана до оплаты, разобрать меню, тексты, кнопки, уведомления, тарифы, Premium-функции, сценарии возврата пользователя и идеи для роста конверсии. Причём заказчику был нужен не список общих замечаний, а конкретные правки, формулировки и материалы, которые можно передавать разработчику.
К следующему утру я сдал большой пакет файлов. В работе участвовал Codex: он помогал ускорять рутинную часть, структурировать материалы, готовить документы и фиксировать скриншоты. Для меня это был пример того, зачем вообще нужны AI-инструменты в прикладной работе.
Заказчик увидел ситуацию иначе.
В переписке появилась фраза: «С моей стороны это выглядит как халтура, склепанная за один день с помощью нейросети».
В итоге заказ дошёл до спора и завершился частичной оплатой. Часть суммы я получил, часть вернули покупателю.
Это не история о том, как «неправильный клиент не понял AI». Перечитывая переписку сейчас, я вижу ошибки с обеих сторон. И именно поэтому считаю этот кейс полезнее многих заказов, которые закрылись без единого замечания.
Что именно нужно было проверить
Задача выглядела достаточно конкретно. Цель аудита: повысить конверсию, удобство использования и вовлечение аудитории.
Нужно было проверить приветствие и первый экран, меню и навигацию, количество шагов до полезного действия и оплаты, тексты, кнопки и эмодзи, уведомления, тарифы и оформление платных функций. Отдельно заказчик хотел рекомендации по прогреву, догоняющим сообщениям, повторным покупкам и упрощению сценариев.
Ожидался прикладной результат: проблемы, рекомендации, новые формулировки, варианты кнопок и сообщений, идеи по изменению сценариев и последовательные материалы для программиста.
До заказа я уже сделал предварительный разбор и показал несколько проблемных зон. Именно здесь появился первый сигнал, который я недооценил. Заказчик написал, что я тороплюсь: некоторые мои предложения, по его мнению, добавляли лишние действия и могли сами снижать конверсию.
Сейчас я бы на этом месте не продолжал доказывать гипотезу. Я бы зафиксировал её как гипотезу и сначала полностью прошёл соответствующий сценарий.
Почему работа оказалась готова так быстро
После оформления заказа я не начинал с пустого листа. Бот уже был предварительно просмотрен, структура задачи была понятна, а сама работа хорошо раскладывалась на отдельные проверяемые блоки.
Дальше я использовал связку ручного анализа и Codex. Я проходил сценарии и принимал решения, а инструмент помогал там, где раньше пришлось бы тратить время на механическую работу: структурирование замечаний, сбор материалов в документы, подготовку вариантов формулировок, оформление технических блоков и работу со скриншотами.
К следующему утру заказчику были переданы чек-лист, основной отчёт, отдельные материалы для разработчика, перечень ресурсов, версии документов в нескольких форматах и подготовленные сообщения с конкретными изменениями. Позже я добавил отдельный документ с нумерацией и скриншотами проблемных мест.
То есть реальная ситуация выглядела не так:
«нажал кнопку в нейросети и получил готовый аудит».
Она выглядела иначе:
Но для заказчика скорость сама стала аргументом против качества. Он сравнивал мою работу с другими исполнителями, которым параллельно дал похожие проекты. Они ещё работали, я уже сдал.
Для меня это означало эффективность. Для него стало поводом сомневаться в глубине анализа.
AI ломает привычную связь между временем и ценностью
Мы привыкли оценивать сложную интеллектуальную работу через затраченное время. Большой отчёт, десятки замечаний, таблицы и скриншоты должны занимать несколько дней. Если всё это появляется через несколько часов, возникает естественное подозрение: значит, что-то сделали поверхностно.
AI эту связь постепенно разрушает.
Часть задач, на которые раньше уходил рабочий день, теперь действительно можно выполнить за час. Это не означает, что специалист стал в восемь раз умнее. Просто часть рутинных операций перестала требовать ручного исполнения.
Но здесь появляется новая проблема. Если клиент не видит процесс, он видит только два факта: задача выглядела сложной, а результат появился слишком быстро.
И тогда скорость, которая должна была быть преимуществом, превращается в источник недоверия.
Где заказчик был прав
Было бы удобно остановиться на версии: я сделал хорошую работу, а клиент просто не поверил в возможности современных инструментов.
Но это была бы половина истории.
В процессе приёмки выяснилось, что некоторые требования мы понимали по-разному.
Например, заказчик отдельно говорил о Premium Emoji Telegram. Для него это была конкретная функциональная задача: новые анимированные эмодзи, которые он хотел интегрировать в продукт. Я в первую очередь воспринимал этот пункт как часть визуального языка сообщений и давал рекомендации по использованию эмодзи.
Это разные результаты.
Ещё один важный момент касался функциональных разделов самого бота. Если назначение функции нельзя достоверно понять по интерфейсу, недостаточно посмотреть на экран и сделать вывод о его полезности. Нужно либо протестировать функцию полностью, либо спросить владельца, какую задачу она решает.
Здесь правило очень простое:
Наконец, был конфликт вокруг формата передачи правок. Заказчик ещё до оформления заказа писал, что хочет получить их последовательно в Telegram-сообщениях и передать своему специалисту. Уже после сдачи я сослался на ограничения площадки и отказался переносить рабочую коммуникацию за пределы Kwork.
Само желание соблюдать правила площадки было нормальным. Ошибка произошла раньше: формулировку «прислать в тг сообщениях» нужно было разобрать до заказа и зафиксировать формат передачи так, чтобы не оставалось разных трактовок.
Где ошибся уже я сам
Чем дольше шла приёмка, тем меньше разговор был похож на обсуждение работы.
Заказчик несколько раз возвращал заказ на доработку и задавал вопросы. Я просил перечислить конкретные пункты ТЗ, которые считаются невыполненными. В какой-то момент обе стороны начали защищать уже не только результат, но и собственную позицию.
И здесь я допустил ошибку, которую сейчас точно не повторил бы.
На эмоциональное сообщение заказчика я ответил резкостью и фразой «Шах и мат».
Это ничего не улучшило.
Исполнитель имеет право не соглашаться с претензией и защищать выполненную работу. Но защищать результат и соревноваться с клиентом в остроумии, это совершенно разные задачи.
Как только обсуждение превращается в личную перепалку, даже сильные аргументы начинают работать хуже.
Теперь в спорной ситуации я бы сделал иначе: один документ с таблицей «пункт ТЗ -> что сделано -> где доказательство -> замечание клиента -> действие». Без иронии, без оценки мотивов и без попытки выиграть переписку.
Почему дело дошло до спора
Позиции сторон постепенно разошлись.
Моя позиция была такой: по ТЗ передан большой комплект материалов, основные блоки аудита закрыты, а часть претензий не показывает, что весь результат непригоден.
Позиция покупателя была другой: отдельные функции исследованы недостаточно глубоко, ожидания по Premium Emoji не закрыты в нужном ему формате, а столь быстрая сдача сама по себе вызывает сомнения в полноте проверки сложного продукта.
Я открыл спор на площадке.
Финал нельзя назвать моей победой. И нельзя назвать полной победой заказчика.
Именно этот итог делает историю полезной. Если бы арбитраж полностью поддержал одну сторону, было бы легко объяснить всё одной причиной. Частичная оплата гораздо лучше показывает реальность: работа была сделана, но ожидания и фактический результат совпали не полностью.
Что я изменил бы сегодня
Сейчас такой аудит я начал бы не с длинного отчёта, а с карты проверки.
Для каждого блока я бы заранее зафиксировал:
Все неочевидные функции согласовал бы с владельцем продукта до выводов.
Требования вроде Premium Emoji превратил бы из общей формулировки в проверяемый результат: что именно требуется предложить, подготовить или передать разработчику.
Скриншот проблемного места прикладывал бы сразу к каждой важной рекомендации. Не отдельным документом после вопроса клиента, а как часть доказательной базы самого аудита.
И главное, я бы добавил промежуточную приёмку.
Не потому, что нужно искусственно растягивать работу на семь дней. Если результат технически можно получить быстрее, я не вижу смысла несколько дней изображать занятость.
Но после первого прохода я бы показал заказчику карту продукта и несколько примеров:
«Вот сценарии, которые проверены. Вот как я фиксирую проблему. Вот глубина рекомендации. Такой формат и уровень детализации подтверждаем?»
После такого согласования можно работать быстро сколько угодно. Клиент уже видел процесс и понимает, откуда появляется результат.
Быстро не значит поверхностно. Но это нужно доказывать
Это главный вывод из всей истории.
Раньше ценность интеллектуальной работы часто была тесно связана с количеством потраченных часов. Сейчас эта связь становится слабее. Специалист с хорошими инструментами может сделать за день то, что несколько лет назад потребовало бы трёх.
Но экономия времени создаёт новую обязанность: делать процесс проверяемым.
Не показывать заказчику, сколько часов вы мучились над задачей, а показывать:
- что именно проверено;
- какие сценарии пройдены;
- на каких данных сделан вывод;
- где приложено доказательство;
- что является фактом, а что гипотезой;
- какие требования считаются выполненными;
- как выглядит критерий приёмки.
AI может ускорить анализ, документацию, оформление и техническую рутину. Он не способен вместо исполнителя договориться с клиентом о смысле результата.
И ещё он не умеет за нас вовремя остановиться в споре и оставить эмоции за пределами работы.
Этот заказ закончился частичной оплатой. Но именно после него я гораздо серьёзнее стал относиться к критериям приёмки, промежуточным контрольным точкам и доказательной базе в аналитических проектах.
Поэтому сейчас я смотрю на историю не как на неудачный заказ.
Это был дорогой, но очень наглядный эксперимент.
