Как найти уровень проекта - Исправление недочетов и поиск решений вместе с Examum.ru

Уровни и моменты оценки проекта

Время на прочтение
6 мин

Количество просмотров 6.4K

Это первая (1) статья цикла, посвященного разработке и использованию системы сбалансированных показателей (ССП/BSC) для мониторинга состояния проекта и оптимизации управления проектом с целью получения запланированных результатов.

Различные моменты оценки проекта

Далее, мы обсудим ключевые моменты, в которые осуществляется оценка проекта, уровни показателей, по которым происходит оценка, главные заинтересованные стороны в ходе этих оценок и использование различных оценок для управления проектом.

Под оценкой, мы понимаем, не только самую простую и распространенную форму оценку – финансовую и количественную, но и зачастую, не менее важную, не финансовую оценку, которая позволяет оценить здоровье проекта с различных сторон и заранее выявить риски и потенциальные проблемы.

В ходе жизненного цикла проекта и его используются следующие оценки:

Оценка ожиданий от проекта до старта проекта;
Оценка исполнения процессов в ходе проекта;
Оценка исполнения планов в ходе проекта;
Оценка исполнения планов в момент закрытия проекта;
Оценка исполнения ожиданий от проекта после завершения проекта;

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

Оценка ожиданий от проекта до старта проекта

На этом этапе производится оценка потенциальных выгод проекта и их ценности для бизнеса с точки зрения всех выгодоприобретателей проекта. Оценка ключевых выгод фиксируется в бизнес – кейсе проекта и плане управления выгодами.

Оцениваются и планируются показатели, которые позволяют объединить стратегические цели компании и бизнеса с результатами проекта – такие как чистый дисконтированный доход (NPV), внутренняя норма рентабельности (IRR), период окупаемости (PP). Кроме количественных показателей, могут применяться качественные, например, повышение безопасности производства.

Зафиксированные плановые показатели используются после завершения проекта для оценки его результатов. Так же, они могут использоваться в ходе проекта, для определения того, соответствует ли проект основным целям, ради которых он инициирован.

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

Ключевым участником и потребителем данного процесса являются спонсор и Заказчик проекта. Руководитель проекта может привлекаться к разработке показателей ожиданий или не привлекаться, так как, формально, в этот момент проект еще не запущен и руководитель проекта ни назначен.

Оценка исполнения процессов в ходе проекта

В ходе исполнения проекта важно чтобы работы не только выполнялись, но и самое главное, выполнялись правильно. Правильное исполнение работ и соблюдение стандартов существенно повышает вероятность достижения целей проекта.

Оценка корректности исполняемых процессов, в первую очередь, производится руководителем проекта и командой управления проектом. Могут привлекаться методологи из офиса управления проектами или сторонние аудиторы.

Оценка может производится в рамках следующих доменов:

Исполнение стандартов (например, PMI, ГОСТ);
Используемые процессы управления (например, управление рисками и управление знаниями);
Используемые проектные документы (например, журнал открытых вопросов и реестр рисков);
Наличие и частота ключевых событий (например, встречи по переоценке рисков);
Другие домены, зависящие от специфики и сложности проекта (например, количество требований и доля заинтересованных сторон, выставивших требования).

Показатели исполнения процессов в ходе реализации проекта позволяют:

Определить на сколько корректно осуществляется управление проектом;
Определить на сколько результативно выполняются работы по проекту;
Заранее выявить и устранить источники рисков;
Помочь правильно организовать работу и расставить акценты;

Показатели исполнения процессов являются опережающими с точки зрения управления проектом и результатов проекта, и позволяют правильно организовать работу по проекту, минимизировать возможные риски и помочь команде правильно организовать свою работу. Эти показатели напрямую говорят, какие процессы и каким образом необходимо исполнять и какие документы необходимо использовать.

Ключевыми заинтересованными сторонами оценки процессов выступают руководитель проекта и команда проекта.

Оценка исполнения планов в ходе проекта

В ходе выполнения проекта важно оперативно контролировать, на сколько текущее исполнение соответствует разработанным ранее планам. При этом достигнутая производительности сравнивается с планом, осуществляется анализ отклонений и вырабатываются корректирующие действия.

Одним из основных методов контроля производительности является метод освоенного объема (EVM) или различные его альтернативы. Наиболее простой вариант – сравнение плана с фактом, анализ отклонений, выявление возможных причин и разработка корректирующих мероприятий. Чем чаще и точнее осуществляется сравнение плана с фактом в ходе исполнения проекта, тем раньше могут быть выявлены возможные отклонения и события риска и минимизирован ущерб от них. В основном используются количественные и удельные показатели исполнения плана и отклонения от плана по содержанию, срокам, стоимости.

С точки зрения времени контроля и влияния на результат, показатели исполнения планов являются запаздывающими или итоговыми, так как они констатируют и показывают факт, который уже наступил. Даже, если, они выявляют негативную динамику показателя, значит событие уже произошло. Кроме того, они фиксируют последствия, но не выявляют причины и не дают рекомендаций, как нужно работать и что нужно изменить, чтобы скорректировать результат.

Ключевыми участниками и потребителями оценки исполнения планов являются руководитель проекта и спонсор проекта. На основании исполнения показателей плана, в основном, идет оценка качества проектного управления.

Оценка исполнения планов в момент закрытия проекта

Оценка исполнения планов в ходе закрытия проекта показывает на сколько проект выполнил цели, поставленные в уставе, бизнес – кейсе. Производится оценка выгод, зафиксированных в плане управления выгодами, которые можно оценить на данный момент.

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

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

Основными заинтересованными сторонами оценки при закрытии являются руководитель проекта, спонсор проекта и Заказчик. На основании итоговой оценки производится оценка качества проектного управления и последующие выводы относительно руководителя проекта.

Оценка исполнения ожиданий от проекта после завершения проекта

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

С точки зрения исполнения и управления проектом, выгоды от продукта полученные после завершения проекта, мало информативны, так как продукт может принести или не принести запланированные выгоды, вне зависимости от корректности реализации проекта. В проектах, связанных с разработкой новых перспективных продуктов, может возникнуть ситуация, когда проект завершился провалом, а продукт оказался на столько удачным, что перекрыл все понесенные издержки. Обратная ситуация, когда успешно завершенный проект породил не успешный продукт, так же возможна.

Основными заинтересованными сторонами оценки проекта после завершения являются спонсор проекта и Заказчики. Руководитель проекта, как правило, уже не привлекается.

Выводы

С точки зрения увязки проекта со стратегией компании и оценки продукта проекта ценность представляют сравнение оценки ожиданий от проекта до старта проекта и оценки ожиданий от проекта по завершении проекта. Эти оценки помогают понять на верхнем уровне что мы планировали и что в итоге получили.

С точки зрения оценки самого проекта, качества управления и руководителя проекта наибольшую ценность представляет оценка исполнения планов в момент закрытия проекта. Эта оценка дает ретроспективу и позволяет понять на сколько правильно мы управляли проектом.

