Запропонувати правку

Покращити цю статтю

Допрацюйте відповідь до «Чому важливо оцінювати складність?». Ваші зміни проходять модерацію перед публікацією.

Потрібне підтвердження

Контент

Що ви змінюєте

Заголовок (UA)

Коротка відповідь (UA)

Показується над повною відповіддю для швидкого нагадування.

Відповідь (UA)

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

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

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

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

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

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

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

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

1. Розбийте на атомарні задачі з критеріями приймання (Definition of Done).
2. Оберіть шкалу: story points, T-shirt sizes, людино-дні/години (для контрактів).
3. Врахуйте ризики і додайте буфер (на дослідження, очікування доступів/рев'ю/релізу).
4. Звіртеся з історичними даними і velocity команди.
5. Валідуйте оцінку з командою (планінг-покер, асинхронне опитування, експертна калібровка).
6. Переглядайте оцінку в міру появи нової інформації (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): оптимістична, найбільш вірогідна, песимістична.

### Підсумок

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

Markdown · перетягуйте зображення · ⌘B / ⌘I шорткати671 слів

Для рев’юера

Примітка для модератора (необов’язково)

Бачить лише модератор. Прискорює рев’ю.