Сроки разработки программного обеспечения: как планировать

Почему срок — это прогноз, а не обещание

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

Для владельца бизнеса важнее другое: срок напрямую превращается в деньги. Пока продукт не запущен, заказы принимаются в директе Instagram, оплаты в Click и Payme сверяются вручную, а менеджеры отвечают на одни и те же вопросы. Каждая неделя задержки — ещё неделя ручной работы.

От чего зависят сроки разработки программного обеспечения

Основных факторов шесть, и почти все видны ещё до старта.

• Объём и сложность функций: каталог с корзиной и личный кабинет с ролями — задачи разного веса, хотя на словах звучат похоже.
• Интеграции: связка с CRM, 1С, платёжными системами, складом или маркетплейсом часто отнимает больше времени, чем сама функция.
• Качество требований: чем меньше «решим потом», тем меньше переделок.
• Дизайн и интерфейс: нестандартные экраны и сценарии требуют отдельных согласований.
• Команда: её состав, опыт и то, делала ли она похожие проекты.
• Скорость решений на вашей стороне: ответы на вопросы, доступы, тексты, фото, макеты.

Пример: Telegram-бот для цветочного магазина в Ташкенте

Возьмём условный магазин, который хочет принимать заказы в Telegram. Фраза «бот с каталогом и оплатой» звучит просто, но срок складывается из отдельных блоков:

• Сценарии: как клиент выбирает букет, указывает адрес и время доставки, что происходит при отмене.
• Каталог: кто и как добавляет товары, обновляет цены и наличие.
• Оплата через Click или Payme: подключение кабинета, тестовые платежи, возвраты и незавершённые оплаты.
• Уведомления операторам и курьерам, выгрузка заказов в CRM или таблицу.
• Админ-панель и рассылки клиентам.
• Тестирование на разных телефонах и исправление найденного.
• Запуск, обучение сотрудников и первые правки по живым заказам.

Что в этом примере двигает срок на самом деле

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

Почему сроки срываются: типичные ошибки

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

• Требования хранятся устно. Через месяц выясняется, что «доставка по регионам» означает отдельные условия для каждой области.
• Функции добавляются по ходу. Каждая «маленькая» идея сдвигает тестирование и релиз.
• Интеграция в документации описана иначе, чем работает: тестовая среда отличается от боевой, доступы выдают не сразу.
• Оценка без тестирования: проверка и исправления считаются «как-нибудь влезут».
• На стороне заказчика нет ответственного: вопросы ходят между директором, маркетологом и бухгалтером.
• Старт без доступов: аккаунты, домен и кабинеты платёжных систем оформляют уже в процессе.
• Нет резерва: любая мелкая задержка сразу превращается в срыв даты.

Пошагово: как сделать сроки предсказуемыми

Этот порядок подходит и для бота, и для сайта, и для внутренней системы.

• Шаг 1. Сформулируйте цель измеримо: например, «заказы из Telegram попадают в CRM без ручного ввода».
• Шаг 2. Разбейте продукт на этапы, у каждого — свой видимый результат и своя дата.
• Шаг 3. Расставьте приоритеты: что нужно в первый день, а что подождёт.
• Шаг 4. Выпишите риски: какие интеграции, какие доступы, кто и что должен предоставить.
• Шаг 5. Попросите заложить резерв на неизвестное и тестирование отдельными строками.
• Шаг 6. Договоритесь о порядке изменений: новая идея оценивается, а вы выбираете — сдвинуть дату, убрать другое или перенести в следующую версию.
• Шаг 7. Назначьте регулярные демонстрации и короткий отчёт: что сделано, что дальше, как изменился прогноз.

Жёсткий срок: сравнение вариантов

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

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

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

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

Роль заказчика и как читать оценку

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

Получив оценку, задайте вопросы: входят ли тестирование, исправления и обучение? Какие допущения приняты? Какой резерв заложен? Что будет, если интеграция окажется сложнее? Хороший ответ конкретен, а не сводится к «всё будет нормально».

Перед подписанием договора пройдитесь по чек-листу: сценарии и результат описаны письменно; есть список функций первой версии и отдельный список «потом»; доступы выданы или заказаны; назначен ответственный; тестирование и резерв выделены в плане; согласованы отчёты и демонстрации; описан порядок внесения изменений.

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