С точки зрения управления проектом и организации процессов наибольшую ценность приносят оценки исполнения процессов и исполнения плана, непосредственно в ходе проекта. Эти оценки позволяют правильно организовать процессы, не допустить отклонений и заранее выявить риски. Проще говоря, они позволяют произвести оперативную диагностику здоровья проекта и показывают, что надо сделать, чтобы вернуть проект в норму, при возникновении отклонений.

Источник

Все компании, заинтересованные развитии, создании и сохранении конкурентных позиций, расширении бизнеса вне зависимости от специфики бизнеса и отношению к проектной деятельности (как проектно-ориентированные компании, которые используют проектный подход в процессе основной деятельности, так и процессно-ориентированные компании, которые используют проекты в качестве инструмента внутреннего развития) так или иначе реализуют проекты в ходе своей деятельности. Успех запускаемых проектов напрямую зависит от качества и уровня развития системы управления проектами в данной компании. В случае если компания находится уже на том уровне, когда приходит осознание необходимости развития данной системы, необходимости выявить сильные и слабые стороны, проанализировать прошлые ошибки и найти способы их исправления, первый вопрос, который встаёт, – это вопрос оценки уровня зрелости управления проектами. Для оценки существующей в компании системы управления проектами и её дальнейшего совершенствования используются различные модели. В соответствии со стандартом ISO [1] модель зрелости — это модель, которая отражает необходимые элементы эффективных процессов и описывает путь постепенного улучшения от незрелых процессов к регламентированным зрелым процессам с повышенными качеством и эффективностью. Под зрелостью организационного управления проектами в свою очередь понимается способность организации отбирать проекты и управлять ими таким образом, чтобы это максимально эффективно поддерживало достижение её стратегических целей [2].

В работе Малининой М. В. [3] предложена классификация моделей зрелости, основанная на различном структурировании критериев оценки и различном графическом отображении результатов оценки. В соответствии с данной классификацией автор делит все модели зрелости на три типа:

1. Уровневые, в которых достижение целей набора заданных областей характеризует определенный уровень, каждый из которых является основанием для последующих уровней. Уровневые модели определяют четыре-пять уровней зрелости и требуют, чтобы выделенные в рамках данной модели показатели зрелости были приведены к значениям, соответствующим каждому уровню. Примером уровневой модели является Модель зрелости управления проектами, разработанная немецким учёным Г. Керцнером;

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

3. Лепестковые, вкоторыхкаждая характеристика, определяющая зрелость компании в области организации управления проектами, оценивается по установленной шкале, что позволяет сразу увидеть отставание компании по каждой из заданных характеристик. Примером лепестковой модели является Модель зрелости организационного управления проектами Роланда Гарайса.

Ещё одним признаком, по которому можно классифицировать модели зрелости является способ оценки критериев. По этому признаку модели зрелости управления проектами можно разделить на качественные и количественные модели.

Качественные модели предполагают проверку наличия или отсутствия определенных характеристик процессов.Количественные модели дают количественную оценку степени соответствия требованиям методики.

В международной практике наибольшее распространение получили следующие модели зрелости управления проектами:

1. Модель зрелости организационного управления проектами — OrganizationalProjectManagementMaturityModel (OPM3), разработанная Американским Институтом управления проектами;

2. Модель зрелости управления проектами –ProjectManagementMaturity (РМ Maturity), разработанная Калифорнийским университетом Беркли;

3. Модель зрелости управления проектами –ProjectManagementMaturityModel (PMMM), разработанную немецким учёным Г. Керцнером;

4. Модель зрелости управления портфелями, программами и проектами — Portfolio, ProgrammeandProjectManagementMaturityModel (Р3М3), разработанная Министерством государственной торговли Соединенного Королевства;

Модель зрелости организационного управления проектами (OPM3) представлена в виде стандарта и состоит из свода знаний, базы лучших практик и инструментария.База лучших практик структурирована по трем доменам (проект, программа, портфель проектов), четырем уровням формализации проектов (процессы стандартизированы, измеряемы, управляемы и оптимизируемы), и в основном соответствуют одному из процессов управления проектами (инициация, планирование, организация исполнения, контроль, завершение) в соответствии с руководством РМВОК [4].

Данная модель включает 4 основных элемента:

— качество процессов

— среда организации

— культура организации

— воплощение стратегии

К каждому элементу применяется модель качества: стандартизация, измерение, контроль и усовершенствование. Таким образом, каждый процесс после применения модели качества воплощается в 4 лучшие практики. В свою очередь, чтобы достичь уровня лучших практик, организация должна иметь набор определённых «возможностей», а каждаявозможность в свою очередь может быть описана одним или более результатом и показателем состояния (KPI).Уровень зрелости организации оценивается по тому, обладает ли организация всеми необходимыми возможностями и в какой мере процессы, используемые в организации, приближаются к уровню лучших практик [5].Модель зрелости (OPM3) не содержит в явном виде уровней зрелости.

Модель зрелости управления проектами (РМ Maturity) Беркли построена в виде ряда ступеней, отражающих эволюцию процессов управления проектами в организации. Модель предполагает количественную оценку зрелости управления проектами и имеет пять уровней.

Таблица 1. [6]

Уровень	Название уровня	Характеристика уровня
1	Начальный	В организации нет формально принятых процедур управления проектами, выполнение проектов не планируется, работы проекта слабо определены по содержанию, объему и стоимости. Процессы управления проектами полностью непредсказуемы и слабо контролируемы. Высшее руководство часто не понимает ключевых вопросов управления проектами, поэтому успех проектов зависит в большей степени от индивидуальных усилий, чем от организации процессов управления проектами.
2	Индивидуальное планирование проектов	В организации применяются отдельные неформализованные процедуры управления проектами. Руководителями проектов процессы управления проектами частично признаются и контролируются. Однако в каждом конкретном проекте планирование и управление зависит от индивидуального подхода его руководителя.
3	Управление	Предполагает частичную формализацию процессов управления проектами и использование базовой системы планирования и управления проектами в организации. Компании, достигшие этого уровня, осуществляют систематический и структурированный подход к проектному планированию и контролю. Проектный персонал подготовлен для понимания и применения методологии и инструментальных средств управления проектами.
4	Интеграция	В организации существует полная формализация и официальное утверждение всех процессов управления проектами и документирование всей соответствующей информации
5	Совершенствование	Процессы управления проектами в компании постоянно улучшаются. Обеспечивается автоматический сбор данных по управлению проектами для выявления слабых мест в процессах, их анализ и количественная оценка для определения возможностей дальнейших улучшений процессов управления проектами. Этот уровень предполагает наличие и использование инструментов постоянного совершенствования процессов управления проектами. В качестве таких инструментов могут выступать, например, организационные структуры, процедуры и информационные технологии, обеспечивающие возможности аудита, мониторинга и экспертизы проектов.

