Допущения проекта

Ограничения проектов

Их существует три:

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

Тройное ограничение относится к фазе исполнения проекта, так как именно на этом этапе чаще всего возникает ситуация, что кто-то из сотрудников что-то не успел сделать. Обычное оправдание: «Хотел сделать хорошо, поэтому не справиться с остальными задачами».

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

Во ФРИИ мы стараемся следовать методологии Lean Startup. Это значит, что создается минимально работоспособный прототип продукта, на котором проверяется — будет ли работать идея в целом. А дальше, если работает, можно уже допиливать отдельные моменты.

Как правильно ставить задачи (цели) по проекту

Рекомендую пользоваться принципом SMART. Как это расшифровывается:

S (Specific — «конкретный»): цели проекта определяются четко и конкретно, чтобы все участники и вовлеченные в процесс люди понимали, что и зачем делают. Неконкретную формулировку допускают часто и она плохо влияет на дальнейшее планирование. Например, задача:»сделать хороший сайт» достаточно абстрактна: нужно четко сформулировать, что именно мы хотим получить на выходе.

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

R (Relevant — «последовательный»): все цели должны укладываться в общую концепцию, соотноситься со стратегией развития бизнеса. Например, если вы фокусируетесь на какой-то нише, то нужно развиваться именно в ней. Если не будет результатов, можно рассмотреть и другие ниши, но последовательно.

T (Timed/Timebounded — «измеримый во времени»): для целей нужно намечать временные рамки, не только конечные, но и промежуточные. Например, если сайт должен быть готов через месяц, нужно оценить сроки выполнения всех подзадач и четко сформулировать их сотрудникам и подрядчикам.

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

Треугольник проекта

Реализации проекта подразумевает обязательное планирование. Планирование это разработка модели проекта в специализированном программном продукте к примеру MS Project. В процессе планирования команда проекта вписывает проект в ограничения проекта. Ограничения проекта можно разделить на три группы:

• Ограничение по содержанию. Это описание требований к продукту проекта, чем сложнее проект тем больше задач необходимо реализовать для создания продукта проекта. Если мы планируем построить одноэтажный коттедж без дополнительных строений то модель, данного проекта будет довольно простой. С увеличением сложности проекта растет количество задачи, усложняется технология и растут сроки и затраты проекта.
• Ограничения по срокам. Мы уже знаем что любой проект имеет ограничения по срокам, и в модели проекта данные ограничения обязательно должны быть четко указаны. В программном продукте MS Project ограничения по срокам указываются с помощью поля «Крайний срок» в котором указываются даты до которых должны быть реализованы задачи и получены результаты проекта. В плане-графике проекта может быть указанно несколько крайних сроков, но для одной задачи или вехи (описание продукта проекта) может быть указан только один крайний срок.
• Ограничение по затратам. Под ограничением по ресурсам понимает не только финансы которые компания готова потратить для реализации проекта, но и стоимость использования ресурсов компании для реализации проекта.  

Желание заказчика или клиента получить максимальный результат (большой коттедж) в сжатые сроки (желательно за две недели) и за «смешные» деньги ( к примеру за 1000$). Можно ли реализовать такой проект? Большинство из Вас ответят НЕТ. Я бы сказал, МОЖНО, картонные коробки еще не перевелись. Как Вы уже наверно догадались это был пример того что в центре любого проекта лежит качество. И если заказчик или клиент пытается поставить нереальные сроки или бюджет при это заказывая уникальный продукт, он всегда жертвует получить продукт низкого качества. Хотя большой бюджет или длительные сроки не гарантируют качество продукта проекта, но одновременно сокращение предложенных исполнителем сроков и бюджетов может привести к продукту низкого качества. Это связано стем что строя модель проекта исполнитель (подрядчик) вписывает имеющуюся у него технологию реализации проекта. Изменение ограничений приводит к повышения вероятности наступления рисковых событий, а они всегда «бьют» по качеству. 

Для чего нужны ограничения на время выполнения задачи в MS Project

В случаях, когда Вам необходимо контролировать время начала и завершения задачи, Вы можете наложить ограничение на время выполнения задачи. Под ограничением в MS Project понимается условие, которое накладывается на срок начала или завершения задачи.
В MS Project существует три группы ограничений:
1. Гибкие ограничения. Гибкие ограничения учитывают зависимости между задачами и не привязывают задачу к конкретной дате. К гибким ограничениям относятся:

• как можно раньше. MS Project ставит на выполнение задачу с ограничением как можно раньше с учетом зависимостей между задачами и прочих факторов, влияющих на формирование графика выполнения проекта. Это ограничение используется в качестве ограничения по умолчанию для проектов, в которых расчет графика выполнения ведется от даты начала проекта.
• как можно позже. Задача с этим ограничением ставится на выполнение как можно позже с учетом зависимостей между задачами и прочих факторов, влияющих на формирование графика выполнения проекта. Это ограничение используется в качестве ограничения по умолчанию для проектов, в которых расчет графика выполнения ведется от даты завершения проекта.

2. Умеренно жесткие ограничения. Умеренно жесткие ограничения не дают начаться или закончиться задаче раньше или позже указываемой даты. Умеренно жесткие  ограничения учитывают зависимости между задачами. К умеренно жестким ограничениям относятся:

