Закон Хофштадтера в разработке ПО

В начале 2000-х, на заре интернета, информации о том, как оценивать проекты, почти не было. Приходилось идти на ощупь, доверяя простой формуле: «рынок порешает». Практика быстро расставляла акценты – ночные звонки, конфликты с заказчиками, жёсткие разборы полётов.

Помню первые проекты. Беру задачу – сделать свод отчётов для филиалов МЧС по Кировской области с учётом отраслевых форм и стандартов. Оцениваю честно: месяц, максимум два. Через месяц появляется первый рабочий отчёт. И становится понятно: оценка уже не сходится.

К этому моменту появляются новые требования, часть прежних теряет актуальность. Заказчик спрашивает: «Успеваем?». Внутри напряжение – задача уже другая, требуется пересогласование. Но это не проговаривается. Идёт попытка любой ценой дотянуть прежние обязательства до конца.

В какой-то момент приходит понимание: развитие должно затрагивать не только техническую часть, но и способность оценивать «нормальность» ситуации. Возникает необходимость сменить тактику – отказаться от бесконечных оправданий и пересобрать подход.

Следовал логике ИТ-наследия – «так у всех, это нормально». Но внутри это не принималось. Чувство вины накапливалось. Формировалось ощущение постоянного долга перед заказчиком: аванс получен, результата нет. Работа продолжается ночами, срок всё равно уходит.

У заказчика, конечно, формируется предубеждение в отношении программистов:

1. Опять эти айтишники пообещали и не сделали.
2. Сказали «в пятницу» – только какую именно, не уточнили.
3. Заставляют покупать какие-то СУБД – всё усложняют, хотя раньше и так всё работало.

Тогда не было понимания: дело не в личной слабости – это закономерное последствие подхода. Закон Хофштадтера в чистом виде. Возникала мысль: «Нужно лучше планировать, жёстче себя контролировать». Но чем жёстче становился контроль, тем больнее было падать.

Осознание закона Хофштадтера

Через этот набор проблем проходил почти каждый новый разработчик. Опорой становились поддержка и опыт коллег. В ходу были объяснения: «такая отрасль», «нужно побороть эффект самозванца». Но суть проблемы оставалась без изменений.

В 2015 году начался активный поиск ответов в индустрии – как решаются похожие задачи, на что опираются при оценке. Чёткое объяснение нашлось в законе Хофштадтера: «Дела всегда занимают больше времени, чем ожидается, даже если учитывать этот закон».

Такова природа взаимодействия постановщика задачи и разработчика. Это не ошибка разработчика, а особенность модели взаимодействия. Каждая попытка пойти навстречу и сыграть «хорошего парня» приводила к одному и тому же результату – всплывали неучтённые факторы:

1. Документация устаревала, актуализация не закладывалась в оценку.
2. Локальные задачи вскрывали системные проблемы – обход через заплатки увеличивал риски, полноценное решение требовало переработки системы.
3. Новые требования появлялись по ходу разработки, объём работ рос, отказ не озвучивался.

Пришло осознание – закон Хофштадтера не отменить. Значит, требуется перестроить систему управления так, чтобы снизить риски ошибок в оценке.

Как мы пришли к трём золотым правилам оценки задач

В следующие годы пробовали разные подходы: добавление 30% к оценке, переход на story points, введение буферов. Ничего не давало устойчивого результата. Суть не менялась: разработчик давал прямую оценку и брал ответственность на себя, затем винил себя. Заказчик терял доверие.

И только в последние пять лет сформулировали и отточили три золотых правила, которые системно решают проблему. Не про точность оценок – про честность и управляемость процесса.

Золотое правило №1. Разработчик не сообщает оценку напрямую заказчику

Разработчик даёт оценку только тимлиду или РП – как техническую экспертную информацию. Мы берём эту оценку и превращаем в обязательство перед заказчиком с учётом закона Хофштадтера, репутации команды и исторических данных. Вот в чём ценность правила:

1. Разработчик перестаёт бояться фразы «точной оценки нет».
2. Исчезает стратегическая игра «кто сильнее занизит оценку».
3. Забираем у разработчика риски планирования сроков, опираясь на экспертную оценку.

В процессе онбординга мы проговариваем с разработчиком: «Твоя задача – честно сказать, сколько это может занять по ощущениям. Наша задача – превратить это в обязательство, которое не будет сорвано. Здесь нет обмана заказчика – есть разделение языков и ролей».

Золотое правило №2. РП корректирует полученную оценку, закладывая риски и понимая особенности конкретного разработчика

Тимлид знает историю каждого разработчика. Саша стабильно занижает оценку в два раза, при этом сохраняет качество. Николай даёт честные оценки, но регулярно переключается на поддержку. У Насти высокий разброс – задача может занять два часа, может десять. Антон меняет правила игры – внедряет ИИ в разработку.

Ценность:

1. Начали использовать статистику, а не гадать
2. Перестали требовать от всех одинаковой «точности».
3. Разработчики перестали обижаться на «поправки», поняв: это не недоверие, а страховка.

Фраза, которую повторяем на ретро: «Я не доверяю твоей оценке. Моя картина мира более полная, ты можешь не знать – как прошлые задачи расходились с прогнозом, как загружена команда и какие риски уже в очереди. Моя поправка – перевод с языка "идеального мира" на язык "реального"».

Золотое правило №3. РП и разработчик регулярно обсуждают план-факт выполнения работ и понимают, как использовать резервы

На ежедневных летучках РП и разработчики сверяют часы: факт – 12 часов, план – 10. Переработка – 2 часа, потребность – ещё 4. Следующий вопрос – как действовать дальше и есть ли запас.

Или: «Я уже использовал 80% резерва, нужно пересмотреть план» – это звучит за 3 дня до дедлайна, а не в 3 часа ночи перед сдачей.

Почему это важно:

1. Разработчик перестал паниковать при первых признаках отклонения.
2. Начали прогнозировать отставания заранее, не дожидаясь последнего момента.
3. Буфер перестал быть «неприкосновенным запасом» и стал рабочим инструментом.

Фраза, которая висит у нас на стене в офисе: «Предусмотрительность создаёт качественный сервис». Задача не в том, чтобы догонять любой ценой. Задача – вовремя зафиксировать реальность, пока остаётся пространство для действий.

Резервы создаются для использования. Молчание – единственный непростительный грех.

Что изменилось за 5 лет

Сегодня: оглядываясь назад, вижу чёткую границу. До введения роли РП и правила «разработчик не обсуждает трудозатраты с заказчиком»:

1. Чувство вины копилось и вело к выгоранию.
2. Разработчики обманывали себя и заказчиков.
3. Закон Хофштадтера был личным поражением.

После появления роли РП и внедрения трёх золотых правил:

1. Тимлиды корректируют оценки под человека и риски – проекты стали более предсказуемы.
2. Разработчики не дают оценок напрямую – уровень стресса минимальный.
3. План-факт с резервами – рутина, а не катастрофа.

Стажёрам рассказываем историю: «Когда начинали, казалось, профессионал – тот, кто точно оценивает, быстро делает и не задаёт лишних вопросов. Жизнь научила: качественный сервис строится на диалоге, быстрой реакции и оправданных ожиданиях.

Чтобы закон Хофштадтера не разрушал доверие, требуется разделение ролей переговорщика и разработчика. Три золотых правила – не инструкция по оценке задач, а технология управления в мире недостижимой точности. Не идеал – вывод из практики: остальное не сработало.