Описываемая модель предлагает вопросник по различным областям знаний и фазам проекта с вариантами ответов. Далее вычисляется усредненное значение состояния процессов по всем областям знаний управления проектами.

Модель зрелости управления проектами Керцнера (PMMM) предполагает качественную оценку уровней зрелости управления проектами и состоит из 5 уровней: терминология, общие процессы, единая методология, бенчмаркинг и непрерывное улучшение.

Таблица 2. [7]

Уровень	Название уровня	Характеристика уровня
1	Терминология	На этом уровне организация осознает важность управления проектами и необходимость глубокого усвоения основных знаний в области управления проектами и изучения сопутствующей им терминологии;
2	Общие процессы	Организация осознает важность определения и разработки общих процессов для того, чтобы успех одного проекта мог быть повторен при выполнении других
3	Единая методология	Организация осознает важность синергетического эффекта, возникающего при интеграции управления проектами с другими методологиями (управление качеством, процессами и т. д.)
4	Бенчмаркинг	Происходит осознание того, что нужно улучшать корпоративные процессы, если корпорация хочет сохранять своё превосходство перед конкурентами
5	Непрерывное улучшение	На этом уровне компания оценивает информацию, полученную в ходе бенчмаркинга, и должна принять решение о том, будет ли эта информация использоваться при расширении (развитии) единой методологии.

Модель предполагает, что некоторые уровни должны и могут перекрываться, но порядок перехода с одного уровня на другой остаётся неизменным [7].

Модель зрелости управления портфелями, программами и проектами (Р3М3) описывает действия, связанные с портфелем, программами и проектами, в пределах областей процессов, которые вносят вклад в достижение успешных результатов проекта. Уровни представляют собой организационные переходы от незрелого состояния к зрелому организации, обладающей возможностями с объективной основой оценки качества и разрешения проблем программ и проектов.

Таблица 3. [8]

Уровень	Название уровня	Характеристика уровня
1	Знание о процессах	Управление проектами осуществляется без регламентирования и стандартизации процедур и при отсутствии системы контроля;
2	Повторяющиеся процессы	Управление проектами осуществляется при минимальном уровне стандартизации, ограниченном уровне последовательности и скоординированности между проектами
3	Определенные процессы	Организация имеет собственные централизованно контролируемые процессы управления проектами и может изменить отдельные проекты под эти процессы
4	Управляемые процессы	— Организация имеет специальные управленческие показатели для всех проектов, пригодные для прогнозирования будущего состояния;
5	Оптимизированные процессы	— Организация ведёт непрерывный процесс улучшения технологий управления проектами для оптимизации процессов.

Модели оценки зрелости управления проектами предназначены для обеспечения основы, которая необходима организациям для того, чтобы целенаправленно и постепенно развивать свою способность к успешной реализации проектов [9]. Данные модели представляют собой некий фундамент для развития формализованного управления проектами и создания конкурентных преимуществ. Тем не менее, в различных источниках можно встретить критику моделей оценки зрелости управления проектами. В работе Беверли Л. Пассиан [10] приводится свод критических оценок рассматриваемых моделей различных авторов. Среди основных моментов приводятся следующие:

— Уровни зрелости не содержат достаточной информации для измерения прогресса;

— Модели сосредоточены на рабочих процессах и часто игнорируют человеческий ресурс или организационные аспекты;

— Модели являются статическими инструментами, которые не учитывают быстрые темпы изменений, влияющих на деятельность компаний (особенно технологий или новых процессов, систем управления).

— Сложная структура моделей делает оценку трудновыполнимой, трудной к толкованию и применению.

— Модели оценки зрелости, как правило, направлены на выявление проблемы, а не на её решение.

Несмотря на присутствие общих характеристик, каждая из моделей оценки зрелости управления проектами имеет свои собственные особенности. Ниже автором приведён сравнительный анализ рассмотренных выше моделей.

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

В результате проводимого исследования были рассмотрены модели оценки зрелости управления проектами, получившие наибольше распространение в мире. В рамках настоящего исследования проведён сравнительный анализ наиболее распространённых моделей, выявлены преимущества и недостатки каждой из рассмотренных моделей оценки зрелости управления проектами.

Литература:

1. ISO/IEC. (2008). FCD 24765 — Systems and Software Engineering Vocabulary. Geneve: International Organization of Standartization

2. Полковников А., Терпугов А., Белозеров А.Что такое модели зрелости управления проектами? [Электронный ресурс]// Режим доступа: http://www.cfin.ru/itm/project/opmmm.shtml

3. Малинина М. В. Современные модели зрелости организационного управления проектами //Управление проектами и программами 03(27)2011–230с.

4. Organizational Project Management Maturity Model (OPM3) — Knowledge Foundation. NewtownSquare, Pennsylvania, USA:ProjectManagementInstitute, 2003

5. Разъяснения по проекту третьего издания Стандарта «Модель зрелости управления проектами организации» [Электронный ресурс]// Режим доступа: http://www.pmi.ru/news/1896/

6. Товб А. С., Ципес Г. Л.. Управление проектами: стандарты, методы, опыт. — М.: ЗАО «Олимп—Бизнес,. — 240 с., 2003

7. Керцнер Г. Стратегическое управление в компании. Модель зрелого управления проектами М.: ДМК Пресс, 2010

8. Portfolio, Programme& Project Management Maturity Model (P3M3) 2006

9. Pennypacker, J.S. & Grant, K.P. 2003, ‘Project management maturity: an industry benchmark’, Project Management Journal, vol. 34, no. 1, pp. 4–11.

10. Pasian B. L. Project management maturity: a critical analysis of existing and emergent сontributing factors // University of Technology, Sydney 2011

Источник

Уровни структуры проекта

Структурная
модель позволяет выбрать все работы с
необходимой степенью детализации:

Нижний
уровень
иерархической декомпозиции проекта —
содержит самый
подробный перечень
работ

В
структурной декомпозиции работ проекта
нет строгой регламентации по числу
уровней иерархии. Число уровней
колеблется в зависимости от сложности
и характеристики проекта.

Верхние
уровни
декомпозиции проекта ориентированы на
результат
или фазы жизненного цикла проекта, а
нижние
уровни отражают дальнейшую детализацию
с ориентацией на выполнение работ
конкретных исполнителей.

Уровни управления	Уровни иерархии	Наименование уровня
организационно-экономические	1	Проект
2	часть проекта
3	подпроект
4	часть подпроекта
технологический	5	Комплексные работы
6	укрупненные работы
7	единичные работы

Уровень
1 позволяет
определить место
данного проекта в окружении других
проектов

уровни
2- 4 характеризуют
объемно-функциональную декомпозицию
проекта (соответствуют уровню заказчика,
генподрядчика)

