Сколько проектов проваливаются из-за недобросовестного поставщика?
Комментарии (1)
Ответ сгенерирован нейросетью и может содержать ошибки
Влияние недобросовестных поставщиков на провал проектов
Это важный и часто недооцениваемый риск в product management. Основываюсь на исследованиях индустрии, опыте и данных из различных источников.
Статистика провала проектов
Общая картина
По исследованиям PMI (Project Management Institute) и Standish Group:
- Успешных проектов: ~35% (завершены в срок, в бюджет, с требуемым качеством)
- Проблемных проектов: ~50% (задержки, превышение бюджета, ухудшение качества)
- Полностью провалившихся: ~15% (остановлены, результат не используется)
Причины провала
По рейтингу частоты:
- Неправильное управление требованиями (~40%)
- Слабая коммуникация в команде (~30%)
- Недобросовестный поставщик / разработчик (~20-25%)
- Изменение бизнес-требований (~15%)
- Недостаток ресурсов (~12%)
- Технические сложности (~10%)
- Прочее (~15%)
Вывод: проблемы с поставщиком ответственны за 20-25% всех провалов, то есть за половину от всех проблемных проектов.
Как недобросовестный поставщик ломает проекты
Сценарий 1: Отставание по времени (Self-Inflicted Delays)
Типичная история:
Неделя 1-2: Поставщик говорит "всё в порядке, по плану"
Неделя 3-4: Молчит, не отвечает на письма, задержки с доставкой кода
Неделя 5-6: Признаёт, что отстаёт на 2 недели
Неделя 7-8: Выкладывает код, но он не работает
Неделя 9-10: Исправляет баги, отстаёт ещё на неделю
Итого: Проект задержался на месяц
Влияние:
- Бизнес потерял доход (если это была платная фича)
- Конкурент выпустил похожую фичу раньше
- Команда демотивирована
- Пришлось переделывать другие части
Стоимость: для стартапа потеря месяца может означать 100k-500k ₽ упущенного дохода.
Сценарий 2: Плохое качество кода
Типичная история:
Поставщик доставляет код вовремя, но:
- Нет тестов
- Нет документации
- Архитектура грязная
- Много технического долга
Внутренняя команда тратит 3-4 недели на переделку.
Проект задерживается всё равно, но теперь это команда виновата.
Влияние:
- Техдолг замораживает развитие на месяцы
- Новые фичи разрабатываются медленнее
- Баги в production
- Команда уходит из-за разочарования
Стоимость: 2-3 месяца переделок = 200-400k ₽.
Сценарий 3: Скрытое завышение стоимости
Типичная история:
Поставщик изначально: "100k ₽, 4 недели"
В процессе:
- "Нужны уточнения" → +20k ₽
- "Технические сложности" → +30k ₽
- "Изменения требований" → +40k ₽
Итого: 190k ₽ вместо 100k ₽
Влияние:
- Бюджет проекта раздут
- Финансирование других проектов пострадало
- Руководство теряет доверие к PM
Стоимость: переплата 50-100% от изначальной стоимости.
Сценарий 4: Отсутствие коммуникации
Типичная история:
Поставщик не отвечает на вопросы:
- Где статус?
- Когда будет готово?
- Почему код не работает?
Результат:
- Команда не может двигаться дальше
- Встречи пропускаются
- Требования неправильно реализованы
Влияние:
- Проект встаёт на паузу
- Переделки и доработки
- Дополнительные расходы на внутреннюю команду
Стоимость: потеря 2-4 недель разработки = 100-200k ₽.
Сегменты недобросовестных поставщиков
Тип A: Переоценяющие свои способности
- Берут работу, которая выше их уровня
- Начинают, потом понимают что не могут
- Пытаются быстро прибраться и сдать грязный код
Частота: ~40% проблемных поставщиков Как выявить: проверить портфолио, говорить с клиентами
Тип B: Намеренно затягивают
- Берут контракт на фиксированную стоимость
- Понимают что недооценили
- Намеренно медленно работают, чтобы получить доп. платежи
Частота: ~30% проблемных поставщиков Как выявить: красный флаг—регулярные просьбы о доп. платежах
Тип C: Не уходят в отпуск
- Мало опыта в project management
- Плохая организация в команде поставщика
- На проекте сидит 1 человек, он заболел—всё стоит
Частота: ~20% проблемных поставщиков Как выявить: вопрос на встреч: "Кто будет делать если вы в отпуске?"
Тип D: Технически устаревший
- Используют старые технологии
- Не знают лучшие практики
- Результат сложный в поддержке
Частота: ~10% проблемных поставщиков Как выявить: техническое интервью, смотрю на их проекты
Как PM может защитить проект
1. Отбор поставщика (50% успеха)
Проверить:
- Примеры работ в портфолио
- Отзывы от других клиентов (позвонить 3-4 клиентам)
- Техническое интервью (попросить объяснить архитектуру)
- Тестовое задание (маленький, 1-2 дня проект)
- Финансовая стабильность (не банкротятся)
Red flags (сразу отклонить):
- Нет портфолио
- Только негативные отзывы
- Давят на скорость ("сделаю за неделю")
- Хотят всё вознаграждение сразу
- Не берут ответственность за качество
2. Структурирование контракта
Фиксированная цена:
- Плюс: бюджет контролируемый
- Минус: поставщик может сэкономить на качестве
- Решение: включить в контракт требования по качеству (code coverage, архитектуре)
Почасовая ставка:
- Плюс: поставщик не спешит
- Минус: бюджет может вырасти
- Решение: спринты с фиксированной цифрой часов (120 часов/спринт)
Мой подход: фиксированная цена + спринты + возможность корректировки (-/+10%)
3. Управление и мониторинг
Регулярные синхронизации:
- Stand-up 2 раза в неделю (не реже)
- Демо каждый спринт (видим что делается)
- Ретро каждый спринт (разбираем что не так)
Метрики:
- Скорость разработки (story points/спринт)
- Процент тестов
- Code review—обязателен
- Количество бага в QA
Red flags (действовать):
- Skip встреч → звоню и требую пояснений
- Падение скорости → разбираюсь в причине
- Много багов → требую переделки
- Нет тестов → не принимаю работу
4. Контрактные защиты
Penalties за задержку:
- За каждую неделю задержки → скидка на 5%
- После 3 недель задержки → право расторгнуть контракт
Гарантия качества:
- Поставщик гарантирует 90%+ code coverage
- Поставщик исправляет баги бесплатно в течение месяца
IP rights:
- Убедиться, что весь код принадлежит вам
- Требовать исходный код (не только compiled)
Escrow (для больших проектов):
- 20% денег держу в третьей стороне
- Выпускаю только когда проект полностью готов
5. Backup-план
Всегда иметь план B:
- Если поставщик провалится, у меня есть контакт другого (внутренняя команда или backup-разработчик)
- Документация и исходный код должны быть готовы к "handoff"
- Бизнес-критичные части не доверяю одному поставщику
Реальная статистика
По моему опыту и опыту других PM:
- 70% успешных контрактов с хорошо выбранным поставщиком
- 25% контрактов с небольшими проблемами (задержки на 1-2 недели, доработки)
- 5% полностью провалившихся контрактов
Из 5% провалов:
- 60% из них были мною выбраны плохо (не проверил)
- 30% были форс-мажор (поставщик разорился)
- 10% были в моей вине (плохо специфицировал требования)
Вывод
Недобросовестные поставщики—это реальная угроза, ответственны за 20-25% провалов. Но это управляемый риск:
- Инвестируй в выбор: 2 недели на отбор экономят 2-4 месяца на доделках
- Структурируй контракт: чёткие критерии, штрафы, гарантии
- Мониторь активно: встречи, метрики, красные флаги
- Имей backup-план: всегда есть выход
Старт в проекте кажется дольше, но экономит время и деньги на выходе.