Запрос «разработка цифровых продуктов» набирает 1 311 показов в месяц, «процесс разработки продуктов» 1 092, «этапы процесса разработки продукта» 245, «как создать цифровой продукт» 113. Wordstat, регион Россия, снято 31 августа 2026 года. Половина верхней выдачи по этим словам это программы магистратуры, вторая половина пересказ одной и той же схемы: идея, аналитика, дизайн, разработка, тестирование, релиз, поддержка.
Схема верная и бесполезная. Она описывает порядок работ и молчит о том, где процесс ломается на практике. Ниже разбор с другой стороны: где процесс рвется на практике, чем каждый разрыв ловится и сколько стоит его пропустить.
Цифровой продукт отличается от проекта наличием обратной связи
Сайт, мобильное приложение и внутренняя система становятся продуктом в момент, когда у команды появляется цифра, по которой видно, стало лучше или хуже. До этого момента есть работы, сроки и акт приемки, но продукта нет. Разница практическая: проект заканчивается сдачей, продукт живет циклами и требует замера на каждом витке.
Отсюда рабочее определение процесса, которым мы пользуемся. Пять узлов: замер спроса, гипотеза, малый релиз, гейт качества, повторный замер. Дальше цикл повторяется. Учебниковые этапы от аналитики до поддержки укладываются внутрь третьего узла и занимают меньшую часть времени, чем принято думать.
Идея проверяется замером, а не совещанием
Самая дорогая ошибка на старте это принять решение о направлении внутри переговорной. Дешевле сделать иначе: взять поток и посчитать, сколько в нем реально доступного.
Наш пример. В августе 2026 года мы разбирали, стоит ли открывать тендерное направление. Вместо обсуждения выгрузили дамп государственных закупок и посчитали воронку. Из 53 035 записей живых лотов оказалось 30 086, в нашей вилке по деньгам 2 795, с реальным цифровым предметом 61, а после чтения технических заданий доступных для подачи осталось два. Полный разбор с фильтрами лежит в материале про тендеры на разработку программного обеспечения.
Направление закрыли за один прогон, до найма тендерного специалиста и до покупки подписки на агрегатор. Замер стоил дня работы. Гипотеза, проверенная совещанием, стоила бы квартала.
Ключевой факт
У гипотезы должен быть критерий смерти, записанный до старта. Формулировка вида «посмотрим, как пойдет» означает, что направление не закроют никогда, потому что закрывать будет нечем.
Малый релиз против залпа: цифры одного сайта
Скорость выпуска соблазняет. Когда инструменты позволяют выпускать быстро, возникает желание выпустить все сразу. Мы это желание не сдержали и получили измеримый результат.
Типовой сценарий выглядит так. Пачка материалов выпускается за один заход, проверки перед выпуском нет, и через месяц часть страниц уходит из поиска. Разбирается это сравнением двух когорт: страницы, выпущенные пачкой, и страницы, выпущенные по одной с проверкой.
| Когорта | Материалов | Вне индекса на 17.08.2026 | Доля потерь |
|---|---|---|---|
| Залп 18 июля, без проверки | 75 | 38 | 50,7 % |
| Партиями, после введения гейта | 82 | 8 | 9,8 % |
Разница в пять раз. Тексты писались по одной методике, автор один, тематика одна. Отличался режим выпуска и наличие автоматической проверки перед публикацией.
Из этого выросло правило, которое мы теперь держим жестко: потолок три материала в сутки и десять в неделю. Оно неудобно и выглядит как искусственное торможение. Оно дешевле, чем полгода возвращать домен в нормальное состояние.
Диагноз обходится дороже лечения
Самая полезная часть истории не в том, что мы уронили индексацию, а в том, что первые две недели чинили не ту причину.
Начальная версия звучала так: сайт попал под фильтр качества, надо чистить. Чистка помогла быстро. За сутки после нее страниц в поиске стало 48 вместо 31, а число исключений упало со 141 за неделю до 7, причем половина оставшихся это наши собственные перенаправления, то есть норма. Выглядело как победа.
Разбор событий исключения поштучно почти всегда меняет картину. Основная часть таких событий приходится на страницы, которым сами сменили адрес, и на страницы, которые сами закрыли от индексации. То есть большую часть «фильтра» команда делает руками, а поиск лишь исполняет распоряжение с задержкой в полторы недели. Живых выброшенных страниц оказывается меньшинство.
Дальше ищется настоящий предиктор. Объем текста не различает группы: медианы у выброшенных и оставшихся совпадают. Чек-лист качества, слова, заголовки, ссылки, плотность цифр тоже совпадают. Оба признака мимо.
Сработал один признак. Доля страниц, к которым робот не заходил дольше 21 дня, у выброшенных в разы выше, чем у оставшихся, и эта разница проходит проверку на статистическую значимость. Остальные признаки её не проходят.
Вывод получился контринтуитивный и практичный. Страница выпадает из поиска не потому, что текст устарел, а потому, что до нее перестал доходить робот. Лечится это очередью на переобход и чисткой мусорных адресов, а не переписыванием статей. Наш робот берет около 24 страниц в сутки, порог вылета 21 день, значит потолок живых адресов на домене около 500. Все, что сверху, съедает бюджет обхода у денежных страниц.
Что мы автоматизировали первым
Вопрос, который задают чаще других: с чего начинать внедрение ИИ в собственные процессы. Ответ звучит скучно. Начинать надо не с генерации, а с проверки.
Генерация текста, кода и разметки дешевеет каждый месяц, и узким местом становится приемка. Поэтому первым мы автоматизировали гейт: скрипт, который перед публикацией считает объем, длину описания, число внутренних ссылок и наличие связанных материалов, а при нарушении оставляет черновик в черновиках. Человек это не отменяет и не уговаривает.
Вторым появился валидатор разметки. Поводом стал прогон 26 августа 2026 года по десяти последним страницам блога: он нашел 25 нарушений спецификации HTML, которых в эталонной проверке двумя днями раньше не было. На двух контрольных страницах регресс составил ноль нарушений против двух. Правку внес фильтр темы, автор текста об этом не знал и знать не мог. Проверка ловит такое за секунды, глаз не ловит вообще.
Третьим стал регулярный замер обхода. Раз в неделю выгружаются страницы, к которым робот не заходил дольше 14 дней, и отправляются в очередь на переобход. Это прямое следствие предыдущего раздела и самая дешевая процедура из трех.
-
Сначала проверка, потом генерация
Автоматический гейт перед выпуском. Пока его нет, скорость производства работает против продукта.
-
Потом валидация результата
Разметка, ссылки, заголовки. Класс дефектов, который вносит инфраструктура, а не автор.
-
Затем регулярный замер
Раз в неделю. Без него первые два шага превращаются в ритуал без обратной связи.
-
И только теперь ускорение
Генерация, шаблоны, агенты. На этом этапе они дают выигрыш, а не долг.
Инфраструктура: почему свой сервер
Наш сайт и рабочие сервисы живут на собственном сервере в России, доступ по ключу, выкладка одной командой из репозитория. Причина прозаическая и состоит из двух частей.
Первая: предсказуемость счета. Управляемые платформы удобны ровно до момента, когда трафик или объем данных выходят за границу тарифа. Вторая: контроль над окружением. Когда падает не приложение, а прослойка, до которой у вас нет доступа, чинить нечего, остается ждать.
Обратная сторона честная. Свой сервер это ваша ответственность за обновления, резервные копии и мониторинг. Для команды без дежурного инженера управляемая платформа объективно безопаснее. Мы выбрали контроль, потому что дежурный инженер у нас есть, и это выбор, а не универсальная рекомендация.
Сколько стоит собрать такой контур
Ниже реальные позиции с нашими сроками. Ставка одна: 2 500 ₽/ч, оплата по факту, без аванса. Итоговая сумма зависит от того, сколько узлов контура у вас уже стоит.
| Узел контура | Что получаете | Срок |
|---|---|---|
| Замер спроса и потока | выгрузка источника, фильтры, таблица с воронкой | 2-4 дня |
| Гейт качества | скрипт проверки перед выпуском, коды возврата, запуск в расписании | 3-5 дней |
| Валидация результата | проверка разметки и ссылок на живых страницах, отчет списком | 2-3 дня |
| Регулярный замер | еженедельная выгрузка метрик и очередь на исправление | 2-3 дня |
Порядок важнее объема. Собранный гейт без замера бесполезен, потому что вы не узнаете, помог он или нет. Замер без гейта тоже бесполезен: цифра будет, а рычага влияния не будет. Если бюджет позволяет один шаг, берите гейт и ручной замер раз в неделю в таблице.
Про сроки самой разработки внутри третьего узла мы писали отдельно: этапы разработки веб-приложения и сборка прототипа за две недели. Требования к входу в разработку разобраны в материале про техническое задание.
Соберем контур на вашем продукте
Замер, гейт перед выпуском, валидация и еженедельный отчет. Ставка 2 500 ₽/ч, оплата по факту, без аванса.
Разберем ваш процесс выпуска
Покажем, какой узел контура разомкнут и во сколько это обходится
Чем цифровой продукт отличается от проекта разработки
Проект заканчивается сдачей и актом приемки. Продукт живет циклами: замер, гипотеза, релиз, проверка, новый замер. Практический признак простой. Если у команды нет цифры, по которой видно, стало лучше или хуже после выпуска, то делается проект, даже если в договоре написано слово «продукт».
С чего начинать создание цифрового продукта, если бюджет ограничен
С замера спроса и с гейта качества. Замер отвечает на вопрос, существует ли аудитория и какого она размера, и стоит дня работы с выгрузкой. Гейт не дает выпустить брак и окупается на первой же партии. Дизайн, брендинг и расширенная функциональность откладываются: они улучшают продукт, у которого уже есть подтвержденный спрос.
Почему быстрый выпуск большими партиями вредит продукту
Потому что вместе с объемом растет и объем дефектов, а обратная связь приходит с задержкой в недели. На нашем сайте пачка из 75 материалов, выпущенная за 22 минуты без проверки, дала 38 потерь в поиске, тогда как 82 материала, выпущенные партиями через гейт, дали 8. Разница в пять раз при одинаковой методике написания.
Как понять, что процесс сломан, а не рынок плохой
Разложить провал на признаки и проверить каждый на цифрах. Первая версия диагноза почти всегда неверна: команда считает, что сайт попал под фильтр качества, а поштучный разбор событий исключения показывает, что большую часть исключений сделали своими руками. Настоящий предиктор находится другой: страницы с обходом робота старше 21 дня выпадают в разы чаще остальных.
Нужно ли своей команде держать инфраструктуру самостоятельно
Зависит от наличия дежурного инженера. Свой сервер дает предсказуемый счет и полный контроль над окружением, но взамен требует обновлений, резервных копий и мониторинга. Команде без дежурного управляемая платформа объективно безопаснее: чужая прослойка чинится чужими руками, и это ее главное достоинство.
