Блог

Принимая решения, мы выбираем из двух и более зол. Что-то начинаем улучшать, а что-то другое начинает ухудшаться. Перед тем, как поговорить об управлении проектами, я предлагаю посмотреть вот на эту диаграмму [spoiler] из мира легкой атлетики:

Эта диаграмма, построенная на основе данных с wikipedia, показывает, как меняется средняя скорость бега в зависимости от дистанции: чем быстрее нам надо бежать, тем меньшую дистанцию мы сможем поддерживать эту скорость. Причем, это идеальный тренд, построенный на основе мировых рекордов. Также дело обстоит с переработками. Небольшие на короткий срок оправданы, а большие, как показывает Эдвард Йордон в книге «Путь камикадзе», ситуацию с производительностью ухудшают:

Ну, и последний на сегодня пример: проектный треугольник.
Оговорюсь сразу, мне очень не нравится изображение параметров проекта - времени, ресурсов и объема работ - в виде граней треугольника. Например, если мы увеличиваем объем работ, то, по идее, должны увеличиться время и требуемые ресурсы. Но, если мы увеличиваем выделяемые на проект ресурсы, то это вообще не влияет на объем работ, да к тому же, уменьшает время. Опять же, зависимости абсолютно не линейны. Допустим, у нас есть некий коробочный продукт с фиксированным функционалом. Понятно, что все предусмотреть нельзя, и в процессе объем работ может существенно меняться. Да, даже не смотря на фиксированный функционал. Например, мы столкнулись с технологической проблемой, и пришлось переписать часть проекта на другой библиотеке. Функционал не поменялся, а вот объем работ...
Хорошо, предположим, один показатель мы зафиксировали. Начинаем анализировать зависимость времени, необходимого на разработку, от объема выделяемых ресурсов. Понятно, что ниже определенного уровня ресурсов проект вообще не может быть выполнен (нужно помещение, вычислительные мощности, люди). При увеличении выделяемых ресурсов время сокращается. Но, во-первых, этот процесс так же, как и с бегом, будет нелинейным, а во-вторых, будет иметь место насыщение. Т.е. после достижения определенного значения объема выделенных ресурсов, дальнейшее их увеличение не будет влиять на необходимое время. Это происходит от того, что задачи можно распараллеливать только до определенного предела. И если вы не можете загрузить имеющиеся вычислительные ресурсы на 100%, то дальнейшее их увеличение также не сократит время. Следовательно, график будет иметь вид:

Ну, а вот и жертвы: согласны ли вы платить в два раза больше, чтобы сократить время на 30% в левой части графика, и платить в десятки раз больше, чтобы выгадать лишние 3-4% в его конце?
Какие выводы из всего этого? Да, наверно, всего один: рост одного показателя всегда связан с потерями в другом. Причем, на разных этапах роста нам придется жертвовать по-разному.