Как мы провалились на проекте сервиса опросов — и что из этого вынесли

Контекст: запрос на сервис опросов

На крупном проекте, где мы отвечали за сервисы авторизации, админ-панели и рассылок, бизнес попросил разработать новый сервис — Опросы.

Зачем он был нужен: проводить опросы среди сотрудников компании, клиентов и сторонних пользователей во внутреннем контуре.

Требования к функционалу:

• Сквозная авторизация через наш сервис.

• Создание баз пользователей для рассылок.

• Создание самих опросов.

• Обмен сущностями с другими пользователями.

• Запуск опросов: отложенный на адресные базы или рассылка ссылки на опрос.

• Статистика по опросам: прохождение, ответы, время прохождения и т.д.

• Ролевая модель для действий над сущностями опросов и клиентских баз.

Функционал, который мы добавили при проектировании:

• Типы вопросов: одиночный выбор, множественный выбор, текстовый ответ, шкала оценки, да/нет.

• Шаблоны опросов — чтобы не создавать с нуля каждый раз.

• Логика ветвления — вопросы, которые показываются в зависимости от предыдущих ответов.

• Анонимность — возможность проходить опрос без привязки к пользователю.

• Обязательные и необязательные вопросы.

• Экспорт результатов в Excel/CSV для анализа.

• Интеграция с сервисом рассылок — для отправки приглашений на адресные базы.

• Статусы опросов: черновик, запланирован, активен, завершён.

• Квоты и ограничения — лимит ответов, дедлайн прохождения.

• Уведомления — напоминания о прохождении, уведомления о новых ответах.

Команда и сроки

Команда:

• Тимлид.

• 1 бэкенд-разработчик.

• 1 фронтенд-разработчик.

Срок: 3 месяца — с учётом обслуживания действующих сервисов, доработки на них новых фич и решения инцидентов.

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

Выбор инструментов и первый риск

Стек: Laravel + Vue.js.

Риск был изначально — и только по Vue.js. Фронтенд-специалист не имел достаточных компетенций в этом инструменте.

Тимлид хотел заменить Vue.js на более простые инструменты — например, Laravel Blade + нативный JavaScript. Но поверил во фронтенд-специалиста.

Это было первое решение, которое привело к провалу. Не потому что фронтенд был плохим — а потому что компетенции не совпадали с выбором инструмента.

Как шла разработка: «всё под контролем»

Бэкенд сдавал свои блоки в срок, даже раньше положенного. Это создавало ощущение, что проект идёт хорошо.

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

Когда оставался месяц до сдачи, мы вынудили фронтенд-специалиста показать наработки.

Результат: очень много проблем, связанных с Vue.js. Наработки были далеки от готовности.

Фронтенд сказал, что будет работать сверхурочно, у него всё под контролем, успеем сдать в срок.

За неделю до показа мы поняли: проект не готов. И причина — именно Vue.js.

Классическая ловушка: «всё под контролем» без демонстрации результата. Чем дольше откладывается показ, тем больше риск, что проблемы всплывут слишком поздно.

Экстренное решение: переписать на Blade + JavaScript

Показ был через неделю. Нужно было что-то делать.

Мы экстренно собрали сильнейших доступных разработчиков. Среди них не было фронтенд-специалистов — поэтому силами бэкенд-разработчиков мы работали сверхурочно и полностью переделали проект для демо на:

• Laravel Blade — шаблонизатор Laravel.

• Нативный JavaScript — без фреймворков.

От Vue.js отказались.

MVP версию мы успели сделать — и отдали бизнесу.

Как это было: работа до 6 утра

Эта неделя осталась в памяти команды надолго.

Мы работали до 6 утра — с бесконечным потоком кофе, шутками и эмоциями. Каждый понимал: отступать некуда, показ через неделю, и нужно успеть.

