3.2.1.Проектный треугольник
Рассмотрим отдельно и подробнее такое важное понятие, как проектный треугольник, или «треугольник управления проектом».
Условно его идею можно сформулировать в одну строку:
«Быстро – Качественно – Дешево: выберите любые два пункта».
Из этого получается:
- хочется быстро и качественно – будет дорого;
- нужно дешево и качественно – будет долго;
- нужно быстро и дешево – будет, очевидно, некачественно.
Как следует из определения проекта – нужно сделать определенный объем работ (закрыть требования к автоматизации) за определенное время (у проекта есть дата начала и окончания) и за определенный бюджет (зависит от привлекаемых к работе ресурсов, нормы прибыли компании-исполнителя и т. п.). Получаем проектный треугольник со сторонами: сроки, ресурсы (стоимость), объем работ.
Все эти величины имеют верхние пределы:
- разумный срок, далее которого проект автоматизации теряет смысл: система устареет, бизнесу жить годы без автоматизации тяжко;
- конечное количество денег у компании, которое она готова заплатить за проект;
- конечный список требований, который нужно автоматизировать (список со стороны заказчика может быть изначально большим, но все равно у него где-то есть конец).
Рис. 3.4. Проектный треугольник
Качество, как четвертый параметр, находится внутри треугольника и напрямую зависит от всех трех граней – как результат того, что делается с объемом работ за отведенное время и выделенные средства.
Внесение изменений в одну из сторон треугольника меняет как минимум еще одну связанную сторону.
Нематериальность выходной продукции в проекте автоматизации создает иллюзию того, что для внесения изменения в список требований или в уже реализованные требования нужны незначительные усилия. Это заблуждение! Для понимания можно приводить аналогию со стройкой и сносом и переделкой кирпичной стены, если ее нужно сдвинуть, например, на 15 см. «Кирпичики» кода системы тоже нужно разобрать и перенести – пусть это не физические, а умственные усилия исполнителей, но время это занимает, как и перекладка кирпичей.
Далее в таком треугольнике проявляется конфликт интересов заказчика и исполнителя:
- Цели заказчика проекта: сделать побольше (увеличить объем работ), побыстрее (сроки сократить), подешевле (меньше ресурсов потребуется).
- Цели исполнителя: заработать максимум денег, закрыть потребности заказчика в приемлемом качестве. А это: сделать поменьше (минимизировать объем работ), подольше (увеличить срок, чтобы все успеть без авралов), подороже (увеличить бюджет).
Как мы видим, цели заказчика и исполнителя прямо противоположны, поэтому в процессе заключения договора на проект автоматизации нужно искать компромисс и договариваться. Проектный треугольник при этом должен устраивать обе стороны.
Для того чтобы понизить расходы на проект, понадобится уменьшить объем работ, убрав некоторые задачи, или снизить качество реализации задач, что позволит сделать их быстрее (явная экономия на оплате исполнителей).
Если выделить дополнительное время на работы, то можно увеличить объем работ, добавив дополнительные задачи (например, на большее количество итераций тестирования и опытной эксплуатации), увеличить тем самым общее качество результата, но это потребует оплаты привлеченных ресурсов, а значит, и увеличения бюджета проекта.
Если мы хотим сделать запланированный объем работ без сокращений, но быстрее, то это потребует привлечения дополнительных ресурсов (распараллелить работы на большее количество исполнителей), а значит, и оплаты этих специалистов, что увеличит бюджет проекта.
Как ни крути, но изменить только одну сторону треугольника не получается.
В общем случае получается четыре подхода:
- Фиксируем объем работ: меняем сроки и бюджет проекта.
- Фиксируем бюджет проекта: меняем сроки и объем работ.
- Фиксируем сроки: меняем объем работ и бюджет проекта.
- Меняем все стороны треугольника.
В гибких agile-методиках, когда оценить объем работ заранее сложно, работы ведутся небольшими временными интервалами (фиксированный интервал), за понятную стоимость (оплата участников). В этом случае в регулярную сборку входит какой-то созданный за отведенное время функционал, который сразу передается пользователям (управляем объемом работ, который можно сделать за это время, и бюджетом).
В классических «водопадных» методиках объем работ заранее утвержден, а оцениваются и управляются сроки и стоимость реализации этого объема работ.
Графически это можно представить на схеме.
Рис. 3.5. Разница между гибким и «водопадным» подходами
Удержание проекта в границах проектного треугольника – одна из важнейших задач руководителя проекта. В ходе работ над проектом могут возникать (и обычно возникают) различные ситуации: вскрываются новые требования, без которых нельзя обойтись, затягиваются сроки, так как неточно были даны изначальные оценки, от этого раздувается бюджет, что никак не может радовать заказчика. Руководитель проекта должен своевременно выявлять такие ситуации и управлять ими: увеличивать бюджет и список требований дополнительными соглашениями к договору, следить за сроками и эффективной работой над задачами в проектной команде.