уровни
5-7 характеризуют
декомпозицию проекта, ориентированную
на работы
(содержит информацию, необходимую
исполнителю.

Структурная
декомпозиция образует информационного
языка проекта, на котором общаются все
участники проекта и ведется документация.

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

дерево
стоимости, дерево рисков и т. д.

Проект
как объект управления
описывается совокупностью определенных
показателей (характеристик проекта),значение
которых меняется н протяжении всего
жизненного цикла проекта.

К
основным характеристикам относятся:

Назначение
проекта (определяет, какие продукты и
услуги получит конечный потребитель
в ходе реализации проекта)
Стоимость
проекта ,которая представляет собой
смету затрат на проект
Объемы
работ в натуральном и стоимостном
выражении
Сроки
выполнения работ
Качество
проект а- соответствие проекта
установленным стандартам и требованиям
Ресурсы
проекта, требуемые для его осуществления
Исполнители
проекта — совокупность специалистов,
вовлеченных в проект ,их профессиональный
уровень и квалификация.

Сдр дополнительно

=
WBS
— Work Breakdown Structure

СДР
является основным «стержнем» для четырех
основных и одного вспомогательного
процессов:

определения
работ,
планирования
ресурсов,
оценки
стоимости,
бюджетирования,
определения
рисков

• что
нужно сделать (определить продукты
проекта);

• как
это нужно будет делать (определить
технологические этапы проекта);

• кто
это будет делать (определить исполнителей,
соисполнителей, субподрядчиков);

• кто
и в какой форме будет оплачивать работы
(определить, какие и с кем будут заключены
контракты).

Виды
WBS:

1)
Продуктовая,
когда проект разбивается по элементам
продукта проекта

2)
Функциональная:
декомпозиция по функциональным областям
менеджмента

3)
По этапам
жизненного цикла
проекта

+
смешанные

31.10.12

Лекция
№5

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

Источник

Оценка помогает команде определить вектор развития проекта и вовремя его скорректировать. Однако для многих менеджеров оценка — сложный и пугающий процесс, из-за чего она часто упрощается или игнорируется вовсе.

Вместе с Андреем Кокшаровым, продюсером направления «Высшее образование» в Нетологии, разобрались, зачем проводить оценку проекта, из каких этапов она состоит и какие инструменты помогут в этом.

Статья будет полезна участникам проектных команд и начинающим предпринимателям.

Проект — это временное предприятие, которое направлено на создание уникального продукта или услуги. Проекты могут иметь различные формы и реализовываться в любой сфере и отрасли. Например, проектами можно считать:

создание вакцины от коронавируса;
разработку приложения по мониторингу за больными;
проект слияния двух организаций;
разработку нового технического устройства;
строительство какого-либо объекта;
разработку IT-продукта для удовлетворения неочевидной или новой для рынка потребности.

Также к проектам относят стартапы — молодые компании без опыта операционной или проектной деятельности, работающие над идеей с высокой долей риска и неопределённости.

Любой проект начинается с идеи, а заканчивается, когда:

достигнуты цели проекта;
становится понятно, что достичь поставленных целей невозможно;
проект больше не актуален для заказчика или рынка.

Оценка проекта как раз помогает избежать рисков не уложиться в бюджет или сроки проекта, потерять в качестве продукта или разработать фичи, которые никому не нужны.

Расскажу, зачем командам проводить оценку проекта и какие методы при этом используют.

Оценка проекта — это способ выяснить, насколько вероятно выполнить задачу в нужные сроки, качественно и в пределах бюджета.

Оценка позволяет понять реальный статус проекта.

Она не призвана наказать отстающих, иначе участники будут приукрашать результаты или прятать неудобные данные и оценка станет необъективной и бесполезной.

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

Например, в некоторых компаниях используют анонимные ящики, которые устанавливают в общедоступных местах, чтобы любой участник команды мог положить туда записанные на листке бумаги сомнения и опасения. С определённой периодичностью менеджер проекта проверяет ящик и узнаёт о проблеме, о которой по какой-то причине подчинённые не говорят лично.

Оценку проекта можно разделить на оценку идеи проекта и оценку самого проекта. Данные блоки в свою очередь состоят из процессов, связанных с оценкой бюджета, сроков, качества и прочих компонентов в зависимости от уровня сложности проекта.

Оценка идеи проекта происходит на этапе, когда формируется бизнес-план и создаётся концепт продукта. Она позволяет руководителю обосновать решение о запуске проекта и его необходимости для бизнеса. В оценке идеи обычно участвуют аналитик, команда маркетинга, менеджер будущего проекта. По её результатам принимают решение об инициации проекта, подписывают устав проекта и набирают команду.

Оценка же самого проекта может происходить на всех этапах, начиная от планирования до этапа завершения. Её задача — скорректировать ход проекта. После проведения оценки проекта обычно вносят изменения в документацию, может измениться состав команды или перечень фичей продукта, либо вовсе решают закрыть проект. Если команда решила продолжать, то после этого оценивают потребности в дополнительных ресурсах.

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

бюджетирование — соответствует ли потенциальный доход от проекта затраченным ресурсам, нет ли несоответствий в запланированном бюджете и реальными запросами рынка;
качество получаемого продукта — нет ли изменений в качестве продукта из-за изменений, произошедших в ходе проекта (например, не стало возможности закупить дорогие материалы), соответствует ли продукт требованиям отраслевых сертификатов (ГОСТ, ISO и тому подобные);
потребность в материальных и нематериальных ресурсах — нет ли несоответствий с изначально запланированным качеством и количеством ресурсов с реальной ситуацией, нет ли необходимости перераспределить ресурсы или нужно поискать возможности для приобретения новых ресурсов;
соответствие запланированным срокам — нет ли проблем с их соблюдением, не нужны ли дополнительные временные ресурсы;
дополнительные процессы с учётом отраслевой специфики.

Состав оцениваемых процессов определяет менеджер на этапе инициации проекта. Чаще всего это называется процессом адаптации системы управления проектом к новому проекту — важно настроить его под среду и процессы внутри компании. Во время адаптации менеджер проекта тесно взаимодействует с командой проекта, с владельцем продукта и ключевыми стейкхолдерами. Адаптация помогает определить контролируемые точки в проекте, грамотно распределить ресурсы и разработать базовый план проекта.

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

Менеджер проекта разрабатывает план управления выгодами проекта. И в процессе адаптации ему необходимо синхронизировать между собой основные бизнес-документы проекта — понять, нет ли расхождения между ними и бизнес-кейсом, который изначально представлялся руководству.

К основным бизнес-документам относят:

Бизнес-кейс проекта — анализ целесообразности проекта, описания и оценки идеи, которые используются для определения и обоснования основных выгод проекта. За утверждение бизнес-кейса отвечает спонсор или руководитель продукта. Менеджер проекта выступает в роли администратора, который готовит документы и данные для бизнес-кейса.
План управления выгодами проекта — план по определению результатов проекта, реализация которых позволяет получить запланированные выгоды. За него уже полностью отвечает менеджер проекта.

