Незакрытые проекты

Без иллюзий

Что значит «кинули при разработке сайта» на практике

На практике повторяется один и тот же сценарий. Работа уже сделана или почти завершена, время потрачено, ключевые решения приняты. Проект всех устраивает, правки обсуждаются, движение есть. …А затем в какой-то момент процесс просто останавливается и остаётся без финальной точки и ответственности.

Это не ситуация «ничего нельзя исправить». Сайты правятся, дорабатываются и пересобираются даже на финальных этапах. Почти всегда есть техническая возможность довести проект до нужного состояния. Но вместо этого происходит слив. Не потому что результат плохой, а потому что в какой-то момент он перестаёт быть нужен.

Кейс №1: договор появился в конце

Работа по проекту уже шла: сайт собран, структура и визуал согласованы, правки обсуждались по ходу. Проект можно было открыть и посмотреть.

Около двух недель всё устраивало. Сайт смотрели, комментировали, принимали изменения, работа шла спокойно. А затем внезапно понадобился договор — с формулировками про «нет доверия», гарантии и пересборку условий, ровно в тот момент, когда до финала оставались технические действия.

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

Перенос без оплаты означал полный риск для исполнителя. После отказа брать этот риск сотрудничество было прекращено.

Итог: заказчик вышел из проекта без приёмки и расчёта. Формально всё выглядело корректно, но по факту меня кинули при разработке сайта. Я потеряла пару недель работы и время, которое уже нельзя вернуть.
Это не «типовой сценарий», это один из самых грязных способов закончить проект: без расчёта и без ответственности.

Кейс №2: «давайте делать» и тишина

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

Работа начинается без формального старта: делается меню, первый экран, предлагаются варианты, обсуждаются цвета, видео, логика блоков. Заказчик обещает «посмотреть сегодня», «дать комментарии завтра», «обсудить с партнёром». На этом этапе никто не говорит о стопе или паузе.

Затем возникает развилка, где нужно принять решение. Выбрать вариант. Утвердить направление. Сказать «да» или «нет». Именно здесь коммуникация начинает ломаться.

Ответы становятся редкими, потом пропадают совсем. Сообщения висят без реакции. Проект не закрыт и не отменён, он просто повисает. Формально работа не закончена, но и продолжить её невозможно без обратной связи.

В итоге заказчик ничего не требует и ничего не объясняет. Он просто исчезает из процесса. А исполнитель остаётся с проделанной работой, потраченным временем и ощущением, что проект «растворился».

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

Кейс №3: «пустой магазин»

Я занималась технической настройкой интернет-магазина: структурой каталога, категориями, карточками товаров, фильтрами и логикой работы. Это был каркас магазина, который дальше должен наполняться реальными товарами.

В процессе работы я несколько раз просила передать товары для наполнения: список позиций, фотографии, описания, характеристики. В ответ заказчик настаивал, что наполнение должна делать я, без предоставления исходных данных.

Фактически от меня ожидали заполненный магазин, при том что я не знала ассортимент, бизнес, товары и их параметры. Взять эти данные было неоткуда. Наполнение как отдельную задачу мы не обсуждали и не оплачивали.

Для проверки работы каталога и фильтров я добавляла тестовые товары. Они использовались только для технической проверки и не могли заменить реальные позиции.

После этого заказчик заявил, что сайт «пустой», и отказался признавать выполненную работу результатом. От меня ожидали финал, который невозможно сделать без данных со стороны заказчика.

Итог простой: техническая работа была выполнена, но не оплачена. Проект не закрыли, потому что ожидали результат, который физически невозможно сделать без информации от заказчика. По факту снова кинули.

Где заканчивается моя ответственность

Важно сказать отдельно. Моя доля ответственности здесь есть. Я действительно каждый раз считала, что всё проговорено: что именно делаю я, где заканчивается моя работа и что заказчик делает дальше. Мне казалось, что этого достаточно, слов, переписки, логики процесса.

Проблема в том, что каждый раз, когда я думала, что уже всё предусмотрела и объяснила, появлялась новая схема, о которой невозможно было догадаться заранее. Менялись не условия работы, а трактовка результата задним числом. И в этот момент любые предварительные договорённости переставали иметь значение.

Поэтому речь здесь не о «я не так объяснила», а о том, что в этих историях правила меняют уже после выполненной работы. И к этому невозможно подготовиться один раз и навсегда, только постоянно усиливая границы и фиксацию.

Что объединяет эти сценарии

Это не три отдельных случая и не «неудачные проекты». Речь идёт о повторяющихся сценариях, которые возникают в работе снова и снова. При этом первый из них произошёл со мной впервые и именно он стал поводом для этой статьи. Не из-за конфликта, а из-за самой логики происходящего.

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

Общее здесь в другом. Проект не закрывают. Не говорят «не подходит», не принимают работу и не отказываются официально. Процесс просто обрывается. Без финального расчёта, без точки и без ответственности.

Именно так чаще всего и кидают при разработке сайта. Не через скандал и не через открытый отказ, а через уход в туман, когда работа уже сделана и время потрачено.

Договор

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

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

Кажется, что договор должен дисциплинировать. Иногда так и происходит. Но договор не меняет мотивацию. Он не делает человека ответственным, если ответственности изначально нет. Он лишь добавляет рамки тем, кто и так готов их соблюдать.

Поэтому проблема не в наличии или отсутствии договора. Если результат можно не признать результатом, никакая бумага сама по себе этого не исправит. Речь в этой статье не о юридических инструментах, а о механике. О том, как работу можно просто не закрыть.

Заключение

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

Даже с опытом такие ситуации каждый раз переживаются как в первый. Потому что за каждым проектом стоит живая работа, а не абстрактный процесс. И потому что незакрытая работа всегда оставляет ощущение незавершённости, независимо от того, сколько раз ты с этим сталкивалась.

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

Эта статья, способ зафиксировать этот опыт. Для себя и для тех, кто работает в похожей реальности.

Смотреть все статьи