Чому важливо оцінювати складність?

АлгоритмиJunior~2 хв читання

Коротка відповідь

Оцінка складності допомагає прогнозувати терміни і вартість, розставляти пріоритети, керувати ризиками і вибором архітектури, синхронізувати очікування з бізнесом і командою, а також підвищувати передбачуваність поставки без переробок і техборгу.

Розгорнута відповідь

Навіщо оцінювати складність у розробці

Прогноз термінів і бюджету: дозволяє планувати релізи і домовлятися про контрактні зобов'язання.
Пріоритизація: обирати задачі з кращим співвідношенням цінність/вартість (ROI).
Управління ризиками: раннє виявлення залежностей, вузьких місць і невизначеностей.
Вибір архітектури і компромісів: зрозуміти, де виправдана складність, а де - KISS/здешевлення.
Синхронізація очікувань: єдина мова між розробкою, QA, аналітиками і бізнесом.
Контроль скоупу: усвідомлені компроміси, щоб вкластися в дедлайн без втрати якості.
Покращення процесів: метрики влучання в оцінку і ретроспектива причин відхилень.

Що саме ми оцінюємо

Алгоритмічну складність і обсяг даних (Big-O, пам'ять, масштабованість).
Обсяг робіт: фічі, інтеграції, міграції, тестування, документація, реліз.
Невизначеність і ризики: невідомі вимоги, протоколи, доступи, нестабільні API.
Залежності: інші команди, бібліотеки, інфраструктура, вікна на реліз/безпеку.
Нефункціональні вимоги: продуктивність, доступність, SLA, спостережуваність.
Якість і безпека: код-рев'ю, тест-піраміда, секрети, відповідність політиці.

Як оцінювати на практиці

Розбийте на атомарні задачі з критеріями приймання (Definition of Done).
Оберіть шкалу: story points, T-shirt sizes, людино-дні/години (для контрактів).
Врахуйте ризики і додайте буфер (на дослідження, очікування доступів/рев'ю/релізу).
Звіртеся з історичними даними і velocity команди.
Валідуйте оцінку з командою (планінг-покер, асинхронне опитування, експертна калібровка).
Переглядайте оцінку в міру появи нової інформації (rolling-wave planning).

Часті помилки

Плутати оцінку і обіцянку: оцінка - це прогноз з ймовірністю, а не гарантований дедлайн.
Не враховувати повний цикл: аналіз, UX, тести, рев'ю, фікси, реліз, план відкату.
Ігнорувати залежності і зовнішні черги (DevOps, безпека, суміжні команди).
Переускладнювати рішення або робити передчасну оптимізацію.
Відсутність критеріїв готовності - складно оцінити те, що погано сформульовано.
Оптимістичне зміщення і якоріння без опори на історичні дані/факти.
Не оновлювати оцінку при зміні скоупу або вимог.

Приклад: вплив алгоритмічної складності на терміни

Одна й та сама бізнес-задача може мати різні варіанти реалізації з різною складністю. Наприклад, пошук двох чисел із заданою сумою:

// Варіант 1: наївний O(n^2)
function twoSumBruteForce(nums, target) {
  for (let i = 0; i < nums.length; i++) {
    for (let j = i + 1; j < nums.length; j++) {
      if (nums[i] + nums[j] === target) return [i, j];
    }
  }
  return null;
}

// Варіант 2: через хеш-таблицю O(n), дод. пам'ять O(n)
function twoSumHash(nums, target) {
  const map = new Map();
  for (let i = 0; i < nums.length; i++) {
    const need = target - nums[i];
    if (map.has(need)) return [map.get(need), i];
    map.set(nums[i], i);
  }
  return null;
}

Для невеликих n наївне рішення може бути швидшим у розробці (менше коду), дешевшим за часом реалізації.
Для великих n наївне рішення не масштабується - зростуть час відгуку і вартість інфраструктури.
Оцінка складності заздалегідь дозволяє обрати реалізацію, яка збалансує time-to-market і експлуатаційні витрати (OPEX).

Міні-шаблон для оцінки задачі

Задача: [короткий опис]
Критерії приймання (DoD):
- [ ] Що має працювати
- [ ] Тести: unit/e2e, покриття
- [ ] Логи/метрики/алерти
- [ ] Документація/Changelog
- [ ] План релізу і відкату

Розбиття на підпункти:
1) Аналіз і уточнення вимог - X год
2) Бекенд/Фронтенд/Інтеграції - X год
3) Тести/рев'ю/фікси - X год
4) Реліз/валідація - X год

Ризики/невідомі:
- [ ] Доступи і залежні команди
- [ ] Нестабільні API/схеми
- [ ] Продуктивність/навантаження

Оцінка: min-most-max = a-m-b (год), очікувана = (a + 4m + b) / 6
Буфер на ризики: ~10-30% залежно від невизначеності
Впевненість: ~60-80%

Коли точну оцінку дати не можна

Це нормально - тоді використовуйте інтервальні оцінки і явно вказуйте рівень впевненості.

Діапазони: «2-4 дні» замість «3 дні».
Рівень впевненості: «70%»; причини невизначеності перелічіть явно.
Триточкова оцінка (PERT): оптимістична, найбільш вірогідна, песимістична.

Підсумок

Оцінка складності - це інструмент управління продуктом та інженерією: вона робить поставку передбачуваною, рішення - обґрунтованими, а ризики - керованими. Регулярно уточнюйте оцінки і фіксуйте припущення - так ви будете вкладатися в терміни і зберігати якість.

Коротка відповідь

Для співбесіди

Premium

Коротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.