на главную поиск по сайту карта сайта
+7 (495) 646-0612info@informicus.ru

Оформить заказ

Оказываем полный спектр услуг в сфере информационных технологий. Разработка, внедрение и сопровождение программного обеспечения. Анализ, оценка эффективности и консультирование в сфере использования информационных систем. А также собственные программные решения для оптимизации вашего бизнеса.
Разработка программ, разработка ПО на заказ, торговые роботы    
ГЛАВНАЯ О КОМПАНИИ РЕШЕНИЯ УСЛУГИ СТАТЬИ

СТАТЬИ

СТАТЬИ

К оглавлению.

Управление временем (Тайм-менеджмент)

Контроль сроков исполнения проектных задач.

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

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

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

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

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

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

Правила декомпозиции проектных работ.

Инструментом, позволяющим руководителю проекта получить оптимальное разбиение проекта на задачи и иметь четкую картину конечного и промежуточных результатов проекта, является WBS - Структура Декомпозиции Работ (Work Breakdown Structure). Данный подход позволяет с заданным уровнем точности описать содержание работ по проекту, провести декомпозицию проекта на пакеты, субпакеты и пр., т.е. представить список работ по проекту в виде иерархической структуры, где каждая элементарная работа имеет объективный или измеримый результат.

Основной процесс разработки WBS состоит из следующих шагов:

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

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

При этом необходимо принимать во внимание следующие правила:

  • В WBS должны быть определены все работы, закрепленные за участниками проекта.
  • Каждый пакет работ должен обеспечивать достижение ощутимого результата.
  • Результаты пакетов работ должны быть уникальными и отличаться от результатов других пакетов работ того же уровня.
  • Должны быть включены пакеты работ, описывающие начальные и завершающие элементы проекта, такие как планирование, монтаж и опытная эксплуатация.
  • Каждый пакет работ должен иметь ровно одного ответственного.
  • Каждый пакет работ, выполняемых внешними организациями, должен быть согласован с соответствующими элементами WBS подрядчика.
  • Все результаты в явном виде должны быть включены в WBS.
  • Для всех важных событий, связанных с отчетностью (например, ежемесячные отчеты, отчеты о проведении испытаний и т.д.) должны быть включены соответствующие пакеты работ.
  • Пакет нижнего уровня иерархии должны иметь размер, достаточный для эффективного управления, но не настолько малый, чтобы сделать затраты на контроль чрезмерными.

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

В общем случае, количество итерационных шагов WBS зависит от выбранного подхода к управлению проектом. Если целью выполняемого проекта является разработка программной системы, в качестве примера можно рассмотреть три наиболее распространенных подхода к управлению проектом: классическое водопадное, или каскадное программирование (Waterfall), RUP (Rational Unified Process) как пример классического итеративного подхода, а также экстремальное программирование как пример гибкого подхода к проектированию.

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

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

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

На практике часто используются не чистые методологии, а их комбинации. При этом учитывается опыт, приобретенный в ранее выполненных проектах (лучшие критические практики, или critical best practices).

Технологии управления личным временем

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

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

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

  • A. Важные и срочные. Делаются в первую очередь.
  • B. Важные и несрочные. Делаются во вторую очередь. Часто это наиболее ущемляемые дела, связанные с собственным развитием, обучением сотрудников, и т.п. При правильной расстановке приоритетов, это поможет в дальнейшем сэкономить массу времени, например, вооружившись новыми знаниями и решив поставленную задачу более эффективно.
  • C. Неважные и срочные. Делаются в третью очередь. Так как человеку свойственно путать срочность и важность, именно эти дела часто создают в фирмах атмосферу непрерывного аврала и суматохи.
  • D. Неважные и несрочные, или «мусорная корзина». Делаются по остаточному принципу. С них нельзя начинать рабочий день, убивая ими лучшие рабочие часы.

Еще один способ классифицировать дела по важности следует из закона Парето. Если применить этот закон к тайм-менеджменту, он будет звучать так: 20% всех дел дают 80% результатов; 80% дел дают 20% результатов. Это позволяет при рассмотрении списка дел выделить те 20%, которые дают максимальный результат и поэтому требуют особого внимания.

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

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

««НазадДалее»»

90
Проектное управление
Проектное управление
Подробнее
89
Аспекты проектного управления
Аспекты проектного управления
Подробнее
82
Что такое Rational Unified Process (RUP)
Что такое Rational Unified Process (RUP)
Подробнее
73
Цикл статей по моделированию программных систем
Цикл статей по моделированию программных систем
Подробнее
1234

телефон/факс: +7 (495) 646-0612/687-9964

105120, г. Москва, ул. Нижняя Сыромятническая,д. 5/7

info@informicus.ru

COPYRIGHT INFORMICUS, 2006 - 2020

Главная | О компании | Решения |
Услуги | Статьи | Карта сайта