Заказчик — инвестор и идеолог проекта с Кипра, владелец сети строительных супермаркетов и товаров для дома в Ларнаке, Лимасоле, Никосии и Пафосе. Он обратился в компанию-партнёра за разработкой интернет-магазина. Партнёр специализировался на стандартных решениях без фреймворков и библиотек, своими силами сделал дизайн и вёрстку, но на этапе разработки функциональной части компетенций не хватило. Партнёр обратился к нам за реализацией проекта по субподряду.
Ключевая особенность: условие партнёра — строгая секретность и отсутствие прямой коммуникации с конечным заказчиком. Вся информация шла через посредника. Это создавало отдельный класс рисков, которые нужно было учитывать с самого начала.
Задача: завершить интернет-магазин по готовому дизайну и вёрстке, разработать функциональную часть, настроить обмен данными с SAP.
Стек: React + MobX, Laravel, MySQL.
Управленческие решения
1. Принял проект с ограниченной коммуникацией и зафиксировал условия работы
Условие партнёра — работа без прямого контакта с конечным заказчиком. Это создавало риски: потеря информации при передаче через посредника, задержки обратной связи, рост сроков и бюджета.
Решение: оценил риски и принял проект осознанно. При этом озвучил партнёру свои условия работы и зафиксировал их в соглашении — чтобы риски были прозрачны для обеих сторон, а не «всплыли» в процессе.
Результат: модель работы была выстроена с учётом ограничений, обе стороны понимали границы и последствия.
Это управленческое решение о принятии проекта с известными ограничениями: не отказ от сложного кейса, а осознанный вход с зафиксированными условиями.
2. Компенсировал отсутствие прямого контакта через структуру документов
Без прямого доступа к заказчику любая недосказанность превращается в задержку или переделку.
Решение: поставил задачу разработать ТЗ по готовому дизайну, продумать и описать структуру базы данных, разработать и описать методы API с таблицей всех параметров — что передаём, что получаем. Всё, что можно было зафиксировать письменно, фиксировалось, чтобы снизить зависимость от устных передач через посредника.
Результат: у команды был чёткий контракт взаимодействия с внешней системой. Даже при задержках в коммуникации разработка не останавливалась полностью.
3. Организовал интеграцию с SAP
SAP — корпоративная система автоматизации бизнес-процессов. Интеграция с ней требует точности в параметрах и методах обмена данными.
Решение: выстроил работу так, чтобы структура обмена была описана до начала реализации — с полным перечнем параметров. Это снижало риск ошибок и лишних итераций при интеграции.
Результат: обмен данными с SAP настроен и работает, проект функционирует.
4. Управлял последствиями ограниченной коммуникации
Часть рисков, заложенных в модель работы, реализовалась: информация от заказчика передавалась медленно, оперативная обратная связь занимала время. Это привело к дополнительной разработке функционала, росту бюджета и сдвигу сроков.
Решение: фиксировал отклонения по мере появления, прозрачно отражал их для партнёра, держал команду в курсе. Не пытался «догнать» сроки за счёт качества — приоритетом было довести проект до работающего состояния.
Результат: бюджет проекта вырос на 15% с нашей стороны, сроки сместились на 2,5 месяца. Проект при этом завершён и передан клиенту, работает.
Результат проекта
- Интернет-магазин завершён и передан клиенту, успешно функционирует
- Разработана функциональная часть веб-приложения по готовому дизайну и вёрстке
- Настроена интеграция с SAP
- Разработаны ТЗ, структура базы данных и описание методов API с полным перечнем параметров
Потери по проекту:
- Бюджет увеличен на 15% с нашей стороны — из-за необходимости в дополнительном функционале
- Сроки смещены на 2,5 месяца — из-за медленной передачи информации и задержек обратной связи через посредника
Чему научился
Ограниченная коммуникация — это управляемый риск, но его нужно закладывать заранее. Если прямого контакта с заказчиком нет, всё, что можно зафиксировать письменно — ТЗ, структура данных, параметры API — должно быть зафиксировано. Это снижает зависимость от посредника.
Проект с известными ограничениями можно брать — если условия прозрачны для обеих сторон. Риски, озвученные на старте и зафиксированные в соглашении, не становятся сюрпризом, когда реализуются.
Рост бюджета и сдвиг сроков — не всегда провал. Если это следствие объективных условий, о которых стороны договорились заранее, — это управляемый процесс, а не потеря контроля. Важно довести проект до работающего результата, а не гнаться за изначальными цифрами в ущерб качеству.