На старте все выглядит красиво. Подрядчик говорит: "Сделаем сайт за месяц". Через четыре недели готов только дизайн. Через два месяца идут правки. На четвертом внезапно выясняется, что интеграция сложнее, чем ожидали. Через полгода клиент уже не спрашивает, когда будет релиз. Он спрашивает, закончится ли проект вообще.
Самое неприятное - бизнес в это время продолжает платить старым сайтом, потерянными заявками, ручной работой сотрудников и собственным временем.
Быстрый ответ: проекты застревают не потому, что разработчики обязательно работают медленно. Чаще проблема появляется еще до разработки: нет нормального ТЗ, не определен объем работ, постоянно меняются требования, решения долго согласуются, а подрядчик не управляет проектом по этапам.
Срок разработки сайта зависит не только от скорости программиста. Он зависит от качества управления всем процессом.
2. Почему проекты застревают уже на старте?
Первая причина - срок называют до того, как разобрали задачу.
Клиент говорит:
"Нужен корпоративный сайт на 20 страниц".
На первый взгляд все понятно. Но потом выясняется, что нужны:
- индивидуальный дизайн;
- каталог;
- импорт данных;
- интеграция с CRM;
- несколько форм;
- личный кабинет;
- SEO-перенос;
- мультиязычность;
- нестандартная админка.
И проект, который оценили как обычный корпоративный сайт, превращается в полноценную информационную систему.
Если обещание "за месяц" дали до нормального анализа, срок изначально был не планом, а предположением.
Мы в RG3 стараемся сначала разобрать функционал, а уже потом говорить о сроках. Иногда честные три месяца намного полезнее для бизнеса, чем красивое обещание одного.
3. Ошибка 1. Нет нормального технического задания
Фраза "сделайте современный сайт" не является ТЗ.
Как и:
"нужен удобный каталог";
"подключите CRM";
"сделайте личный кабинет";
"хочу примерно как у конкурента".
За каждой такой формулировкой находятся десятки решений.
Например, "подключить CRM" может означать просто передавать имя и телефон из формы. А может означать создание сделки, определение источника, передачу товаров, файлов, статусов, ответственного менеджера и обратную синхронизацию.
Если этого нет в ТЗ, разработчик начинает уточнять уже во время работы.
Проект останавливается.
Появляются новые оценки.
Начинаются согласования.
Срок постепенно уезжает.
Хорошее ТЗ не усложняет разработку. Оно убирает вопросы, которые в противном случае появятся в самый неудобный момент.
4. Ошибка 2. Дизайн начинают раньше структуры
Еще одна типичная ситуация.
Дизайнер сразу рисует красивую главную страницу. Клиент согласовывает. Потом подключается SEO-специалист и говорит, что нужны отдельные страницы услуг.
Маркетолог просит добавить кейсы.
Отдел продаж хочет показать этапы и цены.
Разработчик сообщает, что часть блоков слишком сложно реализовать в текущей CMS.
Макет возвращается дизайнеру.
И все начинается заново.
Правильнее сначала определить структуру сайта, пользовательские сценарии и состав страниц. И только потом рисовать дизайн.
Иначе можно потратить месяц на красивый макет, который придется переделывать.
5. Ошибка 3. Проект постоянно меняется во время разработки
Изменения нормальны. Бизнес действительно может увидеть более удачное решение уже в процессе.
Проблема начинается, когда новые идеи добавляются без изменения срока.
Например:
сначала нужна обычная форма;
потом прикрепление файлов;
потом авторизация;
потом личный кабинет;
потом сообщения менеджеру;
потом история заявок.
Для клиента это выглядит как продолжение одной функции.
Для разработчика это уже другая задача.
Если функционал увеличился, должны измениться либо сроки, либо бюджет, либо приоритеты.
Нельзя добавить еще 30 процентов работ и ожидать, что дата запуска останется прежней.
6. Ошибка 4. Согласования занимают больше времени, чем разработка
Про этот фактор часто забывают.
Разработчик сделал макет за три дня.
Клиент согласовывал две недели.
Получил комментарии от директора.
Потом от маркетинга.
Потом от отдела продаж.
После этого выяснилось, что мнения не совпадают.
Еще неделя ушла на внутреннее обсуждение.
Формально подрядчик "делает сайт уже месяц". Фактически значительную часть этого времени проект стоял.
Поэтому при запуске нужно определить:
- кто принимает решения;
- кто собирает комментарии;
- сколько времени дается на согласование;
- что считается утвержденным;
- когда изменения становятся дополнительной работой.
Один человек со стороны клиента, который действительно имеет право принимать решение, часто ускоряет проект сильнее любого дополнительного программиста.
7. Ошибка 5. Никто не управляет зависимостями
Сайт редко состоит только из дизайна и программирования.
Для запуска могут потребоваться:
- доступы;
- тексты;
- фотографии;
- данные товаров;
- API;
- доступ к CRM;
- настройки сервера;
- платежная система;
- документы;
- доступ к 1С.
Разработчик может закончить свою часть, но не иметь возможности продолжать без данных клиента или сторонней компании.
Хорошее управление проектом означает, что такие зависимости фиксируются заранее.
Если интеграция с CRM понадобится через месяц, доступ к ней нужно запросить не через месяц, а сейчас.
8. Ошибка 6. Проект пытаются сделать целиком перед первым показом
Большие проекты опасно разрабатывать несколько месяцев в полной тишине.
Клиент видит результат только в конце и говорит:
"Мы представляли это немного иначе".
Начинается огромный цикл переделок.
Намного безопаснее двигаться этапами.
Например:
1. структура;
2. прототип;
3. дизайн ключевых страниц;
4. верстка;
5. программирование;
6. интеграции;
7. тестирование;
8. запуск.
После каждого крупного этапа результат принимается.
Так ошибка обнаруживается через неделю, а не через четыре месяца.
9. Ошибка 7. Нет нормального тестирования
Иногда проект формально "готов", но запустить его нельзя.
Не работает форма.
В корзине неправильно считается скидка.
На телефоне съезжает меню.
CRM получает дубли.
После оплаты не меняется статус заказа.
И начинается последний бесконечный этап - "еще немного поправить перед запуском".
Причина часто проста: тестирование оставили на конец.
Мы предпочитаем проверять функционал по мере разработки, а перед запуском проходить ключевые пользовательские сценарии целиком.
Сайт должен быть не просто написан. Он должен быть проверен.
10. Как делаем мы в RG3?
Наша задача - сделать процесс максимально прогнозируемым.
Перед стартом разбираем:
- цели проекта;
- структуру;
- функционал;
- интеграции;
- технические ограничения;
- необходимые материалы;
- риски;
- порядок этапов.
Затем оцениваем работы в часах и разбиваем проект на понятные части.
У каждой части есть результат.
Не "работаем над сайтом", а:
"согласована структура";
"принят дизайн";
"готов каталог";
"работает интеграция";
"пройдено тестирование".
Это дает клиенту контроль.
А нам позволяет увидеть отклонение от плана до того, как проект задержался на несколько месяцев.
11. Мини-кейс: обещали быстро, пришлось пересобирать процесс
Типовая ситуация.
Компания приходит с недоделанным сайтом от предыдущего подрядчика. Проект идет несколько месяцев.
На словах осталось "совсем немного".
При разборе оказывается:
- нет полного ТЗ;
- часть дизайна не утверждена;
- мобильные версии некоторых страниц отсутствуют;
- CRM подключена частично;
- формы работают по разным сценариям;
- список оставшихся задач нигде не зафиксирован.
Первое желание клиента - "просто быстрее все закончить".
Но если сразу начать программировать, хаос продолжится.
Поэтому сначала фиксируем текущее состояние, составляем реестр задач и делим их по приоритетам.
До:
- неизвестно, сколько осталось;
- новые задачи появляются ежедневно;
- клиент не понимает процент готовности;
- подрядчик постоянно обещает "еще пару недель".
После:
- есть фиксированный объем;
- задачи разбиты на этапы;
- видно, что блокирует запуск;
- второстепенные функции уходят после релиза;
- появляется реальная дата запуска.
Иногда лучший способ ускорить разработку - сначала на время перестать разрабатывать и нормально спланировать остаток работ.
12. Что вы получите, если обратитесь к нам?
Если ваш сайт уже несколько месяцев находится в состоянии "почти готов", мы можем подключиться и разобрать проект.
Вы получите:
- аудит текущего состояния;
- список незавершенных задач;
- разделение критичных и второстепенных работ;
- оценку оставшегося объема;
- план этапов;
- понятные сроки;
- техническое тестирование;
- помощь с запуском;
- дальнейшую поддержку проекта.
При необходимости можем забрать разработку у предыдущего подрядчика и довести сайт до рабочего состояния.
13. Сколько стоит довести зависший проект до запуска?
Здесь нельзя честно назвать одну фиксированную сумму.
Один проект действительно требует нескольких небольших исправлений.
Другой выглядит готовым на 90 процентов, но внутри требует серьезной переработки.
Поэтому сначала нужно провести аудит.
В RG3 мы считаем работы по фактически необходимым часам. Наша ставка - 2690 рублей в час.
Ориентировочно:
- аудит состояния проекта - 8-20 часов;
- подготовка списка задач и плана запуска - 5-15 часов;
- исправление небольшого объема ошибок - от нескольких часов;
- завершение сложного проекта - оценивается после аудита.
Почему попытка найти "самого дешевого разработчика, чтобы просто доделал" часто выходит дороже?
Потому что новый человек сначала разбирается в чужом коде, затем обнаруживает неизвестные проблемы и только после этого начинает работать.
Чем хуже организован проект, тем больше времени уходит не на разработку, а на понимание того, что вообще происходит.
14. Вывод
Если сайт обещали сделать за месяц, а прошло полгода, проблема обычно не решается фразой "работайте быстрее".
Нужно понять, почему проекты застревают именно в вашем случае.
Нет ТЗ?
Постоянно меняются требования?
Долго идут согласования?
Не хватает материалов?
Плохо организовано тестирование?
Никто не контролирует объем работ?
После этого проект можно вернуть в управляемое состояние.
Оставьте заявку на сайте RG3, и мы разберем зависший проект, оценим реальный объем оставшихся работ и предложим понятный план, как довести сайт до запуска.
