НовостиОбзорыСобытияIT@Work
ИТ-менеджмент:

Блог

А чем вы готовы пожертвовать?

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

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

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

Ну, а вот и жертвы: согласны ли вы платить в два раза больше, чтобы сократить время на 30% в левой части графика, и платить в десятки раз больше, чтобы выгадать лишние 3-4% в его конце?
Какие выводы из всего этого? Да, наверно, всего один: рост одного показателя всегда связан с потерями в другом. Причем, на разных этапах роста нам придется жертвовать по-разному.
Лосев Алексей
Отличное предложение. Вы тренер  Дэвида Рудиша, который является действующим чемпионом мира в беге на 800 метров (да, его результат есть на том первом графике). Вот вам целевая функция: пробежать 1000м, причем бежать нужно со средней скоростью выше, чем Дэвид показывает на 800м. Возьметесь? А то вот у меня нет ясности в мыслях, как этого можно добиться...
Романов Андрей
Прежде, чем что-то писать, обратите внимание, как прекрасен лист белой бумаги.
Лосев Алексей
Спасибо, Андрей, вы просто открыли мне глаза на белый лист.  
Т.е. по существу вам ответить нечего и в предложенном мной варианте вы не видите как достичь предложенной мной целевой функции? Ну а раз так, значит как минимум на одного человека станет больше, который ставя целевые функции, носящие комплексный характер, будет задумываться к каким негативным последствиям это может привести.