Главное Авторские колонки Вакансии Вопросы
😼
Выбор
редакции
67 0 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Ошибка на старте, которая чуть не стоила нам всего проекта

В сфере госзаказов принято считать, что главные риски лежат в плоскости жестких ТЗ и фиксированных бюджетов. Однако наш опыт работы с автоматизированной системой социальной поддержки граждан Ямало-Ненецкого автономного округа (ЯНАО) показал: даже самый адекватный заказчик не спасет проект, если в фундаменте планировани
Мнение автора может не совпадать с мнением редакции

Проект пришел к нам по рекомендации — мы успешно реализовали кейс «Цифровое рыболовство», и заказчик доверил нам развитие системы, которая помогает людям улучшать жилищные условия и получать выплаты: от пособий малоимущим до поддержки участников СВО. Задача стояла масштабная: интеграция с формами ЕПГУ (Госуслуги), модернизация монолита и создание с нуля микросервисного модуля «Реестр аварийных домов».

Хаос под маской стабильности

На старте всё казалось понятным. Есть государственный контракт, есть сроки, есть бюджет. Но была одна деталь, которой в начале не уделили должного внимания: проект переходил из одного отдела в другой без должного очного знакомства и глубокого погружения в контекст. Мы зашли в разработку, не имея на руках четкой декомпозиции задач и актуальной дорожной карты.

Команда развития была внушительной — пять бэкенд-разработчиков, два фронтенда, тимлид, PM и тестировщики. Однако вскоре выяснилось, что даже такого состава катастрофически не хватает. Система оказалась настолько сложной технически, что разработчики один за другим просили снять их с проекта. Технические сложности с внешними сервисами интеграции накладывались на внутренний дефицит ресурсов, а документация и тестирование проседали под натиском бесконечного потока задач.

Момент истины

Главная ошибка вскрылась не сразу, а ближе к середине пути. Только тогда мы наконец провели полную декомпозицию, разбили систему на модули, оценили их в часах и составили реальную дорожную карту. Результат анализа был неутешительным: мы катастрофически не успевали.

Самым сложным в этот период была не сама разработка, а необходимость выйти к заказчику и честно признать: «Мы не укладываемся в сроки». Нас спасла только человечность с обеих сторон. Несмотря на формальные рамки госконтракта, функциональный заказчик оказался готов к диалогу. Мы адаптировались к постоянно меняющимся требованиям, а заказчик шел навстречу в вопросах приоритизации.

Цена опыта

Итоговые сроки мы все же сорвали. Главная причина — упущенное время на старте из-за отсутствия планирования и нехватки людей, которых пришлось добирать в процессе.

Сегодня продукт живет и активно используется жителями ЯНАО. Граждане подают заявки и получают положенные им меры поддержки, а система готовится к новому этапу развития. Но для нас этот кейс стал важным уроком.

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

Иногда, чтобы проект не стоил «всего», нужно просто вовремя остановиться в самом начале и потратить неделю на планирование, которое сэкономит месяцы в будущем.

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.