Сегодня в каждом коммерческом предложении агентства есть слова «прозрачный процесс» и «регулярные отчёты». Написать их ничего не стоит — поэтому их пишут все.
Еженедельное демо — совсем другое дело, и оно заслуживает описания пожёстче, чем «прозрачность»:
Еженедельное демо — это опцион. Вы покупаете право передумать, пока передумать ещё дёшево.
Это финансовый инструмент, а не любезность. И, как у любого опциона, у него есть цена, срок действия и выигрыш, который вполне можно оценить.
Кривая стоимости изменений
Вот механика, которая делает его ценным.
Допустим, вам делают систему онлайн-записи, и где-то посередине вы понимаете, что клиентам нужно записываться сразу вдвоём, а не по одному.
Вторая неделя, на демо. Модель данных набросана, от неё пока ничего не зависит. Изменение — это разговор и правка: часы.
Пятая неделя, на демо. Модель построена, её используют три экрана, её отдаёт API. Изменение затрагивает модель, экраны, API и тесты: несколько дней.
Девятая неделя, запуск. Модель, экраны, API, админ-панель, письма с подтверждением, напоминания, отчёты и записи о платежах — всё исходит из того, что человек один. Изменение превращается в небольшой проект и приходит тогда, когда у всех уже закончились и бюджет, и терпение.
Требование одно и то же. Единственная переменная — когда вы о нём узнали.
Еженедельное демо не делает вас лучшим заказчиком. Оно просто сдвигает ваши открытия влево. А поскольку стоимость изменения растёт вместе со всем, что построено поверх, открытие, сделанное на три недели раньше, стоит гораздо больше, чем три недели работы.
Зачем оно вообще нужно: прогресс невозможно проверить
Есть и вторая, более прямолинейная причина, и она касается именно тех заказчиков, которые не читают код.
Заказывая софт, вы покупаете то, что не можете осмотреть. Вы не отличите код, готовый на 60%, от кода, готового на 20%, но с впечатляющим отчётом о статусе. Вы не отличите хорошую архитектуру от плохой. Традиционные заменители — диаграмма Ганта, процент выполнения, еженедельное письмо — всё это сообщает о себе сама сторона, заинтересованная в цифре.
Рабочая сборка, которую вы открываете сами, — единственный инструмент, который превращает «поверьте мне» в «посмотрите».
В 2026 году это важнее, чем было в 2022-м. Объём выдаваемого кода резко вырос, а его качество за этим не поспевает: Veracode протестировала более 100 моделей на 80 задачах по программированию и выяснила, что они выбирают небезопасную реализацию в 45% случаев. Больше кода, быстрее, а нагрузка на проверку прежняя. «Всё идёт хорошо» никогда ещё не было таким слабым сигналом.
Что считается демо
Именно здесь большинство «еженедельных отчётов» и проваливается, так что пропишите это в договоре конкретно.
Это должна быть сборка, которую вы открываете сами. На своём устройстве, через своё подключение, по адресу, который у вас есть. Не показ экрана, не запись, не прототип в Figma. При показе экрана управляет подрядчик — вы не можете свернуть не туда, а сворачивать не туда и есть весь смысл.
Она должна работать на данных, близких к реальным. Демо на трёх идеальных тестовых записях скрывает все проблемы, которые проявляются только на 500 неряшливых.
Она должна включать то, что сломано. Демо, где показывают только готовое, — это презентация для продаж. Самая полезная фраза на любом демо: «вот эта часть пока не работает, и вот почему».
Оно должно быть еженедельным, в фиксированный день. Не «когда будет что показать». Вся ценность — в ритме: фиксированная дата заставляет держать продукт в рабочем состоянии, а рабочее состояние каждую неделю — это то, что позволяет остановить проект в любой момент.
Последнее свойство стоит назвать отдельно. Проект, который показывают каждую неделю, можно отменить на четвёртой неделе, потеряв четыре недели. Проект, который показывают только в конце, можно отменить, лишь потеряв всё.
Пять вопросов, которые стоит задавать на каждом демо
Нетехнические заказчики часто сидят на демо и кивают, потому что не знают, что спросить. Эти пять вопросов работают, что бы ни разрабатывалось.
- «Можно я попробую сделать то, что буду делать на самом деле?» И сделайте — в том числе неправильно. Введите не ту дату, пропустите поле, наберите имя с апострофом, нажмите «назад». Основной сценарий всегда отполирован. Проект на самом деле живёт на краях.
- «Что вы узнали на этой неделе, чего мы не знали на прошлой?» Команда, которая ничего не узнаёт, не строит, а переписывает под диктовку. Хороший ответ называет сюрприз.
- «Какая самая рискованная часть ещё впереди и когда я её увижу?» Риски нужно разбирать в начале. Если самая трудная часть запланирована на последнюю неделю, график — это пожелание.
- «Что вы решили, не спросив меня?» Таких решений будут десятки, и это правильно: вы не хотите согласовывать всё подряд. Но, услышав их, вы найдёте то одно, которое на самом деле должны были принимать вы.
- «Если мы остановимся сегодня, что у меня останется?» С каждой неделей ответ должен становиться лучше. Если на шестой неделе он звучит как «ничего пригодного», вы покупаете не приращения, а обещание.
Демо-театр и как его сломать
Типичный сбой — сборка, которая всегда работает, потому что её всегда показывают одинаково.
Ломайте это, беря мышку в свои руки. Прося показать что-то незапланированное. Глядя на второй по важности экран вместо первого. Спрашивая, что будет на телефоне, — и потом действительно открывая сборку на своём телефоне, через мобильный интернет, а не через офисный Wi-Fi.
Команда, которая этому рада, уверена в том, что построила. Команда, которая уходит от этого — «давайте я покажу это на следующей неделе», «в этом окружении этот сценарий ещё не подключён», — вам кое-что сообщает, и дату стоит записать.
Что делать, если демо прошло плохо
Об этом никто не пишет, поэтому обычная реакция — сказать «отлично, спасибо» и три недели тревожиться про себя. Лучше реагировать по нарастающей, и начинать гораздо раньше, чем считает правильным большинство заказчиков.
Одно плохое демо — спросите о причине, а не об исправлении. Сроки сдвигаются. Важно, может ли команда одной фразой объяснить почему. «Платёжная интеграция вернула данные в формате, которого мы не ждали, и мы потеряли два дня» — это проект, который идёт нормально. «У нас были некоторые проблемы» — это не ответ, и правильный ход — спросить ещё раз, один раз и вежливо.
Два подряд — спросите, что должно быть правдой, чтобы успеть к сроку. Не «успеете ли вы к сроку» — такой вопрос провоцирует успокаивающий ответ. Этот вопрос вытаскивает ограничение на свет: больше людей, меньше объёма или более поздняя дата. Четвёртого варианта нет, и по тому, какой из них выберет команда, вы поймёте, кого наняли.
Три подряд — режьте объём, а не добавляйте время. Это решение, которого заказчики избегают, и оно почти всегда верное. Что-то должно уйти. Один проект, который мы спасали по NDA, запустился только потому, что честный взгляд на оставшуюся работу — около восьми месяцев при том, что у клиента был примерно один — привёл к тому, что объём урезали до того, что действительно нужно для запуска, а всё остальное перенесли в бэклог после запуска. Этот разговор был возможен на первой неделе. На двадцатой он был бы разбором полётов.
Демо в виде показа экрана вместо сборки — сразу считайте это тревожным сигналом. Это самый дешёвый способ изобразить прогресс, и причина, по которой подрядчик на него переходит, почти никогда не бывает нейтральной.
Общий принцип: демо — это система раннего предупреждения, а раннее предупреждение, на которое вы отказались реагировать, — всего лишь запись о том, что вас предупредили.
Почему мы привязываем к нему деньги
Мы публикуем четыре гарантии, и работают они только вместе: без привязки — всё принадлежит вам · без посредников — напрямую с разработчиками · фиксированная цена, объём не раздувается · рабочее демо каждую неделю.
Именно демо делает остальные три исполнимыми. Поэтому оплата делится на 50% на старте и 50%, когда проект запущен и вас всё устраивает: к моменту второго платежа вы каждую неделю видели рабочую сборку, так что остаток оплачивается по факту, а не по заявлению. И поэтому мы можем сказать, что если мы не сможем сделать как надо, остаток вы не платите: такое обещание честно только тогда, когда у вас была возможность возразить каждую неделю, а не один раз в конце.
Это же механизм, на котором держится самое ценное, что мы делаем для клиентов, — возражать им на раннем этапе. Одно из наших пяти обязательств — не хвалить слабую идею ради подписи под договором. Без еженедельной площадки, где его можно выполнять, это обязательство ничего не стоит.
Как это выглядит, когда работает
Самый наглядный пример из нашей практики — маркетплейс, который нас позвали спасать по NDA. Честная оценка оставшегося объёма составляла около восьми месяцев. У клиента был примерно один.
Запуск стал возможен не благодаря скорости. Его обеспечило решение, принятое в самом начале и открыто: проверить, что уже есть, сохранить то, что работает, и урезать объём до того, что действительно нужно для запуска, а всё остальное перенести в бэклог после запуска. Геоподбор, запись с онлайн-оплатой, подключение исполнителей, споры и вебхуки заявок вышли примерно за месяц; остальное подождало.
Такой разговор случается только тогда, когда кто-то смотрит на реальное состояние работы достаточно рано, чтобы его провести. У проекта, который проверяют в конце, такой встречи нет — там есть сорванный срок и спор.
Та же привычка работает и в обратную сторону. Когда планировщик Bronjoy на продакшене убивало OOM — каждая ежеминутная команда порождала PHP-процесс примерно на 200 МБ, эти процессы накладывались друг на друга внутри контейнера на 512 МБ, и каждый убитый запуск оставлял после себя блокировку на 24 часа, — мы вписали это в кейс, а не вычеркнули из него. Команды, которые прячут свои провалы внутри, прячут их и от клиентов.
Наш процесс — короткий вводный созвон, письменный план с фиксированной ценой и датой примерно в течение 48 часов, затем старт проекта и рабочее демо каждую пятницу до самого запуска.
Расскажите, что вам нужно. В ответ вы получите фиксированную цену и дату сдачи — бесплатно и без обязательств продолжать.
Частые вопросы
Еженедельное демо — это разве не просто лишние встречи?
От пятнадцати до тридцати минут в неделю, и оно заменяет письма о статусе и звонки «просто уточнить», а не добавляется к ним. Если ваши демо идут час, они превратились в презентации.
А если я не знаю, на что смотреть?
Используйте пять вопросов выше. Они не требуют технических знаний и вытаскивают на поверхность то, что важно: неизвестные, порядок рисков, решения, принятые за вас, и то, что у вас останется, если остановиться.
Это работает на совсем маленьком проекте?
Да, и там всё ещё проще. На лендинге, который делается три-пять дней, «еженедельно» на деле означает, что вы увидите его один раз в середине работы и один раз перед запуском, — это всё равно два шанса скорректировать курс вместо ни одного.
А если на демо я увижу то, что мне совсем не нравится?
Значит, оно сделало свою работу — на самой дешёвой из возможных недель. Это и есть выигрыш по опциону. Именно поэтому в каждый наш тариф входят раунды правок, и правки обходятся несравнимо дешевле, когда приходят на второй неделе.
Как прописать это в договоре?
Три предложения: рабочая сборка по адресу, который может открыть заказчик, в фиксированный день каждую неделю, и подтверждение заказчика по каждому этапу фиксируется до следующего платежа. Если подрядчик на это не соглашается, вы узнали, каков его процесс на самом деле, ещё до того, как что-либо ему заплатили.