Прежде чем сформулировать бизнес-кейс, нужно провести оценку потребностей рынка. В неё будет входить первичная оценка бизнес-идеи, оценка бизнес-задач, потенциальных проблем и возможностей проекта.

Ход оценки проекта в зависимости от этапов реализации проекта — от идеи до завершения

Существует большое количество методов оценки проектов. Правительства разных стран используют различные методы оценки, а частные компании разрабатывают свои собственные подходы к оценке, опираясь на мировой и личный опыт.

Поэтому методы оценки проектов в равной степени подойдут как для проекта, так и для стартапа, так как по своей сути он является технологическим проектом.

Проектная работа должна основываться на запланированных сроках, придерживаться ТЗ и устава проекта, иметь системы оценки и переоценки ресурсов, сроков и прочих компонентов. Иначе такая работа превращается в неопределённый временной забег без чётких целей с почасовой оплатой.

В проекте заказчик платит за результат, а не за рабочие встречи, время технических специалистов и отговорки менеджера проекта. Заказчик не оценит 13 000 часов работы по разработке продукта, если продукт будет сырой и недееспособный. Заказчик оценит лишь качественный продукт.

Поэтому отсутствие системы оценки проекта наравне с отсутствием фиксации договорённостей по проекту и игнорированием расстановки приоритетов в задачах — одна из основных причин возникновения проблем при реализации проекта.

Система оценки проекта — совокупность процессов и инструментов, которые направлены на своевременную оценку, анализ и подготовку документации о продолжении работы над проектом или о внесении в него изменений.

По содержанию система оценки проекта относится к группе процессов мониторинга и контроля проекта и должна включать процессы, направленные на оценку важных этапов и элементов проекта.

В малых и средних проектах ответственный за систему оценки проекта — менеджер проекта, в крупных — отдел контроллинга или специалист проектного офиса и менеджер программы, в рамках которой реализуется проект.

Остановимся подробнее на методах, инструментах и содержании оценки проекта.

Наиболее распространённый инструмент оценки проекта — экспертная оценка, которую используют не только в проектном подходе.

Экспертные оценки могут быть индивидуальные и коллективные.

Индивидуальная оценка — процесс привлечения эксперта с опытом реализации аналогичных проектов. Эксперт анализирует основные точки, указывает для них допущения и риски, после чего высказывает предположение по оценке.

Коллективная оценка — собрание, симпозиум или совет, на который приглашаются участники проекта, отвечающие за разные области и процессы. Каждый участник описывает предположение по продолжительности, сложности работ по своему участку или другому оцениваемому параметру. Руководитель проекта систематизирует выводы и выстраивает общий график или систему действий по проекту.

Более точные и менее распространённые — количественные оценки, например, метод PERT.

Метод PERT (англ. Program Evaluation Review Technique) используют для оценки времени выполнения задачи по проекту. Идея оценки заключается в использовании для расчёта оптимистичного и пессимистичного сроков выполнения задачи. Наиболее точный результат можно получить, если в качестве примера взять реальные сроки по схожим задачам в предыдущих проектах. При этом даже без знания чётких сроков можно воспользоваться экспертной оценкой опытных менеджеров проектов для вычисления результата.

Формулы расчёта по методу PERT выглядят следующим образом:

О = оптимистичная оценка: минимально возможная длительность выполнения задачи, если всё идет по плану. Риски учтены и не должны возникнуть.

Р = реалистичная оценка: среднее значение для подобных задач, с учётом возникновения рисков, которые не оказывают значительного воздействия на продолжительность проекта.

П = пессимистическая оценка: закладываем вероятность возникновения средних и серьёзных рисков, при возникновении которых существует вероятность значительного переноса сроков.

Метод PERT хорошо подходит для высокоуровневой оценки проектов и оценки общих трудозатрат, но при более детальной декомпозиции работ процесс анализа может быть неоправданно трудоёмким или ошибочным. Поэтому не рекомендуется использовать данный метод при расчёте непродолжительных задач.

Для определения объёма непродолжительных задач наилучшим образом подходят методы и инструменты оценки работ, принятые в различных Agile-подходах.

Освоите профессию проджект-менеджера в IT и digital
Пройдёте стажировку у партнёров программы уже в первый год обучения

Примете участие в нескольких реальных проектах, которые сможете добавить в портфолио

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

По опыту автора статьи, эффективную оценку проекта без серьёзных трудозатрат можно произвести при помощи последовательного использования двух инструментов, распространённых в гибких системах управления проектами. Это выстраивание порядка задач и покер планирования — рассмотрим их подробнее.

Выстраивание порядка задач (Ordering Rule)

Этот инструмент представляет собой пошаговый процесс, цель которого выстроить порядок из всех предстоящих задач.

Для процесса нужны цветные стикеры, стена или доска

Перед началом процесса ведущий утверждает соотношение цвета стикера с типом задачи. На стикеры выписывают все задачи и раскладывают случайным образом на столе.

Далее каждый участник процесса оценки совершает одно из двух действий: берёт карточку и размещает её на шкале или перемещает на соседнее поле уже прикреплённую карточку, комментируя и обсуждая с участниками своё решение. При необходимости на доску можно добавить отдельное окно, где будут размещены задачи, которые имеют неопределённый размер.

Данный процесс позволяет определить объём задач проекта.

Такой инструмент эффективен при работе с 10–20 задачами. Если требуется обсуждение большего количества задач, лучше разделить процесс на несколько сеансов или воспользоваться схожим инструментом.

Покер планирования (Planning Poker)

Покер планирования — одна из самых популярных техник оценки в проектном менеджменте. Для процесса используют специальную колоду карт, которая пронумерована в соответствии с последовательностью Фибоначчи, чтобы участник голосования с их помощью мог голосовать за задачу. Кроме карт с числами в колоде также присутствуют карта вопроса и карта с чашкой кофе.

Для процесса понадобится специальная пронумерованная колода карт

Игрок использует карту вопроса, если считает, что задачу надо уточнить или обсудить, а чашку кофе — при необходимости сделать перерыв.

Каждый участник получает набор карт с числовыми значениями и с изображениями чашки и вопроса, а ведущий анонсирует задачу или пользовательскую историю и отвечает на вопросы.

Затем участники выбирают карту с подходящей, по его мнению, оценкой и кладёт карту рубашкой вверх. Это необходимо для того, чтобы выбор участников, которые проголосовали первыми, не повлиял на решение других.

После того как каждый член команды определился с выбором, карты одновременно переворачивают. Участники с самыми высокими и самыми низкими оценками дают краткие комментарии, объясняя свой выбор оценки.

В итоге обсуждения команда приходит к единому решению и переходит к следующей задаче.

Покер планирования — одна из наиболее точных техник оценки, но среди основных минусов выделяют продолжительность процесса оценки. В течение часовой сессии сложно произвести оценку более чем десяти задач.

