Почему разработка затягивается, даже когда программист опытный, а задача кажется простой? Чаще всего дело не в лени исполнителя, а в процессе: требования меняются по ходу, к задаче добавляется «а заодно», нет тестовой среды, решения согласуются неделями, а старый код сопротивляется любым изменениям. Каждая из этих причин по отдельности добавляет дни, вместе они превращают двухнедельную доработку в квартальную эпопею. Разберём семь причин и то, как процесс спринтов держит сроки и бюджет.
- Сроки срываются в основном на стыке заказчика и исполнителя, а не внутри кода.
- Фиксированные критерии приёмки и короткие спринты с демо — главная защита от затягивания.
- Если программист затягивает сроки без объяснений, просите показать промежуточный результат на тестовой копии.
1. Требования меняются по ходу работы
Задачу обсудили на словах, оценили, запустили. Через неделю на демо выясняется, что «имелось в виду другое»: фильтр должен учитывать оптовые цены, калькулятор — считать в двух валютах, а форма — уходить не на почту, а в CRM. Каждое уточнение само по себе мелкое, но часть сделанной работы приходится переделывать.
Лекарство — описать сценарий и критерии приёмки до начала разработки и согласовать их письменно. Тогда изменение — это осознанное решение с понятной ценой и сроком, а не «мы же договаривались». Так мы начинаем любую разработку нового функционала: сначала проектирование и согласование, потом код.
Важно понимать, почему поздние изменения так дороги. Одно дело — поменять текст кнопки, другое — изменить логику, на которой уже построены данные, интерфейс и проверки. Если оптовые цены нужно учитывать в фильтре, это затрагивает каталог, обмен с 1С и личный кабинет. Чем позже появляется такое уточнение, тем больше уже сделанного приходится разбирать.
2. «А заодно сделайте»
Самая незаметная причина. Пока программист работает над корзиной, ему пишут: «раз уж ты там, поправь шапку», «заодно добавь баннер», «и посмотри, почему не приходят письма». Каждая просьба — полчаса-час, но они вытесняют основную задачу, ломают план и смешивают изменения так, что потом трудно понять, что вызвало ошибку.
Мелкие просьбы стоит собирать в отдельный список и отдавать отдельным пакетом, а не вклинивать в текущую разработку.
Считать, что маленькие просьбы «бесплатные», раз основная задача уже оплачена. При почасовой оплате они попадают в счёт, при фиксированной — сдвигают срок. Бесплатных правок в разработке не бывает, бывают учтённые и неучтённые.
3. Нет тестовой среды
Если изменения вносятся прямо на рабочем сайте, программист работает медленно и осторожно, а любая ошибка превращается в аварию: сломалась корзина, надо срочно откатывать, разбираться, чинить. Плановая работа останавливается, сроки сдвигаются, а заодно появляются задачи на исправление ошибок, которых могло не быть.
Тестовая копия, совпадающая с рабочим сайтом, — не роскошь, а условие предсказуемых сроков. На ней можно спокойно разрабатывать, показывать демо и принимать работу, не рискуя продажами.
4. Технический долг и чужой код
Сайт делали несколько команд, каждая — по-своему. Правки в ядре CMS, дублирующиеся модули, код без документации. Простая задача «добавить поле в карточку товара» упирается в то, что карточка собирается тремя разными способами в разных разделах. Программист тратит больше времени на то, чтобы разобраться, чем на саму доработку.
Технический долг нельзя игнорировать бесконечно: каждая новая функция на шатком фундаменте стоит дороже предыдущей. Честный подход — показать его на аудите кода и заложить в оценку заранее, а не обнаружить в середине работы.
Признаки, что технический долг уже мешает: каждая новая доработка оценивается дороже похожей прошлой, после обновлений регулярно что-то ломается, а разработчики разных команд говорят, что «тут всё сложно». Если вы узнаёте свой сайт, попросите исполнителя на оценке отдельно показать, сколько времени уйдёт на саму задачу, а сколько — на работу с наследием. Иногда выгоднее сначала потратить спринт на приведение в порядок одного модуля, чем каждый раз платить за обход.
5. Согласования и ответы занимают дни
Программист задал вопрос в понедельник, ответ пришёл в четверг. Нужны доступы к 1С — их выдают неделю. Тексты для нового раздела «будут на следующей неделе». В итоге разработка, рассчитанная на две недели, длится полтора месяца, хотя чистого рабочего времени ушло ровно столько, сколько оценивали.
Назначьте одного человека со стороны компании, который отвечает на вопросы в течение рабочего дня и имеет право принимать решения. Это самое дешёвое ускорение разработки из всех возможных.
6. Зависимости от третьих сторон
Доработка часто касается не только сайта: программист 1С, банк или Kaspi, служба доставки, CRM, внешний сервис с API. У каждого свои сроки. Если о зависимостях не подумали заранее, работа встаёт в ожидании договора с банком или правок в конфигурации 1С.
Перечислите все внешние стороны при постановке задачи и запустите параллельные процессы — договоры, доступы, ключи API — в первый же день.
Отдельно договоритесь, кто отвечает за взаимодействие с каждой стороной. Если исполнитель сайта ждёт, пока ваш программист 1С «найдёт время», а тот не знает, что от него что-то нужно, неделя уходит впустую. Хорошая практика — общий чат или задача в CRM, где видны все участники, вопросы и сроки ответов. Тогда задержка сразу заметна и понятно, у кого она возникла.
7. Нет промежуточных результатов
Исполнитель месяц работает «в стол», а потом показывает всё сразу. Расхождения с ожиданиями обнаруживаются в самом конце, когда исправлять дороже всего. Вы не видите прогресса, не понимаете, на каком этапе работа, и не можете вовремя скорректировать курс.
Договоритесь, что каждый этап заканчивается показом работающего результата, а не отчётом «сделано 70%». Проценты ничего не говорят: последние 30% часто занимают столько же времени, сколько первые 70. Работающая на тестовой копии часть функции — единственное честное свидетельство прогресса, и её можно проверить без технических знаний.
ПРАВИЛОЕсли вы не видели результат две недели, вы не знаете, сколько ещё ждать.
Как спринты держат сроки и бюджет
Все семь причин лечатся одним и тем же: короткими циклами с фиксированным объёмом и демонстрацией результата. Так устроена разработка нового функционала в WeMake:
- Оценка за 1 деньАудит кода и смета по задаче — технический долг виден до старта, а не в середине.
- Проектирование 2–3 дняСценарий, данные, прототип. Разработка начинается после вашего согласования.
- Спринты по 1–2 неделиКаждый заканчивается демо на тестовой копии и приёмкой по частям.
- ТестированиеФункция и всё вокруг неё, чтобы не появлялись срочные задачи на исправление.
- Запуск за одну ночьС откатом наготове, без остановки продаж.
Срок фиксируется в договоре после оценки. Небольшая функция — 1–2 недели и от 80 000 ₸, модуль — 3–4 недели и от 350 000 ₸, крупная доработка — 5–6 недель и от 900 000 ₸. Если срок жёсткий, мы не сокращаем тестирование, а предлагаем упростить первую версию функции: так спешка не ломает работающий проект. А если ошибки после чужих доработок уже мешают работать, их можно закрыть отдельно через исправление ошибок — с фиксированной ценой и гарантией 1 год. Ориентиры по всем форматам доработок и поддержки собраны на странице цен на поддержку и доработку.
Как контролировать разработчика: чек-лист
Контроль — это не ежедневные звонки «ну что там», а правильные договорённости в начале. Сравнение моделей оплаты и того, как каждая влияет на сроки, есть в статье «Фиксированная цена или оплата по часам».
- Сценарий и критерии приёмки согласованы письменно до старта.
- Срок и цена зафиксированы после оценки кода, а не «на глаз».
- Работа идёт на тестовой копии, вы можете открыть её в любой момент.
- Есть план спринтов с датами демо.
- Мелкие просьбы собираются в отдельный список, а не вклиниваются в текущую задачу.
- Назначен один ответственный с вашей стороны, который отвечает в течение дня.
- Внешние зависимости — 1С, банк, служба доставки — запущены в первый день.
- Изменение требований оформляется как отдельное решение с ценой и сроком.
Доработка застряла у другого подрядчика? Посмотрим код и состояние задачи за 1 день и скажем, что реально осталось сделать и за какой срок.
Оценить доработкуСорваны сроки разработки сайта — что делать?
Попросите показать текущий результат на тестовой копии и список того, что осталось. Если исполнитель не может этого сделать, закажите независимую оценку кода.
Программист затягивает сроки — как понять, по чьей вине?
Сравните переписку: сколько времени ушло на ожидание ответов, доступов и материалов с вашей стороны и сколько — на саму работу. Часто сроки съедают согласования.
Можно ли сделать доработку быстрее, если заплатить больше?
Не всегда. Добавить людей в небольшую задачу почти не ускоряет её. Надёжнее упростить первую версию функции и выпустить остальное следующим спринтом.
Как контролировать разработчика без технических знаний?
Через демо: каждые 1–2 недели вы видите работающий результат на тестовой копии и проверяете его по критериям приёмки.
