Почему я не работаю по фиксу на неясных проектах

• Фикс (фиксированная цена) и почасовая оплата (time and material) — это две разные модели расчёта, у каждой своя зона применения, и выбор зависит от ясности требований.
• Когда требования размыты, фикс вредит обеим сторонам: подрядчик либо закладывает риски в цену и берёт лишнее, либо режет качество, а любая правка превращается в спор «вне сметы».
• Фикс уместен там, где есть чёткое техническое задание и типовая, предсказуемая работа: лендинг по готовому макету, понятная доработка, повторяющаяся задача.
• Для сложных и плохо описанных проектов я предпочитаю прозрачную оплату по этапам или по времени — так клиент видит, за что платит, и управляет приоритетами.
• Я честно подбираю модель под конкретную задачу — обсудить её можно на странице предложений, а сами услуги собраны в разделах разработки и автоматизации.

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

Фикс против почасовой простыми словами

Фиксированная цена — это когда мы заранее договариваемся: вот объём работы, вот сумма, вот срок. Что бы ни случилось внутри, итог известен. Звучит надёжно. Почасовая модель, которую часто называют time and material, устроена иначе: вы оплачиваете фактически потраченное время и ресурсы. Я веду учёт, показываю, что сделано, и счёт растёт по мере работы.

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

Представьте, что вы заказываете ремонт. Если речь о покраске одной комнаты по понятному плану, фиксированная цена логична — объём виден. А если вы говорите «сделайте красиво, я потом покажу, что имел в виду», ни один честный мастер не назовёт точную сумму заранее. Он либо заложит запас на все возможные «красиво», либо обязательно ошибётся. С разработкой ровно так же: цена держится на ясности задания, а не на желании её зафиксировать.

Когда фикс вредит клиенту

Самое опасное заблуждение — что фикс всегда защищает клиента. На размытом задании происходит обратное. Когда требования сформулированы общими словами — «нужен сайт с личным кабинетом» или «бот, который всё автоматизирует», — подрядчик вынужден угадывать объём. И у него есть всего два пути, оба плохие для вас.

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

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

И третья беда фикса на размытом ТЗ — отношения превращаются в торг. Любая правка, которую вы считаете очевидной, для подрядчика становится «вне сметы». Вы говорите «но это же подразумевалось», он отвечает «в задании этого не было». Каждый прав по-своему, потому что задание было неясным с самого начала. Вместо совместной работы над результатом начинается спор о границах. Я видел, как такие проекты буксуют месяцами не из-за сложности кода, а из-за выяснения, что входит в сумму. Именно поэтому на сложных задачах я не предлагаю фикс — он бьёт по той самой стороне, которую якобы защищает.

Когда фикс уместен

Я не противник фиксированной цены — я против неё там, где она не работает. Есть целый класс задач, где фикс честен и удобен для всех. Объединяет их одно: высокая ясность и предсказуемость.

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

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

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

Как я выбираю модель честно

Когда ко мне приходит проект, я не начинаю с цены. Я начинаю с вопроса: насколько ясны требования? От ответа зависит всё остальное. Если задание чёткое и работа типовая — предлагаю фикс, потому что в этих условиях он честен и удобен вам. Если требований по сути ещё нет, а есть направление и желание — я говорю об этом прямо и предлагаю другой путь.

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

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

Иногда мы делаем гибрид: сначала короткий оплачиваемый этап на прояснение требований и прототип, а уже потом, когда туман рассеялся и появилось настоящее задание, переходим к фиксу на остальное. Так клиент получает и определённость, и защиту от переплаты. Главное для меня — чтобы выбранная модель помогала результату, а не маскировала риск красивым словом «фикс».

Частые вопросы

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

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

А вдруг при оплате по времени работа будет идти медленно специально? Это разумное опасение, и отвечаю на него прозрачностью. Я показываю, что сделано на каждом этапе, и результат виден сразу. Затягивать невыгодно мне самому: репутация и повторные обращения стоят дороже лишних часов.

У меня правда нет чёткого ТЗ. Это плохо? Совершенно нормально. Большинство хороших проектов начинаются с идеи, а не с готового документа. Именно поэтому я и не настаиваю на фиксе сразу — мы вместе превращаем идею в ясное задание, и это отдельная полезная работа.

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

Выводы

Фиксированная цена — хороший инструмент, но не универсальный. Она честна там, где есть ясность: чёткое задание, типовая работа, понятные границы. На размытых требованиях фикс перестаёт защищать клиента — он либо заставляет переплачивать за заложенный риск, либо толкает подрядчика резать невидимое качество, а заодно превращает каждую правку в спор о смете. Я выбираю модель не по привычке и не по тому, что выгоднее назвать, а по реальной ясности задачи. Для понятного — фикс, для сложного и нового — прозрачная работа по этапам, где вы видите каждый шаг и управляете бюджетом. Так определённость становится настоящей, а не нарисованной одной цифрой в начале. Если у вас проект, по которому пока больше вопросов, чем ответов, — это не препятствие, а нормальная отправная точка, и именно с неё мы вместе начнём.