Закон сохранения работы

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

Если нет разницы, то зачем платить больше? Да и для маркетинга быстрый старт (пусть и в говнокоде) принесёт огромный профит. Как может догадаться проницательный читатель, если бы не было разницы, то не было бы и смысла писать этот пост. А разница есть, и она заключается в одной фразе:

Разработка программного продукта – нелинейна.

Многие владельцы бизнесов рассуждают так: вот у нас появилась лишняя копеечка в бюджете, щас мы наймем грамотных разработчиков и менеджеров (вместо тех, плохих) и с этого момента времени у нас всё будет хорошо.

Это прекрасная теория для того случая, чтоб рисовать на большом листе бумаге непрерывную линию. Плохо пишет старая шариковая ручка? Заменим её другой, более качественной, и дальше наша линия пойдет чистой и яркой.

Разработка софта в реальности имеет совершенно другую аналогию – с водопроводной сетью. Если у вас протекает ржавая труба на первом километре от водокачки, то вы не получите мощного напора воды в новом доме на другом конце города. Какие бы “нанотехнологии” не применялись при его строительстве.

В программном продукте любая новая задача обязательно требует модификации старых механизмов. Это простая истина, которую трудно осознать. Существует жалкий процент задач, которые можно “прилепить сбоку” к проекту, не затрагивая его внутренности. Все мало-мальски серьёзные задачи требуют модификции внутри.

И с течением времени жизни проекта любая оценка трудоёмкости новых задач начинает включать в себя неустранимый компонент – время на исправление старых ошибок:

T_estimate = T_solve + T_bugfix

Оценочное время выполнения задачи = Время решения + Время исправления неожиданных багов.

Не нужно быть семи пядей во лбу, чтобы оценить T_solve. Это может сделать любой разработчик, так или иначе представляющий себе план решения задачи. Да, с оговоркой, что точно оценить задачу можно только выполняя её второй раз – и тем не менее, какую-то плановую оценку дать можно.

Но оценить T_bugfix заранее нельзя.

Коллеги из других компаний иногда делятся со мной статистикой, даже не подозревая какую интересную информацию можно из неё извлечь: в одном из проектов на 2500 коммитов в репозиторий было 1500 багов в багтрекере. О чём это говорит? О том, что на каждые три правки в систему вносилось два новых бага. Эпик фейл.

Поэтому я принимаю для себя закон сохранения работы (вернитесь взглядом к первому абзацу) в совершенно противоположном направлении: каждая сэкономленная минута “сейчас” обернётся затраченной минутой “потом” плюс неизбежные потери.