Математика переписування легасі: як проєкти втрачають час і гроші

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

2025-09-15

Примітка: це фрагмент іншої статті про переписування легасі-систем. Тут ми лише прикидаємо, скільки може коштувати переписування. Жодних рекомендацій — вони є в основному матеріалі. Тут лише цифри.

Вступ

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

Але загальні результати будуть приблизно такими, як тут написано.
Не тіште себе ілюзіями: навіть якщо ми уточнимо математичну модель проблеми, дива не станеться. Місяцем довше чи місяцем швидше — несуттєво.

Ми просто зазирнемо в кролячу нору й подивимось, наскільки вона глибока — як це колись зробила Аліса.

Початкові дані

Зробімо картинку красивою, а цифри — рівними.

• У нас є проєкт. Це справжній легасі-звір — такий самий, який ми всі так любимо ненавидіти — і ми хочемо переписати його в щось новеньке й блискуче.
• Вік проєкту: 10 років.
• Увесь цей час над ним працювали 4 людини, витрачаючи близько 600 годин на місяць.
• Загальні накопичені трудовитрати: 72 000 людино-годин.
• І поки ми переписуємо, проєкт не завмирає — він продовжує зростати: +600 годин щомісяця.

Чи зростає кодова база?

Хтось може заперечити: «А може ці +600 годин щомісяця йдуть лише на багфікси й саппорт? Тоді їх можна ігнорувати».

Може й так. Насправді ми не знаємо, куди йдуть ці години. Це може бути чистий багфікс і підтримка, просто щоб тримати проєкт на плаву. Або ж це можуть бути 600 годин нового функціоналу щомісяця.

Іронія в тому, що це знання нас не врятує. Навіть якби ми знали, команда, яка переписує, все одно не змогла б чітко відокремити багфікси від нових фіч. Їм у будь-якому випадку доведеться пройти через усі ці 600 годин щомісячних змін — принаймні проаналізувати й вирішити, що з ними робити.

👉 Тож приймемо як допущення: проєкт зростає на +600 годин щомісяця.
Життя — біль.

Хто буде переписувати?

Ми визначили обсяг задачі, тепер давайте вирішимо, хто її буде переписувати.

Очевидний, але хибний варіант: «Нехай поточні розробники переписують».

Ні. Ви не можете просто відволікти тих 4 розробників від їхньої роботи. Саме вони рухають продукт уперед, і якщо переключити їх на переписування — це чистий opportunity cost. Тобто бізнес втратить усе, що вони могли б зробити за цей час: підтримку, багфікси й нові фічі.

Інакше кажучи, продукт завмре, поки компанія продовжує платити зарплати за роботу, яка не приносить прямої цінності.

❌ Неприйнятно — ці 4 мають залишитися на своїх поточних завданнях.

👉 Для переписування доведеться залучити нових розробників. Принаймні стільки ж — ще 4 розробники, виділені виключно під переписування.

Швидкість переписування

Так, переписування завжди швидше, ніж розробка «з нуля».

Але наскільки швидше?

• ×2 (правдоподібно),
• ×4 (сумнівно),
• ×6 (дуже сумнівно 🦄),
• ×8 (чиста фантазія 🦄).

І зверніть увагу: ці дві останні «команди мрії» переписували б за місяць у складі 4 людей такий обсяг коду, який у розробці займав 3600–4800 людино-годин. Це вже чиста магія 🦄.

Сценарії та терміни

Команда з 4 людей (нова, для переписування)

Навіть у наших уявних dream🦄 сценаріях (×6 і ×8) терміни все одно залишаються неприйнятними.

А що буде, якщо команда для переписування складатиметься з 8 людей?

Команда з 8 людей (нова, для переписування)

Пам’ятайте, що ці дві останні команди (×6 і ×8 з 8 розробниками) — це вже чиста магія 🦄.

Тим часом бюджет порівняно з поточними витратами на розробку вже зріс утричі.

Висновок

Я промовчу, які саме слова використав би власник, фінансовий директор та інші люди, які справді вміють рахувати гроші.

P.S. У більш точній моделі ситуація не просто гірша, ніж показано у цих розрахунках — вона помітно гірша.