Это попытка на картинках порассуждать, почему проекты так сложно выпускать в срок, и как задание приоритетов может улучшить ситуацию.
Итак, мы принимаемся за разработку проекта. Уже определены цели и общие очертания проекта, но пока совершенно ничего не известно про его реализацию. Какие задачи придется решать? Какие потребуются ресурсы? Неясно.
На этом этапе проект для нас — осязаемое, но все еще довольно бесформенное облако.
Что нам необходимо — это детали. Начиная от целей проекта, мы шаг за шагом разделяем его на относительно небольшие, и главное — очень конкретные задачи, решение которых и будет означать успешное завершение всего проекта.
В результате из изначально обтекаемых форм замысла проступают угловатые контуры его технической реализаций — в виде совокупности задач-«кирпичиков», вместе составляющих весь проект. «Весомо, грубо, зримо».
Итак, проект разделён на отдельные «кирпичики», каждый из которых по отдельности уже поддается осознанию и оценке. Наш следующий шаг — определение ресурсов, потребующихся для реализации всего проекта в целом. Этот шаг уже не так сложен — оценив ресурсоёмкость каждой из задач по отдельности, простым суммированием узнаем, во что обойдется нам весь проект.
Для наглядности представим ресурсы проекта в виде стола или полки, на которой одна за другой выставлены в ряд все задачи-«кирпичики», из которых складывается наш проект. Каждая задача занимает на полке место (то есть «расходует ресурс»), размеры полки соответствуют масштабности проекта и, конечно, ограничены — так же, как в жизни обычно ограничены время, деньги — или и то, и другое одновременно.
Перечисленные выше действия уже должны дать нам ответ на ряд важных вопросов:
- Какие ресурсы необходимы для завершения проекта?
- Какие задачи нужно решить?
- Какие ресурсы потребуются для выполнения каждой из задач?
Похоже, это не просто ответы на вопросы — это план. Приступаем к его реализации.
Время идет, одна за другой решаются задачи — и мысленно выставляются на нашу вымышленую «ресурсную полку». Теперь «ресурсная полка» наглядно показывает, какая часть проекта уже реализована, и сколько запланированных ресурсов уже фактически израсходовано. Конечно, когда все идет по плану, каждая из выполненных задач займет на полке ровно столько места (т.е. поглотит ресурсов), сколько предполагалось изначально, подчеркивая всеобщую мировую гармонию.
К сожалению, с мировой гармонией случаются затруднения. Рано или поздно какая-то из задач (а обычно — не одна) внезапно оказываются сложнее, дороже, дольше — или всё сразу. Она уже не умещается в заранее отведенное ей место — её, как бы это сказать, распирает.
Здесь наступает один из самых неприятных моментов разработки — кирпичи посыпались с полки. Задачи, израсходовавшие больше ресурсов, чем было для них запланировано, не только сами по себе стали «дороже» — они отняли место у тех задач, которые ещё только предстоит реализовать — тех задач, что аккуратно прорисованы на схеме пунктиром.
Возможно, удача ещё улыбнется, и мы все ж таки сумеем уместить все задачи обратно на полку — но для этого придется оставшиеся сделать с меньшими затратами, чем планировалось. Насколько вероятен такой исход?..
Не будем обманывать себя и примем как данность — в любом проекте рано или поздно кирпичи падают с полки. Почему не выпустить проект в срок, но без части запланированных функций? Просто потому, что очень часто в самом конце проекта вдруг оказываются очень важные вещи.
Как быть? Решение проблемы — в изначальной расстановке приоритетов.
В силу вероятностной сущности любого проекта нельзя быть абсолютно уверенным в том, что все пойдет строго по плану. Когда и в какую сторону с нами сыграет случайность — неизвестно, но можно с уверенностью говорить, что чем ближе задача запланирована к концу проекта — тем выше у нее шанс оказаться «за бортом» реализации. На нее может просто не хватить времени, или каких-либо иных ресурсов — и, увы, не всегда есть возможность увеличить бюджет проекта.
Пожалуй, сама по себе возможность потерять одну или даже несколько задач (путем «не влезания в бюджет») не является огромной проблемой; настоящей же проблемой это станет лишь в том случае, если «под сокращение» попадают какие-то очень существенные элементы проекта.
Исходя из этого понимания очевидное решение — еще на этапе планирования упорядочить задачи от самых важных к наименее существенным, и начинать реализацию с задач, критических для проекта. Таким образом риск «не успеть» никуда не исчезает, но под удар будут поставлены лишь наименее важные, второстепенные задачи.
Существенный момент: сложно и непродуктивно отталкиваться при задании приоритетов от «неважных» задач, считая все остальные «важными». Во-первых, трудно что-либо в проекте с самого начала отметить как несущественное и «не очень нужное» — тем более заниматься дальнейшим его планированием и реализацией. Во-вторых, выискивая в проекте «второстепенное», очень легко упустить критические и первостепенные задачи.
Гораздо эффективнее задать вопрос — «без чего проект не может быть выпущен?». С этим вопросом уже не так просто позабыть про такие важные, но легко упускаемые при планировании «кирпичи» проекта, как тестирование, сопроводительная документация, «setup.exe» и тому подобные задачи. Которые, конечно, стоит постараться реализовать как можно раньше, чтобы снизить риски падения кирпичей с полки.
Подведем итоги:
- изначальные оценки ресурсов, необходимых для реализации проекта, а так же их фактическое потребление в процессе разработки — величина вероятностная, имеющая в себе элемент случайности;
- в силу вероятностной сущности проектов существуют риски дефицита бюджета, которые часто приводят к отказу от реализации каких-либо частей проекта;
- задачи, запланированные на ранние этапы разработки, имеют лучшие шансы получить необходимые ресурсы;
- задание приоритетов на этапе планирования позволяет критичные задачи проекта запланировать на ранние этапы разработки, оставляя второстепенные на завершающие этапы — тем самым повышая шансы успешной реализации наиболее важных элементов проекта.