Есть особый жанр боли — «у нас есть разработчик, но сайта как не было, так и нет».
Вам обещали:
— «Да это неделя работы»
Прошло три.
Вы спрашиваете:
— «Ну что там?»
В ответ:
— «Там сложнее, чем казалось, сейчас допилим…»
Месяц, второй, отчётов нет, понятных результатов нет, только новые «нюансы» и «подводные камни Битрикс».
Давайте разберёмся без соплей: как понять, что разработчик реально работает, а не просто тянет резину, и что с этим делать, если у вас проект на 1С-Битрикс.
1. Главный признак: вы ничего не видите, только слышите
Если вы видите только слова — «работа идёт», «мы там почти всё сделали» — это не работа.
Нормальная разработка выглядит так:
- есть задачи →
- есть сроки →
- есть результат, который можно открыть в браузере / скриншоте / демо.
Если вместо этого:
- «мы переписываем архитектуру»;
- «оптимизируем код, но это сложно объяснить»;
- «там много невидимой работы, вы просто не понимаете» —
Скорее всего, либо вас кормят, либо разработчик сам утонул и не понимает, где находится.
Золотое правило:
Если за 1–2 недели вы не можете потрогать хоть какой-то кусок результата — значит, процесс гнилой.
2. Красные флаги, что разработчик тянет время
Флаг 1. Сроки постоянно «плавно переносятся»
— «Сделаем к пятнице».
Наступает пятница.
— «Там всплыли нюансы, перенесём на следующую неделю».
Если так было 2–3 раза подряд — это уже система.
Да, форс-мажоры бывают.
Но если каждый дедлайн — резиновый, это либо:
- отсутствие планирования;
- либо банальная попытка продлить часы и счёт.
Флаг 2. Нет нормальных оценок задачи
Вы спрашиваете:
— «Сколько займёт?»
В ответ:
— «Ну примерно… ну надо смотреть… ну там от 10 до 50 часов…»
Нормальный разработчик:
- сначала уточняет задачу;
- делит её на куски;
- даёт вилку: «минимум столько, максимум столько, вот от чего зависит».
«Надо смотреть» без продолжения — это «я сам не понимаю, во что лезу».
Флаг 3. Любой вопрос — «это особенности Битрикс»
Любая проблема на проекте не может быть вечно списана на платформу.
— Почему так долго?
— Ну это же Битрикс, там всё сложно…
— Почему после небольшой правки всё ломается?
— Ну это же Битрикс, там такая архитектура…
Да, у Битрикс своя специфика.
Но фраза «это Битрикс» не может быть ответом на всё.
Это просто удобная ширма для: «я не хочу разбираться, проще списать».
Флаг 4. Вы видите только «техничку», а не пользу
В отчётах:
- «оптимизировали модуль»;
- «переделали структуру компонентов»;
- «переписали обработчики событий»…
А вы спрашиваете:
— «И что это дало бизнесу?»
Ответа нет.
Нормально, когда вам объясняют:
- что конкретно изменили;
- какой эффект это даёт:
- сайт стал быстрее;
- меньше ошибок при заказе;
- снизили нагрузку, чтобы выдержать рекламу;
- сократили время обработки заявки.
Если этого перевода на язык пользы нет — вам продают «процесс ради процесса».
3. Что вы, как владелец, должны видеть по факту
Вот простой чек-лист. Если этого нет — попросите внедрить.
1) Список задач
Не в голове разработчика, а в нормальном виде:
- что уже сделано;
- что в работе;
- что в очереди.
Формат любой: Notion, Trello, Jira, доска в Миро — не важно. Главное — прозрачность.
2) Оценка по каждой задаче
У каждой задачи должны быть:
- описание человеческим языком («сделать нормальную форму заявки на странице Х»);
- оценка времени;
- приоритет.
Тогда вы понимаете:
- куда уходят часы;
- что делается сейчас;
- почему «сделать кнопку» у вас занимает неделю.
3) Демо-результаты раз в 1–2 недели
Минимум раз в две недели разработчик должен показывать:
- ссылки на страницы;
- скрины;
- видео / гифку работы функционала.
Не «поверьте, я там много переделал», а:
«Вот было → вот стало».
Если вам не показывают — либо нечего показывать, либо человек не умеет нормально коммуницировать. В обоих случаях плохо.
4. Какие вопросы задать разработчику, чтобы всё стало ясно
Можно не быть технарём, чтобы выводить человека на чистую воду.
Вот несколько простых вопросов:
- Что мы сделали за последние 2 недели и как это влияет на продажи / заявки / стабильность?
Если в ответ — поток абстрактных фраз без связи с результатом — минус. - Что мы сделаем в ближайшие 2 недели?
Конкретные задачи или «ну будем смотреть по ситуации»? - Какие у нас сейчас главные риски по проекту и что ты с ними делаешь?
Нормальный разработчик может назвать 2–3 вещи, которые его самого беспокоят. - Если завтра я включу больше рекламы, сайт выдержит? Если нет — что нужно сделать?
Если честный человек, он скажет, где слабые места, а не «ну давайте попробуем». - Что можно выкинуть из текущих задач, чтобы быстрее выйти в плюс по сайту?
Тут хорошо видно, думает ли человек о вашем бизнесе или только о своём красивом коде.
5. Минимальный порядок, который нужно выстроить
Если без теории, вот как должно быть хотя бы «по минимуму»:
1. ТЗ, пусть даже в виде списка в Google Docs
- какие страницы;
- какой функционал;
- какие интеграции;
- что считается «сделано».
2. Договорённость о формате работы
- фиксированные задачи на короткий промежуток (неделя/две), а не «большой туман на три месяца»;
- созвон/отчёт раз в неделю: что сделано, что в работе, что стопорит.
3. Доступ к демо / тестовому стенду
Чтобы вы могли сами зайти и посмотреть, не выпрашивая скрины.
4. Прозрачный учёт времени (если оплата почасовая)
Где видно: что делалось и сколько заняло.
6. Когда пора менять разработчика
Жёстко, но полезно.
Пора думать о смене, если:
- за 1–2 месяца вы так и не увидели ощутимого прогресса по ключевым задачам;
- каждый вопрос про сроки и результат превращается в оправдания и лекции о «сложном Битрикс»;
- вам приходится выбивать отчёты и демо;
- вы больше не доверяете этому человеку, но продолжаете платить «по инерции».
Да, смена разработчика — это тоже боль. Но сидеть годами с тем, кто тянет резину, — дороже.
Владелец бизнеса не обязан разбираться в PHP и архитектуре компонентов.
Но он обязан видеть:
- картину задач;
- реальные результаты;
- понятную связь «работа → эффект».
Если этого нет — это не «карма» и не «сложная платформа».
Это просто невыстроенный процесс и, возможно, не тот человек у руля.