• окончание не позднее. При формировании графика выполнения проекта MS Project ставит на выполнение задачи с этим ограничением таким образом, чтобы они оканчивались не позже указанной даты. Это ограничение накладывается автоматически, если Вы укажете дату окончания задачи в проекте с формированием графика выполнения от даты завершения проекта.
• начало не позднее. Задача с этим ограничением должна быть начата не позднее указанной даты. Это ограничение накладывается автоматически, если Вы укажете дату начала задачи в проекте с формированием графика выполнения от даты завершения проекта.
• окончание не ранее. Задача с этим ограничением не может быть завершена ранее указанной даты. Это ограничение накладывается автоматически, если Вы укажете дату окончания задачи в проекте с формированием графика выполнения от даты начала проекта.
• начало не ранее. Задача с этим ограничением не может быть начата ранее указанной даты. Это ограничение накладывается автоматически, если Вы укажете дату начала задачи в проекте с формированием графика выполнения от даты начала проекта.

3. Жесткие ограничения. Ограничения этой группы не учитывают зависимостей между задачами и жестко привязывают задачу к конкретной дате. К жестким ограничениям относятся:

• фиксированное начало. Это ограничение жестко устанавливает дату начала задачи.
• фиксированное окончание. Это ограничение жестко устанавливает дату завершения задачи.

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

Зачем это нам нужно?

1. Повышение эффективности работы HR.
   Объективные, насколько это вообще возможно, критерии профессионализма разработчиков могли бы, к примеру, помочь HR-менеджеру, подобрать для конкретного проекта исполнителей, которые наилучшим образом соответствуют предъявляемым к данному проекту требованиям. Сами разработчики, имея возможность объективного сравнения своих способностей со способностями своих коллег, могли бы яснее осознавать те качества, над которыми им следует работать, чтобы увеличить спрос на свой труд, и повысить свой рейт.
2. Довольный заказчик.
   Кроме того, внедрение использования объективных критериев профессионализма выгодно и заказчику, поскольку с его точки зрения это повышает качество управления материальными и трудовыми ресурсами, повышая тем самым общее качество управления бизнесом.
3. Небольшие затраты, относительно ожидаемого эффекта.
   Цена, которую придётся заплатить, не слишком обременительна: повышение требования к дисциплине и аккуратный сбор и обработка данных.

SonarQube

Более детальный разбор этапов

Планирование

По американской методологии PMBOK планирование занимает порядка 50% всего времени, что особенно подчеркивает его значимость.

Планирование лучше начать с разделения проекта на части (Work Breakdown Structure — WBS), где каждая фаза разделена на более мелкие задачи. Это помогает понять объем работ и учесть все нюансы.

Рис. 2 — Структура разделения проекта на подзадачи (WBS)

Графики работ

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

Самый простой вариант диаграммы можно сделать в Exсel: слева в таблице находится название работ, а все остальные столбцы — даты.

Рис. 3 — Диаграмма Ганта, Microsoft Exсel

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

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

Рассмотрим пример диаграммы Ганта, построенной в MSProject.

Рис. 4 — Диаграмма Ганта, Microsoft Project

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

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

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

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

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

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

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

Убедитесь, что концепция решает задачу

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

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

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

Рис. 5-1. Концепция продукта охватывает границы каждого запланированного выпуска и тем менее четко определена, чем более дальняя перспектива рассматривается

Перекрывающиеся границы

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

Влияние заинтересованных сторон

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

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

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

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

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

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

Критерии приемки результата проекта

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

Настоящее искусство – это сформулировать критерии так, чтобы они были действительно удобны в использовании и не вызывали разночтения.

Например, для элемента “Обученные пользователи” (подкатегория “Обученные бухгалтера по работе с дебиторами”) критерием приемки может быть “Бухгалтер может выполнить следующие операции: ввод акта сверки, согласование счета и т.д. самостоятельно не более чем за 1 минуту”.

Зачем нужна WBS

WBS – крайне полезная вещь в планировании проекта и вот почему:

WBS – если не единственный, но точно самый эффективный способ наглядно отразить весь объем проекта.
WBS фокусирует внимание не на процессе а на ожидаемом результате, и создает нужный «посыл».
В идеале в разработке WBS участвует заказчик или его представитель и вся команда, что позволяет а) обеспечить единое понимание результатов проекта и его объема б) увидеть важность и вклад отдельных элементов в общий результат
С помощью WBS можно наглядно обосновать необходимости в финансах или человеческих ресурсах, так как против конкретного описанного объема возражать гораздо сложнее, чем против «да что там системку написать, посадите программиста и все».
WBS помогает предотвратить риски и изменения или по крайней мере значительно (очень значительно!) снизить их вероятность и влияние, так как именно здесь всплывут многие неочевидные ранее вещи и «а мы хотели совсем другое» (и так и должно быть, для этого инструмент и предназначен).
На уровне WBS уже можно определить и согласовать контрольные точки проекта (как для решений о продолжении проекта после очередного этапа, так и для контроля затрат человеческих и финансовых ресурсов).

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

Ограничения проектов

Их существует три:

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

Тройное ограничение относится к фазе исполнения проекта, так как именно на этом этапе чаще всего возникает ситуация, что кто-то из сотрудников что-то не успел сделать. Обычное оправдание: «Хотел сделать хорошо, поэтому не справиться с остальными задачами».

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

Во ФРИИ мы стараемся следовать методологии Lean Startup. Это значит, что создается минимально работоспособный прототип продукта, на котором проверяется — будет ли работать идея в целом. А дальше, если работает, можно уже допиливать отдельные моменты.