Вдохновившись идеей или продуктом, мы погружаемся в информационный пузырь и можем не заметить очевидные для рынка и скрытые для нас недостатки разрабатываемого нами продукта или услуги. Поэтому объективная оценка на всех этапах проекта — важный процесс, направленный на достижение успеха проектной деятельности.

Рассмотрим основные шаги оценки проекта.

Оценку потребностей проводят перед описанием бизнес-идеи — она необходима для принятия решения о запуске проекта. Именно на оценке потребностей рынка и целевой аудитории, анализе ситуации должно основываться решение о старте проработки бизнес-идеи и подготовке устава проекта или подобного документа, подписание и утверждение которого служат формальным подтверждением начала проекта.

В результате оценки потребностей формируется понимание и видение бизнес-цели и бизнес-задач, а также возможных проблем, важных допущений и рисков. Также оценка потребностей помогает сформировать первичное понимание того, каких показателей и в течение какого срока должен добиться проект, с учётом возможных рисков и описанных в рамках оценки допущений.

Оценка бизнес-идеи — творческий процесс, который зависит от отрасли и специфики проекта. Для каждой отрасли процесс оценки бизнес-идеи будет отличаться, но есть универсальные рекомендации:

описывайте идеи проекта в удобном формате — чтобы каждый участник проекта понял содержание проекта и мог интерпретировать данные;
внедряйте проработку идей, их анализ и обсуждение в общий процесс работы отдела или организации — чтобы избежать однобокости и ограниченности информации;
правильно презентуйте идею проекта — участники могут не понять идею, если она будет оформлена неправильно. К тому же, не нужно пренебрегать стилистикой компании.

План управления проектом — это живая сущность, требующая постоянного внимания. Практически невозможно распланировать проект на этапе инициации так, чтобы после старта не пришлось пересматривать сроки, стоимость, менять содержание или очерёдность задач. Поэтому оценка плана управления проектом, его актуализация и пересмотр — нормальная практика для любого проекта.

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

Если длительность проекта составляет от 9 месяцев до нескольких лет, лучше переоценивать план и актуализировать его не реже одного раза в месяц.

MVP — минимально жизнеспособный продукт. Это прототип продукта проекта, который можно представить инвестору или потенциальным пользователям в качестве демообразца для сбора обратной связи и последующей доработки продукта до полностью рабочего состояния.

Оценка MVP может строиться на следующих инструментах:

опрос клиентов;
запуск тестовых посадочных страниц;
тестовые рекламные кампании и фандрайзинг;
продажа MVP клиенту с условием сбора обратной связи и последующей заменой на полноценный продукт;
оформление предзаказа.

После сбора информации об MVP с помощью предложенных или других инструментов команда проекта должна проанализировать полученные данные и доработать продукт до финального состояния.

Нельзя считать выпуск MVP и сбор предзаказов по продукту успехом и завершающим этапом проекта. После выпуска MVP его доработка обязательно должна продолжиться — одним из основных приоритетов любого проекта должна быть нацеленность на разработку качественного продукта для его пользователей.

Представляет собой глубокий анализ собранных данных и результата деятельности проекта в целом.

Для финальной оценки необходимо:

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

Вне зависимости от сложности проекта, его продолжительности и предполагаемого результата проектной команде и менеджеру проекта важно придерживаться систем оценок проекта, работать над его развитием и прислушиваться ко мнению будущих пользователей результата проекта. Следование описанным в статье рекомендациям поможет снизить риски проекта и минимизировать ошибки в самом проекте, снизить количество ошибок и при его оценке.

Главная причина неудачи в оценке проекта — недосказанность или недопонимание между заказчиком и исполнителем. Необходимо вести прозрачный диалог с заказчиком, если в проекте появились изменения. В противном случае могут быть проблемы.

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

Поэтому ответ на вопрос «как не ошибиться», будет звучать парадоксально: практикуйтесь! Оценивайте, ошибайтесь, нарабатывайте опыт и экспертность. Со временем вы будете сталкиваться со всё меньшим количеством ошибок в оценке проекта, а вызванные вашими ошибками риски будут выглядеть менее критично.

Удачи в проектах!

Мнение автора и редакции может не совпадать. Хотите написать колонку для Нетологии? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.

Источник

Проект – это творческое объединение людей, которые занимаются своим любимым делом прямо здесь. Мы будем всячески их поддерживать, создавая дополнительные модули, предоставляя место для их деятельности и привлекать новых людей к ознакомлению с проделанной работой. Так, проектом может быть как команда, разрабатывающая модификацию для Warcraft 3 или Starcraft 2, так и музыкальная группа. Теперь вместо того, чтобы создавать какой-то малоизвестный сайт, достаточно зарегистрировать здесь проект и получить мощный функционал по работе с ним.

Форма создания проекта находится здесь.

Все проекты разделены по уровням (от 1 до 5). Уровень определяет возможности проекта, его максимальный размер. Чем выше уровень вашего проекта, тем большим функционалом он обладает, тем выше в списках он будет находиться. Проекты уровня 4 получают автоматическую подписку и могут стать публичными (см. далее). Уровень повышается менеджером проектов на основе результатов деятельности проекта: чем популярнее ваш проект, чем качественнее ресурсы в нем, тем больше шансов получить новый уровень. Если вы считаете, что проект заслуживает большего уровня, напишите менеджеру проектов, воспользовавшись специальной кнопкой на странице управления проектом.

Подробнее об уровнях можно прочитать в правилах ведения проекта.

Чтобы перейти на страницу управления проектом, нужно нажать на соотв. кнопку в правом меню проекта.

Первые два поля – заголовок и краткое описание. Заголовок проекта – это его полное имя.

Краткое описание используется в списке проектов, а также при поиске. Опишите в нескольких предложениях, о чем будет проект, какова его тематика и его основные цели. Сменить описание может менеджер (или руководитель проекта уровня 4 и выше).

Аббревиатура (или имя) используется в ссылках на проект и проектных ресурсах, что делает ссылки более узнаваемыми.
Если проекту дать Аббревиатуру «name», то ссылка на проект будет иметь вид «xgm.ru/p/name».
Сменить имя проекта может менеджер (или руководитель проекта уровня 4 и выше), однако это крайне нежелательно.

Логотип проекта – картинка, которая служит для идентификации и узнаваемости проекта. Анимированные картинки запрещены. Сменить логотип может менеджер (или руководитель проекта уровня 3 и выше).

В проекте можно создать главную страницу, используя соответствующий пункт правого меню. Если она задана, то при переходе на страницу проекта, будет открываться именно главная страница, в противном случае будет выдаваться список всех его ресурсов. Чтобы снять статус главной со страницы достаточно нажать на соответствующую кнопку при редактировании.

