Как все помнят из школьной программы, сумма затраченных работ всегда равна приобретённой работе за вычетом неизбежных потерь. Какое отношение это имеет к управлению проектами? Самое прямое: делаете ли вы быстрый говнокод и часто фиксите баги, либо долго и размеренно работаете по правильным методикам с тестированием и бла-бла-бла, – в любом случае в долгосрочной перспективе результата X вы достигнете через равные промежутки времени.
Если нет разницы, то зачем платить больше? Да и для маркетинга быстрый старт (пусть и в говнокоде) принесёт огромный профит. Как может догадаться проницательный читатель, если бы не было разницы, то не было бы и смысла писать этот пост. А разница есть, и она заключается в одной фразе:
Разработка программного продукта – нелинейна.
Многие владельцы бизнесов рассуждают так: вот у нас появилась лишняя копеечка в бюджете, щас мы наймем грамотных разработчиков и менеджеров (вместо тех, плохих) и с этого момента времени у нас всё будет хорошо.
Это прекрасная теория для того случая, чтоб рисовать на большом листе бумаге непрерывную линию. Плохо пишет старая шариковая ручка? Заменим её другой, более качественной, и дальше наша линия пойдет чистой и яркой.
Разработка софта в реальности имеет совершенно другую аналогию – с водопроводной сетью. Если у вас протекает ржавая труба на первом километре от водокачки, то вы не получите мощного напора воды в новом доме на другом конце города. Какие бы “нанотехнологии” не применялись при его строительстве.
В программном продукте любая новая задача обязательно требует модификации старых механизмов. Это простая истина, которую трудно осознать. Существует жалкий процент задач, которые можно “прилепить сбоку” к проекту, не затрагивая его внутренности. Все мало-мальски серьёзные задачи требуют модификции внутри.
И с течением времени жизни проекта любая оценка трудоёмкости новых задач начинает включать в себя неустранимый компонент – время на исправление старых ошибок:
T_estimate = T_solve + T_bugfix
Оценочное время выполнения задачи = Время решения + Время исправления неожиданных багов.
Не нужно быть семи пядей во лбу, чтобы оценить T_solve. Это может сделать любой разработчик, так или иначе представляющий себе план решения задачи. Да, с оговоркой, что точно оценить задачу можно только выполняя её второй раз – и тем не менее, какую-то плановую оценку дать можно.
Но оценить T_bugfix заранее нельзя.
Коллеги из других компаний иногда делятся со мной статистикой, даже не подозревая какую интересную информацию можно из неё извлечь: в одном из проектов на 2500 коммитов в репозиторий было 1500 багов в багтрекере. О чём это говорит? О том, что на каждые три правки в систему вносилось два новых бага. Эпик фейл.
Поэтому я принимаю для себя закон сохранения работы (вернитесь взглядом к первому абзацу) в совершенно противоположном направлении: каждая сэкономленная минута “сейчас” обернётся затраченной минутой “потом” плюс неизбежные потери.