Как обмануть Железный Треугольник
Когда речь заходит о руководстве проектами, мы постоянно сталкиваемся с пресловутым Железным Треугольником
В этом треугольнике три вершины, которые описывают параметры проекта: объем работ, время и ресурсы. Можете жестко задать любые две из них, но не все три. Третья величина фиксироваться не должна. В противном случае проект окажется перегружен ограничениями.
Я прямо-таки вижу, как мой читатель глубокомысленно кивает - да, конечно, мы уже знакомы с этим треугольником.
И, несмотря на это некоторые из нас все же обнаруживают, что участвуют в проектах, где все три вершины "железного треугольника" уже заданы. Например, нам говорят, что мы должны разработать определенную функциональность за 18 месяцев с бюджетом 15 миллионов. Один из моих друзей постоянно получает задания, типа "у тебя есть четыре человека и три месяца, чтобы разработать вот такую функциональность". И, пусть с небольшими поправками, мы это делаем!
Секрет в том, что существует еще одна вершина, которую пока еще не оценили по достоинству: процесс разработки.
К сожалению, в большинстве организаций процесс разработки настолько неэффективен, что можно без особого труда увеличить продуктивность работы команды на 30%, всего лишь упростив его. Так мы сэкономим время и ресурсы, что даст нам возможность завершить проект (почти) в срок и (почти) уложиться в бюджет.
Вторая часть этого "секрета" состоит в том, что это ни для кого не секрет. Руководители проектов знали и использовали его на протяжении десятилетий. Я не уверен, что этот факт описывали в литературе, но старожилы часто рассказывали мне, как они давным-давно использовали то, что сейчас называется "гибкими методологиями", чтобы выполнить невыполнимый проект в срок.
