Тендеры и лиды
Информация
История о том, как мы за два года превратились из пожарной бригады в стратегического партнёра, которому доверяют.
Представьте картину: вам отдают проект, от которого до вас отказались две команды. Никакой документации. Основной разработчик то на больничном, то «ничего не помнит». Код — чёрный ящик, который работает через раз. А через полтора месяца — важное мероприятие, где продукт будут показывать руководству. И вы — третьи по счёту, кто должен либо вытащить всё на себе, либо окончательно провалить задачу.
Ровно в такую историю мы попали с проектом реестра для инвестиционной платформы. Расскажу, как шли два года от режима «тушим пожары» до статуса надёжного партнёра и какие процессы нам в этом помогли.
Первое, с чем сталкиваешься в такой ситуации — полный информационный ноль. Документов по архитектуре нет. Прошлые исполнители знания не передают. Всё, что получаешь на руки — медленный, глючный код и шлейф недовольства заказчика предыдущими подрядчиками.
Кроме технических бед, а они были серьёзные (страницы грузились по минуте, данные в интеграциях пропадали), у проекта была своя организационная специфика:
Жёсткая отчётность. Раз в две недели — детальные доклады по строгим формам. Каждый спринт закрывался протоколом тестов и скриншотами всех изменений.
Оценки наугад. Задачи приходилось прикидывать без полного понимания, как устроен код.
Длинные цепочки согласований. Спринты, задачи, правки — всё шло через несколько уровней начальства.
Ситуация осложнялась тем, что доверие к подрядчикам было убито уже дважды. На нас смотрели скептически.
Первые полтора месяца мы жили в режиме, который назвали «исследование на ходу». Изучать всё спокойно, а потом делать — такой роскоши у нас не было. Мероприятие приближалось, сроки никто не сдвигал.
Разбили работу на два потока:
Залатать критичное. Нашли самые больные точки — например, запросы, которые вешали базу — и по-быстрому прикрыли их кэшированием и другими временными мерами. Никакого волшебства, просто жгут на рану, чтобы дотянуть до нормального лечения.
Сделать новое к мероприятию. Параллельно пилили функционал для презентации. Спасало две вещи: короткие циклы и ежедневные созвоны с заказчиком. Показывали промежуточные результаты каждый день, чтобы в конце не услышать «это не то, что мы хотели».
Показ прошёл хорошо. Проект выжил. Но мы отдавали себе отчёт: это не успех, а только передышка. Настоящий ремонт был ещё впереди.
Главная сложность долгой работы с этим заказчиком была не в коде, а в процессах. Нужно было вписаться в жёсткую систему приёмки так, чтобы она не душила продуктивность.
1. Шаблоны и «высушивание» требований
Первый месяц отчёты переделывали до пяти раз. Причина простая: мы не знали всех внутренних нормативных требований заказчика. Тогда мы сделали очевидную, но действенную вещь: подняли всю нормативку, проанализировали замечания за время правок и создали свои шаблоны документов. Один раз согласовали их — и вопрос закрылся.
2. Всё наружу
Мы помнили: мы третья команда на проекте. Доверие не даётся просто так. Поэтому включили режим максимальной открытости:
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13519 тендеров
проведено за восемь лет работы нашего сайта.
К каждому спринту — протокол тестов с конкретными кейсами.
Каждое изменение в системе — подтверждено скриншотом.
Все риски и сложности — эскалируем заранее, а не когда уже поздно.
Через несколько месяцев заказчик перестал требовать тройной перепроверки. Просто начал нам верить.
3. Как объяснить пользу переписывания кода
В проектах с кучей старого кода самое трудное — доказать бизнесу, зачем нужен рефакторинг. Когда заказчику горит «ещё одна кнопка», сложно объяснить, почему полспринта уйдёт на невидимую глазу переделку внутренностей.
Мы говорили на языке выгоды, а не техники:
Не «рефакторинг роутов», а «страницы откроются в 50 раз быстрее».
Не «шина данных», а «данные перестанут теряться, ручной ввод больше не нужен».
Не «настройка CI/CD», а «убираем риск человеческой ошибки при обновлениях».
Любую техническую задачу упаковывали в понятный и измеряемый бизнес-итог.
За два года мы не просто починили и переписали архитектуру. Мы полностью поменяли отношения с заказчиком. Из исполнителя под микроскопом превратились в партнёра, с которым продолжают работать и развивать продукт.
Три главных вывода, которые мы сделали для себя:
В режиме скорой помощи «сначала всё изучить» — это роскошь. Исследование и разработка должны идти бок о бок, иначе провалишь сроки.
Бюрократия — не враг. Разберитесь в правилах, оформите их — и friction исчезнет.
Доверие строится шаг за шагом. Показывайте больше, чем от вас ждут, и однажды вас перестанут перепроверять.
Если ваш проект сейчас в похожей яме — тормозит, сыпется, сроки горят — мы знаем, как разгрести хаос и сделать процесс управляемым. Потому что проходили это сами.
