Бета была готова к Новому году. Финальная версия заняла еще 4 месяца и сотню тикетов.
Мы автоматизировали расчет роялти для музыкального лейбла. Каталог артистов, дистрибьюторы, квартальные отчеты, выплаты. Первая рабочая версия — парсинг данных, расчеты долей, дашборды в Metabase — заняла предсказуемые 6-8 недель. К январю система работала.
А потом начались вторые 80%.
Реальность обновилась — числа разъехались
Клиент обновил каталог. Потом еще раз. Изменились условия у дистрибьютора. Добавились артисты. Каждое уточнение влияло на расчеты за прошлые кварталы — данные за 2024 и 2025 годы пересчитывались заново. Числа, которые вчера сходились, сегодня расходились. Не потому что код сломался. Потому что реальность обновилась.
В пиковые недели приходило по 20 тикетов. За 4 месяца набралось больше ста.
Самое тяжелое — не объем работы. Проект «почти готов» три месяца подряд. Каждую неделю кажется: вот эта партия правок — последняя. Но за ней приходит следующая. Это изматывает исполнителя и нервирует клиента.
На разборе проекта мы сформулировали точно: первые 80% были готовы. А потом начались вторые 80%. Звучит как шутка. Но это непреложный закон.
Том Каргилл из Bell Labs сформулировал похожее правило в 1985 году: первые 90% кода занимают 90% времени, оставшиеся 10% — другие 90%. Но у нас дело было не в коде. Код работал. Проблема — данные. Каталог с тысячами треков, ставки, которые меняются посреди квартала, условия, зависящие от других условий. Каждый пересчет — пайплайн обработки, сверка с каталогом-источником, генерация PDF-отчетов.
За три месяца этих доработок я потратил 4 миллиарда токенов в Claude. Без AI такой объем пересчетов был бы физически невозможен для одного человека.
Правило 2X
Мы вынесли одно правило: когда оцениваешь проект для клиента, закладывай 2X на доработки после беты. Не потому что плохо планируешь. Потому что живые данные, живые пользователи и живые требования — это не продолжение разработки. Это другой проект.