Было всё: усталость, споры, смех над очередным багом, чувство «ещё чуть-чуть и получится». И когда MVP наконец заработал на новом инструменте — было чувство собственного достижения. Мы сделали это. За неделю. На стеке, который не планировали.

Это не оправдание провала. Это память о том, как команда сплотилась в критический момент — и вытащила проект.

Результат: MVP сдан, но с багами

Увы, из-за ускоренной разработки и невозможности тестирования в проекте было много багов. Бизнес дал негатив.

Но кредит доверия был большой — из-за взаимодействия по другим задачам на этом же проекте. Нам дали время на приведение проекта в стабильное состояние.

Что мы сделали:

• Привели проект в стабильное состояние в краткие сроки.

• Исправили баги, которые накопились из-за спешки.

• Сервис заработал как нужно.

Но осадок остался. Как и опыт.

Что пошло не так: разбор ошибок

1. Выбор инструмента под компетенции, а не под желание

Тимлид хотел заменить Vue.js на более простой стек. Но поверил во фронтенд-специалиста. Компетенции не совпадали с инструментом — и это стало корнем проблемы.

Урок: если компетенций нет — либо учиться заранее, либо выбирать инструмент под команду, а не под тренд.

2. Отсутствие демонстрации результата

Фронтенд говорил «всё под контролем», но не показывал наработки. Проблема всплыла за месяц до сдачи — слишком поздно.

Урок: регулярные демо — обязательны. «Показать не могу» — это красный флаг, а не «мелочи».

3. Сжатые сроки с параллельной нагрузкой

3 месяца — с учётом обслуживания действующих сервисов и инцидентов. Это не «чистая» разработка. Ресурс команды был ограничен.

Урок: реалистичная оценка сроков должна учитывать параллельную нагрузку. Иначе проект стартует с заведомо заниженным сроком.

4. Экстренная переделка — дорого и рискованно

Переписать проект за неделю силами бэкенд-разработчиков — это героизм, но не процесс. MVP сдали, но с багами.

Урок: лучше предотвратить, чем героически исправлять. Но если проблема случилась — кредит доверия и скорость реакции спасают.

5. Отсутствие тестирования — прямая дорога к багам

Из-за ускоренной разработки тестирование было невозможно. Баги накопились.

Урок: тестирование — не роскошь. Если его нет, баги неизбежны.

Что мы вынесли из этой истории

1. Инструмент должен соответствовать компетенциям команды

Vue.js — хороший инструмент. Но если команда им не владеет — это риск. Лучше выбрать простой стек и сделать хорошо, чем современный и сделать плохо.

2. «Всё под контролем» без демо — не аргумент

Регулярные демонстрации результата — обязательны. Если разработчик не может показать наработки — это сигнал проблемы, а не «мелочи».

3. Сроки должны учитывать параллельную нагрузку

3 месяца с обслуживанием действующих сервисов — это не 3 месяца чистой разработки. Оценка должна быть реалистичной.

4. Кредит доверия — это актив

Из-за взаимодействия по другим задачам бизнес дал нам время на стабилизацию. Кредит доверия спас проект. Это важно: репутация на других задачах — это страховка на случай провала.

5. Провал — это опыт

Мы провалились. Но исправились. И вынесли уроки, которые больше не повторим.

6. Команда, которая работала до 6 утра, — это тоже результат

Да, это был героизм, а не процесс. Но та неделя показала: команда умеет сплотиться в критический момент. И это чувство собственного достижения — тоже часть опыта.

Стек (итоговый)

• Backend: Laravel (PHP)

• Frontend: Laravel Blade + нативный JavaScript (от Vue.js отказались)

• Авторизация: сквозная через наш сервис авторизации

Заключение

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

Мы провалились. Но исправились в краткие сроки — и сохранили доверие бизнеса.

Осадок остался. Как и опыт. И воспоминания о той неделе, когда мы работали до 6 утра, пили бесконечный кофе, шутили, злились и в итоге сделали MVP на новом инструменте.