[an error occurred while processing the directive]
[an error occurred while processing the directive]

1.1.1 Определи работу / Малые проекты

Обзор малых проектов

(1.1.1.P1)

Понятие "малых" проектов охватывает много видов работ. В большинстве компаний, малые проекты и вовсе не рассматриваются как "проекты". К примеру, Ваша компания может называть это улучшениями или разовыми запросами. Тем не менее, в рамках Процесса Управления Проектами TenStep подобная работа считается проектом, потому что она соответствует всем отличительным признакам проекта. Работа уникальна, имеет даты начала и завершения, приводит к созданию выходной продукции, и т.д. Просто объем работы невелик, и поэтому проект сам по себе мал.

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

Бывает достаточно трудно решить, как лучше управлять таким маленьким объемом работы: как работами по поддержке или как малым проектом. Критерий, принятый в Процессе TenStep, заключается в рассмотрении требований к срокам завершения работы. Если возникает проблема, требующая незамедлительного устранения, то соответствующая работа определенно рассматривается как поддержка. Если проблема не столь "горящая", а позволяет назначить ей приоритет и заняться ее решением в будущем, то соответствующая работа может рассматриваться как малый проект.

В общем смысле, малые проекты могут включают следующее.

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

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

Процесс Запроса на обслуживание

(1.1.1.P2)

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

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

  1. Клиент направляет запрос. Клиент с помощью руководителя проекта, если таковая потребуется, заполняет простую форму Запроса на обслуживание, в которой документируется запрашиваемая работа. Даже тогда, когда объем работы совсем небольшой, Запрос на обслуживание служит формальным документом, описывающим, что должно быть сделано, и содержащим соответствующее подтверждение клиента. Как правило, Запрос на обслуживание также содержит оценку приоритетности работы и ее значения для бизнеса.
  2. Руководитель проекта рассматривает и уточняет. Руководитель проекта проверяет Запрос на обслуживание, чтобы убедиться в понятности работы. При необходимости, руководитель проекта задает вопросы клиенту, чтобы уточнить смысл запроса. Руководитель проекта также должен понять критичность запроса, и нужно ли вначале выполнить какие либо предварительные работы.
  3. Высокоуровневая оценка трудоемкости, стоимости и продолжительности подготовлена.
    • Если руководитель проекта достаточно хорошо понимает смысл работы, и обладает нужным уровнем квалификации, то он (она) готовит высокоуровневую оценку трудозатрат, стоимости и продолжительности работ и включает эту информацию в Запрос на обслуживание. Возможно, когда клиент увидит результаты оценки, то он изменит свое мнение по поводу приоритетности соответствующего запроса. В частности, если трудозатрат потребуется больше, чем представлялось клиенту, приоритетность может быть уменьшена. А если оценка окажется меньше, приоритетность может быть увеличена для того, чтобы работа была выполнена быстрее.
    • Если руководитель проекта не имеет возможности оценить работу, оценка поручается одному из членов команды. Если ни у кого из команды нет ни времени, ни опыта в проведении такой оценки, то процесс оценки может быть сам помещен в очередь. Клиент должен решить, настолько ли высок приоритет сбора информации для проведения оценки, чтобы назначить на эту работу участника команды, который мог бы вместо этого выполнять другие Запросы на обслуживание. Данная высокоуровневая оценка используется только в целях расстановки приоритетов. Когда работа фактически назначена, то при необходимости, может быть выполнена более детальная оценка.
  4. Запрос назначен или отложен. Руководитель проекта и клиент оценивают запрос по отношению к другой работе, которая уже распределена или находится в очереди. Они также проверяют реальные возможности и способность команды приступить к запрашиваемой работе. Если необходимые ресурсы недоступны или данная работа имеет более низкий приоритет, чем другие, то такой запрос помещается в очередь. Таким образом, очередь содержит все оцененные и ранжированные по приоритетности запросы, которые на данный момент еще не назначены к выполнению.
  5. Периодическое рассмотрение отложенной работы. Руководитель проекта и клиент регулярно (еженедельно, раз в две недели или ежемесячно) пересматривают отложенные Запросы на обслуживание. При этом, они должны обновить приоритеты работ, учитывая новые Запросы на обслуживание, завершенные работы и текущую ситуацию. Если приоритет Запроса на обслуживание достаточно высок и необходимые ресурсы доступны, работа назначается к исполнению. Если в очереди выявляется Запрос на обслуживание, более критичный, чем текущая работа, то эта работа может перевестись в режим ожидания, вернуться в очередь или выполняться в "фоновом" режиме, пока не выполнится более критичный запрос.
  6. Уточнение исходных данных. Перед началом выполнения работы, назначенные на нее сотрудники должны уточнить информацию в Запросе на обслуживание и актуальность сделанных ранее оценок работы. Если это потребуется, новую информацию нужно задокументировать и немедленно обсудить с участием клиента, чтобы выяснить, как она повлияет на приоритетность запроса. Например, клиент может запросить проект на 40 часов. Если детальный расчет даст оценку трудозатрат около 80 часов, то данная работа может быть поставлена в очередь, а в работу пойдет другой запрос, который равноценен по критичности, но требует меньше времени на выполнение.
  7. Выполнение работы. Если работа после уточнения данных запроса все еще приоритетна, начинается ее реальное выполнение. Малые проекты обычно следуют типичному короткому жизненному циклу. (См. процесс LifecycleStep на www.LifecycleStep.com для более подробной информации о выполнении жизненного цикла проекта.)
  8. Управление работой. Как только работа начнется, она должна управляться согласно процессам управления работой (Управляй объемом, коммуникациями, рисками и т.д.). Поскольку работа небольшая, все эти процессы используются по необходимости. Процедуры управления проектом для каждого отдельного малого проекта не создаются. Вместо этого, как правило, устанавливаются общие процедуры, чтобы управлять всеми работами, выполняемыми по Запросам на обслуживание. Обычно, сюда входят процедуры по отслеживанию прогресса выполнения Запросов на обслуживание, по управлению объемом, коммуникациями и т.д.
  9. Закрытие работы. Когда работа завершена, клиент должен завизировать ее приемку. В этом случае Запрос на обслуживание закрывается и помещается в архив завершенных работ в целях учета и сохранения истории работ. Новая или измененная выходная продукция может быть запущена в производство либо сразу же, либо по графику, либо в составе комплексного продукта. В некоторых организациях, Запрос на обслуживание не закрывается до тех пор, пока клиент не дает подтверждение, что выходная продукция корректно работает в производстве.

[Пред. страница - Определи работу / Процесс]   [След. страница - Определи работу / Средние проекты]