Их главный признак: они готовы подписать договор и выставить чек быстрее, чем клиент успеет объяснить, что вообще за проект, какие цели/бюджет/сроки. Им искренне плевать на интеграции, будущую нагрузку и архитектуру, да и вообще на само развития проекта в будущем. Они не задают вопросов. Их единственная цель — зафиксировать клиента юридически или получить перевод на карту. А что они там будут кодить — разберутся потом. Или не разберутся и выдадут кривой кусок ******, который придется переписывать с нуля (возможно).

Это не теория, а суровая реальность фриланса и аутсорса, с которой регулярно приходят разгребать последствия, и сталкиваются многие клиенты, особенно в эпоху ИИ.

Как выглядит нормальный предпроект

Адекватный предпроектный анализ — это не попытка загрузить клиента сложной технической терминологией или забросать спамом из ста шаблонных вопросов. Задача нормального спеца — навести клиент на правильные мысли через реальные потребности бизнеса, задачи, цели, бюджет и сроки.

Если клиент не разбирается в коде, никто не станет спрашивать про архитектуру базы данных. Профессионал задаст простые, но ключевые вопросы на человеческом языке:

• «Пользователи будут оформлять заказ сразу в один клик или сначала собирать корзину?»
• «Какие варианты оплаты мы подключаем на старте, а какие оставим на потом, чтобы сэкономить бюджет?»
• «Системой будете управлять вы сами лично или нужно делать отдельную админку с разграничением прав для менеджеров?»
• «Уведомления о новых заказах должны падать в общий чат Telegram или каждому сотруднику в личку?»

ТЗ — не 100% решение

Конечно, если у есть готовое техническое задание, четкие пожелания и референсы — это огромный плюс, который сэкономит кучу времени. Но даже имея на руках идеальное ТЗ, опытный разработчик все равно задаст наводящие вопросы.

Просто потому, что сразу видит логические несостыковки, скрытые подводные камни или откровенно лишние функции, которые используют бюджет, но не принесут пользы бизнесу.

Всё описанное выше основано на реальном опыте, а любые совпадения с конкретными лицами индивидуальны. В исключительных случаях разработка может стартовать вообще без лишних слов, либо, наоборот, начаться со строго технических вопросов — всё зависит от специфики, масштаба задачи, клиента и самой исполняющей стороны.