Портфолио IT компании — первое, на что смотрит продукт-менеджер при выборе подрядчика для корпоративного проекта. И первое, что подрядчики научились подделывать. Красивые скриншоты, громкие логотипы клиентов, впечатляющие цифры — всё это может не иметь никакого отношения к реальным компетенциям команды. По данным исследования Clutch, 35% IT-компаний приукрашивают свои кейсы, а 12% включают в портфолио проекты, которые делали субподрядчики.
В IT Integration мы сами проходим этот фильтр со стороны клиентов — и знаем, какие вопросы задают самые опытные продукт-менеджеры крупных компаний. За 40+ реализованных корпоративных проектов мы видели, как компании выбирают подрядчика по красивой обёртке — и через 3 месяца приходят к нам переделывать. Проверка портфолио IT компании — навык, который экономит миллионы рублей и месяцы потерянного времени.
В этом гайде — конкретная методология проверки портфолио IT-подрядчика. С чек-листами, красными флагами и вопросами, которые отделяют реальный опыт от маркетинговой упаковки.
Почему портфолио IT компании нельзя принимать на веру
Проблема портфолио в IT — отсутствие стандартов. В строительстве есть лицензии и допуски СРО. В медицине — сертификации и аккредитации. В аудите — членство в профессиональных ассоциациях. А в разработке ПО подрядчик может написать на сайте что угодно, и проверить это непросто.
Четыре типичных приёма «украшения» портфолио:
- Чужие проекты: компания указывает проекты, сделанные предыдущими работодателями основателей. Формально — «наш опыт», фактически — другая команда, другие процессы, другой контекст.
- Субподряд без маркировки: проект делал субподрядчик, а в портфолио он записан как «наш кейс». Команда, которая его реализовала, уже работает в другом месте и недоступна для вашего проекта.
- Преувеличение роли: компания сделала небольшую часть (верстку или одну интеграцию), но в портфолио это представлено как полноценная разработка с нуля.
- Устаревшие кейсы: проект 2019 года с другой командой, другим стеком и другим руководством выдаётся за показатель текущих компетенций компании.
Всё это не значит, что IT-компании сплошь мошенники. Однако ваша задача как продукт-менеджера крупной корпорации — отделить реальные компетенции от маркетинга. Давайте разберём, как это делать системно и эффективно.
Шаг 1: проверка портфолио IT компании по 5 критериям
Каждый кейс в портфолио оцениваем по пяти параметрам. Если кейс не проходит хотя бы по двум — это повод для дополнительных вопросов подрядчику.
| Критерий | Что проверяем | Красный флаг |
|---|---|---|
| 1. Релевантность | Похож ли проект на ваш по масштабу, отрасли, стеку | Все кейсы из другой отрасли или масштаба |
| 2. Глубина описания | Есть ли конкретные цифры, метрики, сроки | Только «красивые» скриншоты без деталей |
| 3. Верифицируемость | Можно ли связаться с клиентом, увидеть продукт | «NDA, не можем раскрыть клиента» |
| 4. Актуальность | Когда был реализован, работает ли ещё | Последний кейс старше 2 лет |
| 5. Роль команды | Что именно делали (full-cycle или часть) | Размытые формулировки «участвовали в проекте» |
Релевантность — самый важный критерий. Подрядчик может иметь 100 кейсов, но если все они — лендинги для малого бизнеса, а вам нужна корпоративная система с интеграцией в ERP — это нерелевантный опыт. Для корпоративного MVP ищите кейсы с comparable scope: enterprise-клиенты, интеграции с корпоративными системами, AI-компонент, работа в условиях корпоративного compliance и соответствия ФЗ-152.
Шаг 2: вопросы, которые раскрывают реальный опыт
Портфолио — это витрина. Реальную картину дают прямые вопросы при личном общении. Вот 10 вопросов, которые мы рекомендуем задавать на первом созвоне с потенциальным подрядчиком:
Про конкретный проект из портфолио:
- Кто в вашей команде работал над этим проектом? Эти люди ещё работают у вас?
- Какой был бюджет и сроки? Уложились ли в план? Если нет — почему?
- Какие были главные трудности при реализации? Как решили?
- Можно ли поговорить с клиентом или получить рекомендательное письмо?
- Продукт ещё работает в продакшне? Можно посмотреть демо?
Про компетенции команды:
- Сколько разработчиков будут работать конкретно над моим проектом? Каковы их роли?
- Какой стек используете для enterprise-проектов? Почему именно этот?
- Есть ли опыт интеграции с [ваша CRM/ERP — 1С, SAP, Bitrix24]?
- Как обеспечиваете качество кода (code review, тестирование, CI/CD)?
- Что происходит после сдачи проекта? Какая модель гарантийной поддержки?
Ключевой индикатор: конкретность ответов. Опытный подрядчик отвечает цифрами и фактами, называет имена конкретных разработчиков, показывает артефакты. Неопытный — общими фразами и обещаниями. Если на вопрос «уложились ли в сроки?» ответ «мы всегда укладываемся» — это не ответ, а маркетинг.
Портфолио IT компании: красные и зелёные флаги
После анализа десятков подрядчиков мы составили список индикаторов, которые помогают быстро отсеять ненадёжных кандидатов на первом этапе:
Красные флаги (повод отказаться или задать больше вопросов):
- Все кейсы под NDA — невозможно проверить ни один проект
- Нет технических деталей — только скриншоты и маркетинговые описания
- Команда «растёт под проект» — сейчас 3 человека, но «наймём ещё 5 под ваш проект»
- Нет отзывов от клиентов — ни на сайте, ни на Clutch/GoodFirms
- Последний завершённый проект — более 12 месяцев назад
- Обещают «любые технологии» — значит, ни в чём не специализируются
- Не могут объяснить, почему проект стоит именно столько — нет детальной декомпозиции
Зелёные флаги (повод продолжить диалог и углубить проверку):
- Кейсы с конкретными метриками: ROI, сроки, нагрузка, количество пользователей
- Готовность дать контакт клиента для referral call
- Стабильная команда: ключевые разработчики работают 2+ года
- Кейсы в вашей отрасли или с comparable scope (enterprise, интеграции, AI)
- Прозрачный процесс: описание этапов, артефактов, точек контроля
- Фиксированная цена с понятной декомпозицией работ по статьям
- Наличие гарантийной поддержки после сдачи проекта
Как проверить технические компетенции без технического бэкграунда
Продукт-менеджер не обязан разбираться в архитектуре и паттернах проектирования. Однако есть три способа оценить техническую зрелость подрядчика без глубоких технических знаний:
1. Попросите показать код (GitHub/GitLab). Даже если вы не читаете код, сам факт открытого репозитория говорит о прозрачности компании. Посмотрите: есть ли тесты (папка tests/), документация (README), регулярные коммиты (активность). Если подрядчик отказывается показать хотя бы один open-source проект — это повод задуматься.
2. Спросите про архитектуру словами бизнеса. Вместо «какой паттерн используете?» спросите: «Если через полгода нагрузка вырастет в 10 раз, что нужно будет изменить?». Опытный подрядчик ответит конкретно: «Ничего, архитектура масштабируется горизонтально» или «Нужно будет добавить кэш и балансировщик — это 2-3 дня работы». Неопытный — скажет «мы с этим разберёмся, когда придёт время».
3. Попросите провести технический аудит вашей текущей системы. Если подрядчик может за 2-3 часа дать обоснованную оценку существующего кода с конкретными рекомендациями по улучшению — это показатель экспертизы. Если ответ «всё нужно переписать с нуля» без аргументов — это красный флаг: опытный разработчик всегда предложит эволюционный путь.
В конечном итоге проверка портфолио IT компании — это инвестиция в снижение рисков вашего проекта. Час, потраченный на due diligence, экономит месяцы на исправление ошибок неудачного выбора подрядчика. А стоимость переделки неудачного MVP — в 2-3 раза выше стоимости первоначальной разработки.
Чек-лист проверки портфолио перед подписанием договора
Используйте этот чек-лист при оценке каждого кандидата. Идеально — проверить все 8 пунктов до подписания контракта:
- Релевантные кейсы: минимум 2-3 проекта, похожих на ваш по масштабу и сложности
- Referral call: получили контакт хотя бы одного клиента, поговорили и получили обратную связь
- Команда: знаете имена и роли людей, которые будут работать над вашим проектом
- Процесс: получили описание этапов работ с артефактами и точками контроля
- Стоимость: получили детальную декомпозицию бюджета по статьям расходов
- Сроки: подрядчик зафиксировал сроки в коммерческом предложении
- Технический аудит: подрядчик продемонстрировал техническую экспертизу на примере
- Поддержка: условия гарантийной поддержки зафиксированы в договоре
Если все 8 пунктов закрыты — можно переходить к подготовке бизнес-кейса для руководства с конкретным подрядчиком и цифрами. Если 3+ пункта не закрыты — продолжайте искать. Для разработки MVP корпоративного уровня лучше потратить лишнюю неделю на выбор, чем 3 месяца на переделку.
FAQ о портфолио IT компании
Что делать, если у подрядчика все кейсы под NDA?
NDA — нормальная практика для корпоративных проектов, но подрядчик должен найти компромисс: обезличенное описание кейса (без названия клиента, но с метриками и деталями), рекомендательное письмо от клиента (без раскрытия деталей проекта), или демо похожего решения на тестовых данных. Если подрядчик не может предложить ни один из этих вариантов — задумайтесь.
Сколько кейсов в портфолио должно быть у надёжного подрядчика?
Количество не важно — важна релевантность. Подрядчик с 5 кейсами в вашей отрасли ценнее, чем подрядчик с 200 кейсами из разных областей. Ищите 2-3 проекта, похожих на ваш по масштабу (enterprise), стеку (если критично) и предметной области (AI, интеграции, MVP).
Стоит ли проверять портфолио IT компании через отзывы на внешних площадках?
Да, но с оговорками. Clutch и GoodFirms — полезные площадки с верифицированными отзывами от реальных клиентов. Отзывы на Яндекс.Картах и Google Maps менее надёжны (легко сфабриковать). Лучший способ — прямой referral call с клиентом: 15-минутный звонок даёт больше информации, чем 50 анонимных отзывов на любой площадке.
Как отличить реальный кейс от приукрашенного?
Три индикатора: конкретные цифры (не «увеличили продажи», а «конверсия выросла с 2.1% до 3.8%»), описание трудностей (в реальном проекте всегда есть проблемы — если всё «гладко», кейс приукрашен), и актуальность (продукт ещё работает в продакшне и его можно посмотреть).
Нужно ли привлекать технического консультанта для проверки портфолио?
Для проектов с бюджетом от 3 млн рублей — рекомендуем. Технический аудит (2-4 часа работы консультанта) стоит 30-50 тыс. рублей и может сэкономить миллионы на переделке. Для проектов с бюджетом до 900K (MVP) достаточно самостоятельной проверки по чек-листу — риски ограничены фиксированной ценой.
Итого
Проверка портфолио IT компании — обязательный этап due diligence перед выбором подрядчика для корпоративного проекта. Пять критериев оценки (релевантность, глубина, верифицируемость, актуальность, роль команды), 10 прямых вопросов и чек-лист из 8 пунктов — этого достаточно, чтобы отделить реальных профессионалов от маркетинговых обёрток.
Главное правило: не верьте скриншотам — верьте цифрам, referral calls и конкретным ответам на прямые вопросы. Час на проверку портфолио IT компании экономит месяцы на переделку и миллионы на исправление ошибок неудачного выбора.
Хотите проверить, как мы проходим собственный чек-лист? Запишитесь на бесплатный Zoom-колл с командой IT Integration — покажем реальные кейсы с метриками, представим конкретных разработчиков и ответим на все 10 вопросов из этого гайда.