Проект может находиться в трёх состояниях: активен, закрыт и готов.
Проект закрывается, когда в нем долгое время не наблюдается активности. Руководитель может закрыть проект самостоятельно. В закрытом проекте вы теряете все права, но он останется в истории.
В состояние «готов» проект переводится менеджером, если проект достиг всех поставленных целей и опубликовал конечный продукт.
Некоторые проекты всегда находятся в активном состоянии.

Если вы желаете по каким-то причинам сделать проект невидимым для других пользователей, снимите галку «виден всем пользователям«. Участники проекта по-прежнему смогут работать в нем. Вы всегда сможете вернуть видимость установив эту галку снова.

Связываться с проектным менеджером по любому поводу и вопросу рекомендуется с помощью кнопки «Написать менеджеру«. Вероятность, что менеджер решит проблему правильно, получив запрос через данную функцию выше, чем написание ему личного сообщения или через внешние средства связи.

Функция «Дружественные проекты«, доступная проектам с уровня 4, добавляет участникам выбранного проекта права в своём проекте. Так, участники дружественного проекта станут неявными участниками и вашего проекта. Соответствие статусов будет задаваться на следующей странице, после нажатия «Добавить дружественный проект«.

Функция «Похожие проекты» позволяет перечислять проекты, которые каким-либо образом связаные с вашим. Это могут быть просто похожие проекты или проекты, которые также могут быть интересны вашим посетителям. Правильно составленный список облегчит навигацию вашим пользователям.
Например, проект-модификация для игры StarCraft 2 связана с общим проектом «StarCraft 2».
Максимальное число похожих проектов — 13.

Также присутствует функция настройки прав, о ней подробно написано в следующей главе.

Проект – это группа людей, которых можно поделить на четыре подгруппы:

Временные участники;
Участники;
Модераторы;
Руководители.

При создании проекта, пользователь автоматически становится его руководителем. Назначать новых руководителей могут менеджеры и руководители в проектах уровня 4 и выше, таким образом, в проекте может быть несколько руководителей.

Посмотреть список участников можно перейдя по соответствующей ссылке из главного меню. Оттуда же можно высылать приглашения на вступление в проект другим пользователям сайта. Приглашение, по желанию, можно снабдить комментарием. Высланную заявку может отклонить как пользователь, так и руководитель проекта. Если пользователь принимает приглашение, он становится участником проекта и получает все права этой группы (см. ниже).

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

Руководитель может исключить участника из проекта, при этом следует добавить комментарий, поясняющий причину исключения. После исключения пользователя, его можно вернуть в список активных участников (кнопка М в списке участников – дополнительные опции).

Участников можно временно лишать всех прав (банить) или переводить в состояние read-only. Если указать время лишения прав, то бан будет снят автоматически, кроме того, его можно снять и вручную (дополнительная опция).

Модераторы – помощники руководителей. Они имеют больше прав, чем участники, однако все права можно настраивать вручную (см. далее). По умолчанию модераторы могут приглашать новых участников, редактировать и опубликовывать ресурсы, удалять комментарии (в проектах уровня 3 и выше).

Временные участники – участники, история участия которых не сохраняется в истории (только в логах, см. далее). Их можно добавлять в проект без приглашения, но при этом они не будут считаться участниками проекта, однако они будут иметь в проекте права, определенные подгруппой «временные участники» (см. далее).

У каждого пользователя и у каждой подгруппы есть свои права. Личные права накладываются на права группы и получаются результирующие права пользователя в проекте. Личные права пользователя не могут превышать прав подгруппы «Руководители» данного проекта.

Право может иметь четыре значения:

По умолчанию (зелёный цвет — «да«, красный — «нет«, синий — «да+«);
Права нет (нет);
Право есть (да);
Право есть и с возможностью давать это право другим (да +).

С помощью этой системы можно как угодно настроить права в нужном нам проекте.

Чтобы настроить права пользователей в проекте, нужно перейти в раздел «Участники» по ссылке в верхнем меню проекта и нажать кнопку «Настройки прав» справа от участника.
Если вы хотите посмотреть и поменять права подгруппы, перейдите на страницу настроек проекта, кликнув по соответствующей кнопке в меню справа и выберите подгруппу в секции «Настройки прав подгрупп».

Публичные проекты — проекты, в которых права есть у всех пользователей сайта без исключения. Чтобы сделать проект публичным достаточно перейти в настройки группы «гости» (группа включает в себя всех зарегистрированных пользователей XGM) и установить все нужные права. Изначально гостям можно дать право два права: «посылать заявку на вступление в ваш проект» и даже «вступать в ваш проект» — ссылка на вступление будет отображаться у них в блоке «О проекте» справа.

После 4-го уровня открывается куда больше возможностей. Так можно установить для гостей права «добавлять ресурсы», «менять видимость» и «заявлять на публикацию», что даст возможность любому пользователю добавлять ресурсы в ваш проект, вы же сможете осуществлять премодерацию добавляемых ресурсов, опубликовывая или отклоняя их. Если вы хотите оставить жесткую премодерацию, то право «менять видимость» устанавливать не нужно, тогда все добавляемые гостями ресурсы будут полностью скрыты, пока вы не смените их видимость. Если же дать гостям права «редактировать любые ресурсы», «опубликовывать ресурсы» и «видеть логи», то можно создать свою маленькую википедию, в которой каждый сможет вносить свою лепту, редактируя ресурсы. При этом в журнале (см. далее) будут отображаться все правки. Если не давать право «опубликовывать ресурсы», руководитель и модераторы смогут осуществлять премодерацию после редактирования гостями. Таким же образом можно установить право «брать незанятые задания», тогда все пользователи будут видеть свободные задания (см. далее) и смогут выполнять их, получая награды.

Манипулируя правами разных групп, вы сможете настроить права в проекте практически любым удобным для вас способом.

Проектные модули — системы, созданные чтобы улучшить функциональность и сделать удобнее ваши проекты. Всего доступно 4 модуля:

Главная страница — модуль, который отображается по ссылке на проект вместо списка ресурсов. Используется для удобного управления проектом. Тут можно подробно описать работу проекта. Изначально включен.
Статьи — особая категория ресурсов, которая может иметь разделы и подстатьи. Используется для оформления и группирования разного рода текстов. Модуль изначально выключен.
Задания — Система позволяет выдавать задания участникам и контролировать их выполнение. Благодаря ей, очень удобно следить за порядков внутри команды проекта и кооперировать действия участников. Модуль изначально включен.
Форум — Позволяет создавать ресурс типа «обсуждение». Такие ресурсы не отображаются в основном списке, а разбиваются по разделам на форуме. Модуль изначально выключен.
Вопросы/Ответы — Система позволяет дать возможность посетителям задать вопрос в вашем проекте и выбрать лучший ответ из всех комментариев. Модуль изначально выключен.

Модули могут быть активированнымидеактивированными в любой момент. Но даже если модуль выключен, его настройки и содержимое остаются прежними

