НовостиСобытияКонференцииФорумыIT@Work
ИТ-менеджмент:

Блог

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

Алексей Лосев
16.07.2014 17:57:08

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

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

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

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

Комментариев: 8

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии

17.07.2014 09:02:27

Не очень понял, в чем "мораль басни".

Да, управление проектами – это оптимизация, поиск компромиссов между противоречивыми требованиями (деньги – время – качество).

Если такое известный афоризм – "Дешево! Быстро! Качественно! Выберите любые два из трех" (три одновременно – невозможно!)

Да, эти параметры связаны между собой существенно нелинейным образом. А для ПО все обстоит намного сложнее, чем с материальными объектами, хотя бы потому, что тут намного сложнее обстоит дело с определением качества.
А сложность планирования связана, в том числе с тем, что производительность труда программистов даже примерно одного уровня может легко отличаться в 3-10 раз.

Но что же делать?
Насколько я помню одним из первых эту проблему поднял Брукс в своей классической работе "Мифический человеко-месяц" в начале 70-х. Дал анализ сути проблем, предложил подходы в их решения (не готовые методики, а именно подходы – тут все очень трудно формализуемо).

Да, и Йодан (именно так писалось по-русски его фамилия в 70-х) хорошо описал важные аспекты проблем же времен.

Но что и как можно посоветовать сегодня по теме? И кому советовать – руководителям проекта или бизнес-руководителям?

17.07.2014 09:48:52

Сейчас для многих IT это как электричество в начале 20-го века. Почти магия. Хотя с современным развитием этого направления производства уже можно жить так-же, как и с любым другим. Ведь никто не заказывает построить атомный ледоход за 3 недели и 20 рублей? А в IT такое сплош и рядом. Но, и IT в этом отношении не отстает. Мы все такие творческие, мы не можем ничего оценить, то что из материального производства у нас не работает. Хорошо хоть в последнее время некие положительные тенденции наметились. Вот начались разговоры о применении методики из производства середины прошлого века барабан-буфер-канат в Скрам. Еще раз, середины прошлого века, а для IT это все как откровение...

17.07.2014 12:25:15

Но все же - давайте попробуем сформулировать постановку вопроса - что мы тут хотим обсужить и какую проблемы решить?
Руководители программных проектов не используют "правильные методики" разработки?
Бизнес-руководители не понимают специфики проектов и потому неверно подходят к планированию?
Что?

17.07.2014 12:42:31

Мы пытаемся решить проблему, что в большинстве случаев ставиться задача: улучшить, углубить, расширить. А вот к тому, что в процессе придется жертвовать чем то другим, к этому мало кто готов. Внедряем внешнюю систему мотивации, все должны быть к тому, что угробим внутреннюю. И таких примеров тысячи, но запуская новый проект, ставя новый KPI, про это как то забывается и оцениваются только положительные эффекты.

21.07.2014 20:25:47

Как говорят англичане, - "Из двух зол не выбирают". Разберитесь, что в вашем проекте есть целевая функция, которая может носить комплексный характер. Возможно, после этого наступит ясность в мыслях?

23.07.2014 16:28:58

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

23.07.2014 20:18:31

Прежде, чем что-то писать, обратите внимание, как прекрасен лист белой бумаги.

23.07.2014 20:35:34

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

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии