Был ли проект который не получился

📉 Анализ неудачного проекта: опыт и выводы

Да, конечно. Был проект, который мы не смогли завершить успешно, и этот опыт стал для меня одним из самых ценных уроков в карьере IT Project Manager. Речь идет о проекте по разработке B2B-платформы для автоматизации закупок в ритейле, запущенном в 2018 году.

🎯 Контекст и цели проекта

Изначальная задача казалась четкой: создать единую SaaS-платформу для сети из 200+ магазинов, которая интегрировала бы процессы закупки, логистики и учета товаров. Технический стек включал Python (Django), React и Kafka для обработки событий. Основные KPI:

• Сокращение времени обработки заказа на 40%.
• Интеграция с 5 внешними системами партнеров.
• Запуск пилотной версии за 6 месяцев.

🔥 Основные проблемы и этапы "провала"

Проект столкнулся с комплексом проблем, которые привели к его замораживанию через 10 месяцев.

1. Фундаментальная ошибка в сборе требований (Requirements Elicitation)

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

# Пример изначального "неправильного" требования в ТЗ:
# "Система должна автоматически подтверждать заказ при поступлении от поставщика."
# Реальность, выявленная позже:
# 70% заказов требуют ручной проверки менеджером на соответствие акциям и остаткам.
def confirm_order_auto(order):
    # Первоначальная логика, не отражавшая реальный процесс
    if order.received_from_supplier:
        order.status = 'confirmed'  # НЕВЕРНО!
        order.save()

Пользователи буквально взбунтовались, так как прототип ломал их реальные рабочие процессы.

2. Технический долг и проблемы архитектуры

В погоне за сроками команда разработки пошла на компромиссы. Мы игнорировали принципы чистой архитектуры (Clean Architecture) и DDD (Domain-Driven Design) для бизнес-логики. Вместо модульного кода получили "спагетти":

// Пример плохого кода из-за спешки - всё в одном компоненте
class OrderComponent extends React.Component {
    // Здесь была и логика валидации, и UI, и API-вызовы, и обработка ошибок
    handleSubmit() {
        // 300 строк кода, смешивающих всё подряд
        fetch(...).then(...).catch(...); // Нет единой стратегии обработки ошибок
        // Логика, зависящая от конкретного API бэкенда
    }
}

Технический долг рос экспоненциально, и к 5-му месяцу скорость разработки упала на 60%.

3. Управленческие просчёты: коммуникация и риски

• Слабая коммуникация с бэкенд- и фронтенд-командами: Они работали в относительной изоляции, что привело к несовместимости API и дублированию логики.
• Игнорирование ранних сигналов о рисках: Первые задержки тестирования и жалобы разработчиков на "хрупкость" кода мы списали на временные трудности.
• Отсутствие работающего прототипа для пользователей до 4-го месяца: Мы строили "чёрный ящик", не получая обратной связи.

🧠 Ключевые выводы и изменения в процессе

Этот проект заставил меня кардинально пересмотреть подход к управлению.

1. Внедрение User-Centered Design и Discovery-фазы: Теперь ни один проект не стартует без глубокого исследования (Discovery Phase) с вовлечением ВСЕХ категорий пользователей. Мы проводим воркшопы, интервью, составляем карты эмпатии (Empathy Maps) и пользовательские сценарии (User Story Maps).

   *   Раньше: Требования от одного стейкхолдера -> ТЗ -> Разработка.
   *   Теперь: Интервью (5+ ролей) -> Прототипы в Figma -> Юзабилити-тесты -> Итерация -> ТЗ.
   

2. Жёсткий контроль за техническим качеством: Я, как PM, стал "адвокатом качества" на стороне команды. Мы внедрили:

    *   **Definition of Ready (DoR)** и **Definition of Done (DoD)** для каждой задачи.
    *   Обязательные **code review** и **архитектурные сессии** перед началом разработки сложных модулей.
    *   Резервирование времени в спринте (до 20%) на рефакторинг и борьбу с техдолгом.

1. **Прозаичный и частый демо **: Мы перешли на короткие итерации (1-2 недели) с обязательным демо рабочего прототипа для группы ключевых пользователей. Даже если функционал минимален, обратная связь бесценна.

2. Проактивное управление рисками: Риск-регистр стал живым документом. Каждую потенциальную проблему (например, "сложная интеграция с системой X") мы сразу же начинаем прорабатывать: делаем spike-задачи, пишем PoC, общаемся с вендором.

💎 Заключение

Этот неудачный проект стал для меня лучшим учебником. Он наглядно показал, что успех IT-проекта зависит не от идеальных планов в Jira, а от гибкости, постоянной обратной связи и глубокого понимания реальных проблем пользователей. Главный вывод: нельзя жертвовать качеством коммуникации и качеством кода ради мнимой скорости. Теперь моя философия управления — это баланс между бизнес-давлением и защитой sustainable pace команды, где честность о проблемах ценится выше, чем рапорты об успехах на бумаге. Эта неудача закалила меня как менеджера и научила видеть проекты системно, предвосхищая проблемы до их возникновения.