В во всех проектах доступна система заданий. Задания можно давать, как определенным участникам проекта, так и оставлять открытое задание без исполнителя – в этом случае, его сможет взять любой участник (или любой человек, имеющий право брать незанятые задания). Открытые и личные задания будут отображаться в шапке у участников, пока они их не выполнят (или не откажутся от задания.).

Задание может находиться в четырех состояниях:

Не рассмотрено;
Рассматривается;
Рассмотрено;
Провалено.

При создании задания можно назначать награду в виде рейтинга и опыта (если у вас есть право выдавать опыт). Награду исполнитель получит автоматически при выполнении задания. Если после этого изменить состояние задания или сменить исполнителя, награда с предыдущего исполнителя также снята автоматически. При смене состояния на рассматривается и рассмотрено пользователь становится исполнителем задания и получает награду.
Кроме того, заданию можно устанавливать срок исполнения, если оно не будет выполнено в течении указанного срока, то будет присвоин статус провалено.

Оглавление проекта – это своеобразный конструктор пользовательского меню проекта.
Чтобы создать элемент оглавления, который будет ссылаться на ресурс, метку или другой проект, выберите пункт «Оглавление проекта». После этого задайте тип объекта, на который будет ссылаться пункт оглавления. Это может быть проект, ресурс, тег или оглавление статей, если в проекте есть категория «Статьи». Если выбран тип «Оглавление статей», указывать ссылку в следующем поле необязательно.
Пунктам оглавления можно задавать названия, отличные от названий ресурсов – в поле «Заголовок».

Начиная с 3 уровня проекта, пункты оглавления можно добавлять в главное (верхнее) меню проекта. Для этого надо перейти на страницу оглавления проекта и нажать «добавить в меню» у соответствующего пункта. Чтобы убрать пункт из меню, соответственно, нужно нажать «убрать из меню» на той же странице.

С 4 уровня проекта открывается возможность создавать особые ресурсы – объявления – небольшое окошко, которое показывается над проектным меню. Для того, чтобы добавить объявление, надо выбрать пункт «Добавить ресурс» в правом меню проекта и нажать «Объявление» на открывшейся странице. Если же объявление достаточно большое по объему, достаточно в поле «Краткое описание ресурса» описать объявление одним-двумя краткими предложениями, тогда в окошке над проектным меню будет отображаться именно краткое описание и ссылка на полный текст объявления.

Категория ресурсов определяет набор дополнительных полей, способ отображения ресурсов, а также некоторые награды авторам за ресурс этой категории. Добавить поля категории можно после ее создания с помощью ссылки «добавить поле» напротив заголовка категории. Дополнительные поля — именованные области ввода, которые появляются при добавлении/редактировании ресурса, содержание которых будет отображаться на странице ресурса. Кроме того, поля могут быть двух типов: обычное текстовое поле и выпадающий список. Тип поля можно задать на странице его настроек. На этой же странице нужно задать все допустимые варинты для «выпадающего списка«. Следует создавать такие поля, которые есть у всех (или большинства) ресурсов этой категории. Например, для категории ресурсов «Музыкальные произведения» можно создать такие поля:

исполнитель – текстовое поле;
жанр – выпадающий список со всеми популярными жанрами (также следует добавить в список «другой жанр»);
альбом – текстовое поле;
год записи – выпадающий список.

Если при создании/редактировании категории установить флажок «добавлять название категории в метки ресурса«, к меткам ресурсов этой категории будет автоматически приписываться ее название. Это полезно для категорий с «говорящими» названиями, как «Статьи» или «Музыкальные произведения«, описанные выше, но не для категорий «Служебная страница«, «Моя категория«. Подобный флажок есть и у полей — если он установлен, то значение поля будет также приписываться к меткам при сохранении ресурса, тогда пользователи смогут осуществлять поиск по информации в этом поле. Это может быть полезно для полей «Жанр», «Исполнитель», «Альбом».

Описание категории отображается при выборе категории во время добавлении ресурса в проект, в нем нужно описать для авторов, какие ресурсы следует отнести отнести к этой категории.

Шаблон категории определяет некоторые специфические параметры отображения ресурса.
Шаблон «Простая страница» предназначен для ресурсов, которые будут отображаться без блока «О ресурсе» и без комментариев. Это может быть полезно для служебных страниц.
При создании/редактировании категории можно задать количество рейтинга и количество опыта (для проектов 5 уровня), которыми будет награжден автор ресурса этой категории.

Статьи — это модуль, при включении которого автоматически создается специальная категория.
Такая категория позволяет создавать у ресурса список вложенных (или дочерних) ресурсов, а также отображает статьи, разбивая их на группы по полю «Раздел». Если в проекте есть категория с шаблоном «Статья», то в списке доступных категорий появится категория «Подстатья». У ресурсов-подстатей есть поле «Базовая статья», в которой можно выбрать статью-родителя для создаваемой подстатьи.
Пример модуля статей:

Для удобного обсуждения внутри проектов рекомендуется использовать модуль «Форум», который активируется в «Проектных модулях». В панели управления проектом можно настроить видимость форума, возможности для определенных групп пользователей.
Чтобы активировать раздел, заходим в «Проектные модули»

Включаем модуль «Форум»

Далее займемся настройкой разделов, поэтому движемся в «Управление разделами»

Просто называем свои будущие разделы.

Далее пробуем создать свою первую тему. Нажимаем на главной странице форума на кнопку «Создать тему»

Тут все привычно, только появился пункт «Раздел», который классифицирует папки.
Также обратите внимание на 2 пункта, «Важная тема» и «Закрытая тема»:

Первый пункт значит, что тема будет всегда находится на вершине списка, между самыми важными темы верхней будет та, которую обновили последней.
Закрытая тема значит, что она доступна пользователям только для чтения. Оставлять комментарии в ней могут только руководители и модераторы проекта.
Если нет тем в определенных разделах — они не видны на форуме. Как только темы создаются — разделы появляются.
Также удобной функцией есть создание темы в уже определенном разделе. Нужно всего лишь нажать на кнопку «Создать тему» в самом разделе.

Руководителям проекта доступны его логи – журнал всех действий участников, связанных с проектом и проектных ресурсов, которые помечаются датами. Открыть их можно с помощью соответствующей кнопки в правом меню проекта или ресурса. С помощью логов, можно узнать какой участник что сделал в заданный момент времени. Ссылка детали ведет на страницу, отображающую все сделаные изменения в ресурсе или проекте. Так, используя логи, можно посмотреть историю правок ресурса, вернуть старую версию содержания, если это по каким-то причинам стало необходимо.

Чтобы проект стал известным, стоит:

попросить других лидеров добавлять твой проект в похожие
публиковать качественные ресурсы и повышать тем самым активность
повысить уровень проекта, доказав свой прогресс материалами
заинтересовать людей, чтобы они добавили его в закладки и подписались

Источник