[Зміст]Показати зміст
Ми оцінили ~200 вендорів для власних продуктів. Самих нас оцінювали ~150 разів. Після 10 років: я кодив для команд і купував у команд. Прірва між good-on-paper і good-in-reality — гігантська.
Цей фреймворк — не академічний список. Він випав із конкретних проєктів, де щось пішло не так або пішло краще, ніж хтось очікував. Кожен критерій має причину існування та спосіб перевірки. Повну пропозицію побачите в огляді послуг, реальні впровадження — у реалізаціях.
Scorecard вибору software house — 10 критеріїв
Ці десять критеріїв беруться з провалів, не з теорії. Критерій 3 (склад команди) — junior-only команда впала нам на проєкті за 280k PLN. Критерій 6 (rescue) — кожен зрілий shop має за плечима проєкти, які мусив реанімувати. Якщо вендор не має таких історій, продає Вам лише вигладжену версію.
Як оцінювати портфоліо вендора?
Вендор показує 5 case studies, всі — успіхи. Червоне світло. Показує одну поразку і пояснює, як її виправив — тоді слухаєте. Це єдина міра, яка працює.
Попросіть 3-5 case studies з Вашої галузі або порівнянної складності. Не презентації — конкретику з метриками. Скільки тривав проєкт? Який був бюджет? Що пішло не так? Додайте другий тест: попросіть контакт клієнта з проєкту, який мав проблеми. Відмова — дискваліфікація.
2. Процес розробки — повторюваність понад креативність
Запитайте: як виглядає Ваш типовий Sprint? Хто виконує роль Product Owner? Як звітуєте про прогрес? Як обробляєте change request-и? Зрілий software house описує свій процес за 5 хвилин, бо він повторюваний. Поганий каже «ми підлаштовуємося під клієнта», що найчастіше означає відсутність процесу.
Перевірте, чи мають визначений Definition of Done, code review, CI/CD pipeline з першого дня. Це гігієна, не розкіш. У 2026 відсутність автоматичного тестування та деплойменту — сигнал, що компанія застрягла в 2015.
3. Команда — познайомтеся з людьми, а не зі слайдами
На етапі продажу спілкуєтеся з менеджером і senior-архітектором. Але хто реально напише Ваш код? Вимагайте познайомитися з командою, призначеною до проєкту. Перевірте пропорцію сеньйорів до джуніорів. Junior-only команда з одним senior-ментором — рецепт на катастрофу понад 500 робочих годин. Ми протестували це на власній шкірі, і коштувало нам чверть мільйона.
Запитайте про плинність. Понад 25% на рік означає, що Ваша команда зміниться під час проєкту. Кожна заміна програміста — це 2-4 тижні втраченої продуктивності, а контекстні знання витікають разом із ним.
4. Комунікація — частота та інструменти
Позірно дрібні питання генерують 80% фрустрації в ІТ-проєктах. Мінімальний стандарт: щоденний асинхронний статус, щотижневий call з демо, час реакції менше 4 робочих годин.
Сказали ми вендору: п’ятниця 16:00, технічне питання. Відповідь у вівторок. Ця дельта вбила дил. Один тест комунікації вартий більше, ніж десять обіцянок у пропозиції.
5. Підхід до невдач — тест на зрілість
Запитайте прямо: розкажіть про проєкт, який не вдався. Що пішло не так? Що Ви змінили в процесі після цієї невдачі? Компанія, яка стверджує, що ніколи не мала невдалого проєкту, бреше або не має достатнього досвіду. Шукайте партнерів, які говорять про невдачі відкрито — це означає культуру навчання, не маркетингу.
6. Rescue capability — вміння рятувати
Чи має компанія досвід у перейнятті проєктів після інших команд? Rescue mission вимагає швидкого аудиту, стабілізації та рефакторизації. Ці компетенції стануть у пригоді й у Вашому проєкті, коли з’являться непередбачені проблеми, а вони з’являться.
У Do More Soft rescue missions — близько 30% проєктів. Кожен з них навчив нас більше про інженерію програмного забезпечення, ніж десять greenfield-проєктів. Ці знання прямо перекладаються на якість нових впроваджень.
7. Цінова прозорість
Чесність в оцінці означає пояснити, як ця сума була розрахована. Скільки годин на окремі модулі? Який буфер на ризик? Що входить у scope, а що ні? Компанії, які подають одну цифру без розбиття, роблять оцінку «на око» або свідомо приховують витрати. У серйозних проєктах почніть із формального аудиту та консалтингу — це структурує оцінку та усуває сюрпризи.
8. Технологічна відповідність
Не йдеться про React vs Vue. Йдеться про те, чи стек пасує до Вашого контексту: наявної інфраструктури, компетенцій Вашої команди, довгострокових планів. Компанія, що нав’язує свою улюблену технологію без аналізу Ваших потреб, вирішує свою проблему, не Вашу.
Запитайте: чому Ви обрали б технологію X для мого проєкту? Відповідь «бо ми в цьому найкращі» — вихід із гри. Правильна містить аналіз Ваших вимог, обмежень і планів розвитку.
9. Культурна відповідність
Організаційна культура software house впливає на кожен аспект співпраці. Компанія з культурою «yes-man» ніколи не скаже Вам, що Ваша ідея погана. Компанія з інженерною культурою скаже й запропонує краще рішення. Шукайте партнерів, які можуть сказати «ні» й обґрунтувати чому. Це і є цінність, за яку Ви платите.
10. Договір — захист, не формальність
IP, NDA, гарантії, умови розірвання, escrow коду, SLA на підтримку після впровадження. Ці питання мають бути зрозумілі до підписання. Не залишайте їх юристу на кінець. Хороший договір захищає обидві сторони та визначає очікування. Особливо клаузула exit — що станеться, якщо співпраця не складеться? Чи отримаєте Ви вихідний код, документацію та knowledge transfer?
Які питання поставити software house перед контрактом?
Вендор казав, що має Definition of Done. Показали список у Jira. Ніхто не читав його 3 місяці. Це cargo cult. Ставте питання, які перевіряють практику, не декларацію: коли востаннє оновлювали DoD? Покажіть commit з code review, де senior відхилив PR джуніора. Покажіть продакшн-інцидент і post-mortem.
Фреймворк на практиці
Оцініть кожен критерій за шкалою 1-5. Сума нижче 35 — шукайте далі. Один критерій з оцінкою 1 — deal-breaker незалежно від суми. Найчастіші помилки: вибір найдешевшої пропозиції (платите двічі за rescue), вибір найбільшої компанії (Ваш проєкт для них неважливий), вибір на основі презентації (слайди не пишуть код).
Цей фреймворк — діагностичний інструмент. Бачите red flags рано — економите місяці. Ігноруєте, бо пропозиція гарна — маєте те, на що заслужили.
Хочете scorecard у PDF/Excel? Підпишіться на checklist нижче — надішлемо редагований шаблон із 10 критеріями та полями для оцінки трьох компаній поруч. А якщо хочете, щоб ми самі оцінили себе цим фреймворком — напишіть прямо. Поставите нам 1 у будь-якому критерії — скажемо, як це виправимо, або порекомендуємо конкурента, який у цьому кращий за нас.
FAQ
Які 10 критеріїв вибору software house? Портфоліо (case studies з поразками), процес розробки (повторюваність), команда (склад senior/junior, плинність), комунікація (час реакції), підхід до невдач, rescue capability, цінова прозорість, технологічна відповідність, культурна відповідність, договір (exit clause).
Як оцінювати портфоліо вендора? 5 успіхів без жодної поразки — red flag. Вимагайте контакту клієнта з проєкту, що мав проблеми. Перевірте метрики: час, бюджет, scope creep, утримання команди.
Що таке red flags при виборі партнера для розробки? Відсутність процесу («ми підлаштовуємося під клієнта»), junior-only команда, плинність понад 25% на рік, оцінка однією цифрою без розбиття, культура «yes-man», відмова в контакті до складних клієнтів, відсутність клаузули exit у договорі.