Что такое список контрольных событий: НОУ ИНТУИТ | Лекция | Управление сроками проекта

Содержание

Контрольные события — Oktell

Техническая документация / Call-центр / Контрольные события


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

Контрольное событие — заранее определенная ситуация в работе call-центра (или других блоков), по наступлении которой система производит установленные в ходе настройки действия (уведомляет пользователей и/или выполняет служебные действия, определяемые служебным сценарием).

Типы контрольных событий

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


В системе существует ряд предопределенных типов КС, оперирующих исключительно системными событиями и не обращающихся к долговременной истории в БД. Отдельным типом являются КС на основе пользовательских SQL-запросов к БД.

  • Превышение времени обработки звонка в задаче

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

  • Пропуск оператором входящего вызова

Пропущенным вызовом считается ситуация, при которой происводится звонок оператору (в задаче или из АТС) и истечение установленного времени вызова, после которого дозвон прекращается системой (для вызовов задач настраивается в модуле «Администрирование. Общие настройки. Менеджер задач», по умолчанию 20 секунд, для вызовов внутри АТС определяется настройкой внутреннего номера, посредством которого происходит вызов, не более 90 секунд). Параметры: набор задач, набор операторов, номер звонившего. Если указан ограниченный список задач, система фокусирует внимание только на установленных задачах. В случае, если задачи не выбраны, происходит слежение за операторами равно во всех задачах, а также в АТС.

  • Превышение допустимого времени предвызывной обработки

Параметры: набор задач, набор операторов, контрольное время.

  • Превышение допустимого времени обратного вызова

Параметры: набор задач, набор операторов, контрольное время.

  • Превышение допустимого времени поствызывной обработки

Параметры: набор задач, набор операторов, контрольное время.

  • Превышение допустимого времени в статусе перерыва

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

  • Выход оператора из call-центра или из системы в рабочее время

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

  • Звонок от/к оператору вне задачи

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

  • Оператор первым положил трубку

Параметры: набор задач, набор операторов.

  • Оператор выбрал пропуск вызова по запросу исходящей задачи

Параметры: набор задач, набор операторов.

  • Число активных операторов задачи менее установленного

Параметры: набор задач, минимальное количество операторов (число).

  • Число активных операторов задачи менее определенного расписанием (в процентах)

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

  • Число абонентов в очереди задачи более установленного

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

  • Максимальное время ожидания абонента в очереди задачи более установленного

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

  • SQL-базированное КС

В установленные моменты времени осуществляется пользовательский запрос в БД, возвращающий некий набор данных, состоящий из совокупностей: {код задачи, код оператора, определенное в запросе значение, описание}. Система фильтрует полученный набор данных в соотвествии с параметрами, после чего производит сравнение значения каждой совокупности (строки из набора данных) с установленным контрольным значением на основе выбранного типа сравнения. В случае неудачи генерирует контрольное событие для каждой совокупности. SQL-КС концептуально возможны двух вариантов:

  1. запрос возвращает весь набор совокупностей со значениями, которые оцениваются менеджером контрольных событий с использованием выбранной операции сравнения, после чего подошедшие по условию генерируют соответствующее контрольное событие. В этом случае описание может быть пустым, так как КС жестко связано с запросом и все генерируемые на базе этой настройки события технологически имеют один тип.
  2. в теле запроса на уровне БД производятся различные действия, сравнения и анализ, после чего возвращается некоторый набор подошедших совокупностей, которые все полностью передаются на генерацию событий. В этом случае одна настройка КС может сгенерировать принципиально разные контрольные события (согласно тексту SQL). В этом случае используется возвращаемое запросом описание для конкретной совокупности. Cравнение также производится, однако его можно исключить, например, принудительно выставив сравнение на равенство с константным значением, которое также явно выходит как результат запроса в поле значений.

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


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

Действия при возникновении контрольных событий

При наступлении КС система производит установленные администратором или супервизором действия.

Среди возможных действий:

  • рассылка уведомлений супервизорам «виновной» задачи;
  • рассылка уведомлений выбранным при настройке пользователям системы;
  • запуск произвольного служебного сценария с передачей в него параметров возникшего КС. Параметры в сценарии доступны через встроенные функции с маркировкой «КС». Код запуска служебного сценария — 10.

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

Модуль настройки и просмотра контрольных событий

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

На вкладке «Настройка» происходит работа по созданию, редактированию, удалению, а также активации и деактивации контрольных событий.

Контроль проектов. Управление проектами по контрольным точкам. Адванта-Москва

Почему планирование по-старому не работает?

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

Какова суть метода контрольных точек?

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

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

Метод контрольных точек позволяет:

  • планировать в категории «результатов»
  • не испытывать иллюзий «поднажмем-успеем»
  • разделить контроль на несколько уровней и минимизировать лишнее вмешательство в руководство работами.

Что такое контрольная точка?

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

КТ фиксирует:

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

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

  • прошедшее время
  • совершенный вид
  • страдательный залог (отвечать на вопрос «Что сделано?»).

Например, не «Тестирование продукта», а «Тестирование продукта завершено». Ведь тогда стремиться нужно будет не к процессу «Тестирование продукта», а к завершению тестирования.

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

Примеры контрольных точек: 

Какими бывают контрольные точки?

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

Уровень 0. Вехи

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

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

Уровень 1. Критические

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

Как и для вех, контроль получения этих результатов выполняется на высоком уровне. Отклонение сроков достижения таких результатов рассматривается Первым лицом или специальным органом – Проектным комитетом. А при достижении результатов Руководитель проекта обязан привлечь Заказчика к приемке или представить ему полученные результаты.

Уровень 2. Ключевые

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

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

Уровень 3. Оперативные

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

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

Общее представление планирования контрольных точек представлено на рисунке 1. 

Рис. 1. Планирование по контрольным точкам            

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

На каждом уровне контрольные точки должны быть формально утверждены. Утверждение предполагает:

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

На верхнем уровне утверждение будет выполнено через Устав или приказ, который утверждает первое лицо или председатель Проектного комитета. На нижнем – это может быть документ в MS Excel или MS Word, который согласовали участники команды, или даже цветные кнопки на доске, которую видит конкретный отдел.  

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

Кто должен сформулировать КТ высокого уровня?

Контрольные точки 0 и 1 уровня ответственен сформулировать Заказчик проекта. Если у Заказчика нет требований к сроку (продолжительность работ), кроме финального срока передачи результата, значит, Руководитель проекта ответственен за определение контрольной точки своего уровня и контроль проекта будет осуществляться только на основе Базового плана.

Сколько уровней КТ должно быть?

Количество уровней КТ зависит и от зрелости компании, и от масштаба проекта. На первых шагах применения метода в компании мы рекомендуем использовать не более 2 уровней КТ: КТ в Уставе (вехи и критические результаты) и Базовом плане. Если компания зрелая и выстроила культуру управления по контрольным точкам, то последний уровень КТ устанавливается для рабочей группы не более 5 человек и срок получения промежуточных результатов не должен превышать 2 недели.

Какие шаги должны быть сделаны Руководством для применения метода?

ШАГ 1. Определить конкретные поставко-ориентированные результаты (далее – Продукты проекта), которые должны быть сформированы или произведены проектом и требуемые сроки их поставки. При этом срок поставки действительно должен быть важен и обоснован.

ШАГ 2. Согласовать срок с исполнителями, определить их ответственность за подготовку результатов именно к этому сроку. Не должно быть двоякого понимания срока или ответственности: конкретная дата, один ответственный, один измеримый результат.

ШАГ 3. Определить того, кто может подтвердить, что результат получен, измерен, его качество соответствует заявленному и его можно применить для достижения ваших целей или для целей проекта (Приемщиков).

ШАГ 4. Определить того, кто независимо может контролировать выполнение контрольных точек и правила контроля.

Кейс крупного банка

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

Для контроля исполнения проекта были разработаны следующие контрольные результаты:

Через месяц Руководству были представлены итоги конкурса по выбору поставщиков и заключен контракт на работы. Поскольку согласования условия контракта были затянуты – контрольная точка по согласованию дизайна не была выполнена в срок – что отразилось на премировании участников проекта. Зато следующий результат – «Запущены в пилотном режиме 5 страниц нового сайта» был представлен ранее срока и получил высокую оценку.

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

Контрольный список для ревью кода в распределенных системах

points of view by sanja

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

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

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

Удаленная система выходит из строя


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

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

  1. Определите путь обработки ошибок. В коде должны быть явно определены средства для обработки ошибок. Например, правильно разработанная страница ошибок, журнал исключений с метриками ошибок или автоматическое выключение с механизмом резервирования. Главное — ошибки должны обрабатываться явно. Нельзя допускать, чтобы пользователи видели ошибки работы вашего кода.
  2. Составьте план восстановления. Рассмотрите каждое удаленное взаимодействие в вашем коде и выясните, что нужно сделать для восстановления прерванной работы. Запускается ли рабочий процесс с точки сбоя? Публикуются ли все полезные данные во время сбоя в таблице очередей или таблице повторов? И повторяются ли каждый раз, когда удаленная система восстанавливается? Есть ли скрипт для сравнения баз данных двух систем и их синхронизации? Системный план восстановления нужно разработать и реализовать до развертывания фактического кода.

Удаленная система медленно отвечает


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

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

  1. Установите тайм-ауты для удаленных системных вызовов. Это касается и тайм-аутов для удаленного вызова API и базы данных, публикации событий. Проверьте, установлены ли конечные и разумные тайм-ауты для всех удаленных систем в вызовах. Это позволит не тратить ресурсы на ожидание, если удаленная система перестала отвечать на запросы.
  2. Используйте повторные попытки после тайм-аута. Сеть и системы ненадежны, повторные попытки — обязательное условие устойчивости системы. Как правило, повторные попытки устраняют множество пробелов в межсистемном взаимодействии.

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

  3. Применяйте автоматический размыкатель (Circuit Breaker). Существует не так много реализаций, которые поставляются с этим функционалом, например Hystrix. В некоторых компаниях пишут собственных внутренних обработчиков. Если есть возможность, обязательно используйте Circuit Breaker или инвестируйте в его создание. Четкая структура для определения запасных вариантов в случае ошибки — хороший вариант.
  4. Не обрабатывайте тайм-ауты как сбои. Тайм-ауты — не сбои, а неопределенные сценарии. Их следует обрабатывать способом, который поддерживает разрешение неопределенности. Стоит создавать явные механизмы разрешения, которые позволят системам синхронизироваться в случае тайм-аута. Механизмы могут варьироваться от простых сценариев согласования до рабочих процессов с отслеживанием состояния, очередей недоставленных писем и многого другого.
  5. Не вызывайте удаленные системы внутри транзакций. Когда удаленная система замедляется, вы дольше удерживаете соединение с базой данных. Это может быстро привести к исчерпанию соединений с базой данных и, как следствие, к сбою в работе вашей собственной системы.
  6. Используйте интеллектуальное пакетирование. Если работаете с большим количеством данных, выполняйте пакетные удаленные вызовы (вызовы API, чтение БД), а не последовательные — это устранит нагрузку на сеть. Но помните: чем больше размер пакета, тем выше общая задержка и больше единица работы, которая может дать сбой. Так что оптимизируйте размеры пакета для производительности и отказоустойчивости.

Построение системы, которую вызывают другие системы


  1. Убедитесь, что все API идемпотентны. Это обратная сторона повторов при тайм-аутах API. Вызывающие абоненты могут повторить попытку, только если ваши API безопасны для повторения и не вызывают неожиданных побочных эффектов. Под API я имею в виду как синхронные API, так и любые интерфейсы обмена сообщениями — клиент может опубликовать одно и то же сообщение дважды.
  2. Определите SLA — согласованный уровень качества предоставления услуги. Потребуется SLA для времени отклика и пропускной способности, а также код для их соблюдения. В распределенных системах гораздо лучше быстро потерпеть неудачу, чем позволить абонентам ждать.

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

  3. Определите и ограничьте пакетирование для API-интерфейсов. Максимальные размеры пакетов явно определяют и ограничивают обещанным SLA — это следствие соблюдения SLA.
  4. Подумайте заранее о наблюдаемости системы. Наблюдаемость — способность анализировать поведение системы, не обращая внимания на ее внутреннее устройство. Подумайте заранее, какие метрики и данные о системе нужны, чтобы ответить на вопросы, на которые ранее невозможно было получить ответы. И продумайте инструменты для получения этих данных.

    Мощный механизм — разбить логику системы на «домены» и публиковать события каждый раз, когда в «домене» происходит событие. Например, получен запрос с id = 123, возвращен ответ на запрос с id =123. Обратите внимание, как можно использовать эти два «доменных» события, чтобы получить новую метрику под названием «время отклика». Из необработанных данных следуют заранее определенные агрегации.


Общие рекомендации


  1. Используйте агрессивное кэширование. Сеть нестабильна, поэтому кэшируйте столько данных, сколько возможно. Ваш механизм кэширования может быть удаленным, например сервер Redis, работающий на отдельной машине. По крайней мере, вы перенесете данные в свою область управления и уменьшите нагрузку на другие системы.
  2. Определите единицу сбоя. Если API или сообщение представляет несколько единиц работы (пакет), то какова единица сбоя? В случае сбоя вся полезная нагрузка выйдет из строя или, напротив, отдельные блоки будут успешны или потерпят неудачу независимо? Отвечает ли API кодом успеха или неудачей в случае частичного успеха?
  3. Изолируйте внешние доменные объекты на границе системы. Еще один пункт, который, по моему опыту, вызывает проблемы в долгосрочной перспективе. Не стоит разрешать использование доменных объектов других систем во всей вашей системе для повторного использования. Это связывает вашу систему с работоспособностью другой системы. И каждый раз, когда меняется другая система, нужно рефакторить код. Поэтому стоит создавать собственную внутреннюю схему данных и преобразовывать внешние полезные данные в эту схему. И затем использовать внутри собственной системы.

Безопасность


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

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

Удачи!

Что еще почитать:

  1. Как спокойно спать, когда у вас облачный сервис: основные архитектурные советы.
  2. Как технический долг и лже-Agile убивают ваши проекты.
  3. Наш канале в Телеграме о цифровой трансформации.

Вехи (контрольные точки) проекта [Wiki]

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

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

На диаграмме Ганта веха проекта – это задача с длительностью, равной нулю.

  1. Веха в графической части диаграммы Ганта отображается ровно в тот момент времени, когда заканчиваются или начинаются связанные с ней задачи.

  2. Если предшествующей связи нет, то веха располагается в начале дня. В этом случае последующая связанная задача начинается в один день с вехой (Рисунок 1).

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

Рисунок 1 – Вехи на диаграмме Ганта

Обнулить длительность задачи можно, изменив ее даты или выбрав соответствующий пункт в контекстом меню (Рисунок 2).

Рисунок 2 – Обнулить длительность задачи

При обнулении длительности:

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

Планирование контрольных точек

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

КТ фиксирует:

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

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

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

Уровни КТ
0. Вехи

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

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

Контроль таких результатов выполняет сотрудник высокого уровня (Генеральный директор, заместитель Генерального директора) или специальное подразделение (Проектный офис).

1. Критические

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

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

Контроль получения этих результатов выполняется на высоком уровне.
Отклонение сроков достижения таких результатов рассматривается первым лицом или специальным органом – проектным комитетом.

2. Ключевые

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

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

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

3. Оперативные

На нижних уровнях расположены оперативные результаты.

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

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

Роли

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

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

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

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

Диаграмма контрольных точек

Что такое «контрольная точка»

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

С т.зр. системы ADVANTA контрольная точка – это объект с нулевой длительностью.

Что такое диаграмма контрольных точек

Диаграмма контрольных точек в отчёте «Проекты и работы» – это визуальное представление прохождения, выполнения задач в рамках проекта.

Диаграмма строится на основе данных «Дочерние объекты».

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

Рисунок 1 – Отображение диаграммы контрольных точек

Принципы формирования диаграммы
Цвета
Ромбы
Название объектов

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

Особенность отображения «Не начатых» и «Завершённых» в рамках одного периода
Есть и то, и то

Если в выборке присутствуют контрольные точки со статусами «Завершен» и «Не начат», то выбираются и отображаются как ромбики:

Есть КТ с одним из этих статусов

Если в выборке присутствует хотя бы одна контрольная точка со статусом «Не начат» или «Завершен», то:

Как добавить диаграмму
  1. Создайте новый отчёт «Проекты и работы» или зайдите в уже существующий, где хотите добавить диаграмму контрольных точек.

  2. Меню управления (три точки наверху справа) → «Изменить»

  3. В поле «Дочерние объекты»:

    1. выберите в выпадающем меню «Диаграмма контрольных точек»;

    2. задайте выборку дочерних объектов;

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

      В качестве контрольной точки могут использоваться любые типы объектов.

    4. сохраните изменения.

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

Настройка диаграммы

  1. Выберите шаг отображения периода (месяц, квартал или год):

  2. Поставьте чек-бокс на «Скрыть объекты без КТ в выбранном периоде», если в отчете не должно отображаться проектов, у которых в выбранном вами периоде нет контрольных точек.
    Если нужно, чтобы отображались все проекты, вне зависимости от наличия контрольных точек, чек-бокс не ставьте.

  3. Выберите временной период для отображения диаграммы.

  4. Выбрать даты окончания дочерних объектов, которые будут использоваться при включении дочернего объекта в шаг периода проекта: «Плановая дата окончания» или «Утвержденная дата окончания» (дата из последнего базового плана).

  5. «Показать названия объектов» – если хотите, чтобы названия объектов отобразились в диаграмме.

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

  6. «Показать исполнителей» – чтобы добавить имена исполнителей в диаграмму.

    Если полномочия исполнителя делегированы, то на диаграмме отображается делегированный исполнитель с иконкой «часики», до тех пор, пока он не примет полномочия.

  7. «Показать даты завершения» – включает отображение дат завершения дочерних объектов.

  8. Задайте визуальное оформление диаграммы:

    1. Размер шрифта контрольных точек

    2. Отображение легенды – соответствие размеров и цветов иконок для контрольных точек в диаграмме.

      Легенда появится под таблицей отчета.

    3. Размер и цвет иконок: «Задать размер иконок КТ» и «Задать цвет иконок КТ» соответственно.

    4. Цвет статуса проекта: «Задать цвет полос проектов».

Рисунок 2 – Настройка диаграммы КТ

Логика расчета отклонения

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

В качестве «Даты дочерних объектов» выбрано значение:

«Плановая дата окончания» «Утвержденная дата окончания»
Фактическая дата заполнена фактическая дата объекта минус плановая дата объекта фактическая дата объекта минус дата базового плана для указанного объекта
Фактическая дата НЕ заполнена расчет не производится плановая дата объекта минус дата базового плана для указанного объекта
Доступные форматы для экспорта настраиваемых отчетов DE Reporting

Не говори красиво, говори правильно… или Глоссарий управления проектами | Директор информационной службы

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

Григорий Львович Ципес, ведущий системный аналитик компании IBS, [email protected] Александр Самуилович Товб, руководитель проектов компании IBS, [email protected]
Начнем эту заметку с рассказа об одном забавном эпизоде. Однажды в нашей компании проходили практику студенты-дипломники, специализирующиеся на управлении проектами. Выдавая им задание, руководитель практики (один из авторов этой заметки) попросил описать scope проекта (он так и сказал — скоуп). «А что такое scope?» — осторожно поинтересовалась одна девушка. «О, scope — это…» — ответил руководитель и нарисовал руками в воздухе нечто, напоминающее средних размеров глобус. «Понятно, — грустно сказала девушка. — Нам в институте так же объясняли».

Ситуация очень характерная и довольно опасная. Есть некий термин, употребляемый в англоязычных источниках и не имеющий очевидного и однозначного перевода на русский язык в контексте управления проектами. На профессиональном жаргоне мы привыкли пользоваться этим термином на языке оригинала. Действительно, гораздо удобнее сказать scope, чем какое-нибудь достаточно громоздкое «содержание и границы». Если кому-то непонятно, то всегда можно объяснить, хотя бы с помощью жестов. А приводит все это к тому, что некоторое время спустя точного значения термина никто уже не помнит, каждый трактует его по-своему, и при этом все думают, что понимают друг друга!

Прибавьте к этому еще и то, что и на языке оригинала многие термины трактуются вовсе не однозначно. В сравнительном словаре Макса Вайдемана [MW], опирающемся на более полусотни источников, для многих терминов приводится по 5-6 различных определений. Русскоязычные глоссарии, которых тоже набирается немалое количество, во многих случаях запутывают ситуацию еще больше.

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

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

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

КРАТКИЙ СРАВНИТЕЛЬНЫЙ ГЛОССАРИЙ

Проект (project) — уникальный комплекс взаимосвязанных мероприятий для достижения заранее поставленных целей при определенных требованиях к срокам, бюджету и характеристикам ожидаемых результатов.
Проект — уникальный процесс, состоящий из набора взаимоувязанных и контролируемых работ с датами начала и окончания и предпринятый, чтобы достичь цели соответствия конкретным требованиям, включая ограничения по времени, затратам и ресурсам [ISO].
Проект — целенаправленная деятельность временного характера, предназначенная для создания уникального продукта или услуги [НТК].
Управление проектами (Project Management) — профессиональная творческая деятельность по руководству людскими и материальными ресурсами путем применения современных методов, средств и искусства управления для успешного достижения заранее поставленных целей при определенных требованиях к срокам, бюджету и характеристикам ожидаемых результатов проектов, осуществляемых в рыночных условиях в социальных системах.
Управление проектом включает планирование, организацию, мониторинг и контроль всех аспектов проекта в ходе непрерывного процесса достижения его целей [ISO].
Управление проектом — процесс применения знаний, навыков, методов, средств и технологий к проектной деятельности с целью достижения или превышения ожиданий участников проекта [PMBOK].
План управления проектом (Project Management Plan) — основополагающий документ (baseline document), с которого должен начинаться любой проект. Содержит согласованное всеми участниками документально зафиксированное представление о проекте. В инвестиционных проектах — мастер-план проекта (Project Master Plan) (УП).
Устав проекта (Project Charter) — документ, разработанный вышестоящей администрацией, который предоставляет менеджеру проекта право использовать ресурсы организации для выполнения работ проекта [PMBOK].
Определение проекта (Project Definition Report) — документ, определяющий проект, в том числе: каковы цели и результаты проекта; в чем его необходимость; что должно быть сделано; как, когда и где это должно быть сделано; что для этого нужно; сколько это будет стоить; какие необходимо привлечь внешние ресурсы и организации; какие стандарты и процедуры подлежат соблюдению при осуществлении проекта [НТК].
Базис (Project Baseline) — основополагающие параметры и, фиксирующие их согласованное понимание всеми участниками, документы проекта — «точка опоры» для всего последующего развития проекта.
Базовый план (Baseline) — первоначальный план проекта с утвержденными изменениями. Базовый план бывает также и по составляющим проекта — стоимости, расписанию и т. д. [ОУП]
Содержание и границы проекта (Project Scope) — цели и задачи проекта, основные результаты, критерии оценки того, что работа или ее часть выполнена.
Содержание проекта, объем работ (Scope) — (букв. пределы, рамки, сфера). Содержание работ и результаты проекта (или его части). Проект описывается путем перечисления всех выполняемых работ, необходимых ресурсов и конечных результатов, включая требования к качеству [УП].
Предметная область (Scope) — совокупность продуктов и услуг, производство которых должно быть обеспечено в рамках осуществляемого проекта [PMBOK].
Цели (Scope) — совокупность продуктов и услуг, намеченных к производству в проекте [ОУП].
Ключевые вехи проекта (Project Milestones) — ключевые события проекта, свершение которых является необходимым и достаточным условием, определяющим достижение результатов проекта. Обычно представляются в виде схемы или таблицы с взаимосвязями и сроками свершения, образуя План по Вехам (Milestone Plan, Milestone Schedule, Master Schedule).
Контрольное событие — важное событие проекта, обычно связанное с достижением важнейших результатов [ОУП].
Другие варианты — ключевое событие [УП], контрольная точка [УП].
Структура декомпозиции работ (Work Breakdown Structure), СДР (WBS) — представление проекта в виде иерархической структуры работ, полученной путем последовательной декомпозиции. СДР предназначена для детального планирования, оценки стоимости и обеспечения персональной ответственности исполнителей.
Структурная декомпозиция работ — иерархическая структуризация работ проекта, ориентированная на основные результаты проекта, определяющие его предметную область. Каждый нижестоящий уровень структуры представляет собой детализацию элемента высшего уровня проекта. Элементом проекта может быть как продукт, услуга, так и пакет работ или работа [НТК].
Иерархическая структура работ — структуризация работ проекта, отражающая его основные результаты. Каждый следующий уровень иерархии отражает более детальное определение компонентов проекта [ОУП].
Структура разбиения работ — иерархическая структура последовательной декомпозиции проекта на подпроекты, пакеты работ различного уровня, пакеты детальных работ [УП].
Проектные отклонения (Project Exceptions) — несовпадения фактических и плановых результатов проекта, причины таких несовпадений, методы и технологии, позволяющие справляться с такими ситуациями в проекте. Включают в себя риски, проблемы и изменения.
Отклонение (Deviation) — выход за пределы установленных требований. К отклонениям относятся случаи, когда результат работы не удовлетворяет требованиям или необоснованно их превышает[QMPP].
Проектные риски (Project Risks) — возможность возникновения непредвиденных ситуаций или рисковых событий в проекте, которые могут негативно или позитивно воздействовать на достижение целей проекта. Риск проекта характеризуется следующими факторами: источниками и характеристиками событий, которые могут оказать влияние на его выполнение; вероятностями появления таких событий; возможным ущербом проекту и оценкой его влияния на проект.
Риск — потенциальная, численно измеримая возможность неблагоприятных ситуаций и связанных с ними последствий в виде потерь, ущерба, убытков [УП].
Проектный риск в самом общем понимании — это опасность нежелательных отклонений от ожидаемых состояний в будущем, из расчета которых принимаются решения в настоящем [УПП].
Проблемы проекта (Project Problems) — любой функциональный, технический или связанный с бизнесом вопрос, который возник в процессе осуществления проекта и требует изучения и решения для того, чтобы проект мог идти так, как запланировано.
Проблемные ситуации (Problem situations) — возникающие при осуществлении проекта ситуации, для выхода из которых необходимо находить оптимальные решения [НТК].
Решение проблем (Problem Solving) — определение последовательных систематических процедур, с помощью которых анализируются и решаются проблемные ситуации [НТК].
Изменения проекта (Project Changes) — модификация ранее согласованных продуктов и услуг, сроков исполнения и стоимости работ, используемых ресурсов, управленческих и технологических процессов и т. п.
Изменения — увеличение или уменьшение характеристик элементов проекта. Пересмотр базового плана проекта. Подразумевает документально оформленные и утвержденные изменения [УП].
Календарный план проекта (Project Schedule) — перечень планируемых работ проекта со сроками исполнения и ответственными лицами, подготовленный в соответствующей форме, определенной планом управления проектом.
Расписание проекта — плановые даты для выполнения работ и плановые даты для наступления контрольных (ключевых) событий («вех») проекта [НТК].
Куратор проекта (Sponsor) — лицо, отвечающее перед руководством предприятия за успех проекта в целом и имеющее полномочия для решения ресурсных и других проблем, эскалированных руководителем проекта.
Спонсор проекта — лицо или организация, для которых проект предпринят и которые в наибольшей степени принимают на себя проектный риск [BS2].
Руководитель проекта (Project manager) — менеджер, отвечающий за успешную реализацию проекта, взаимодействие с заказчиком, субподрядчиками и подразделениями компании, а также за организацию подготовки и предоставление отчетности по проекту.
Менеджер проекта — лицо, ответственное за управление проектом [PMBOK].
Бюджет проекта (Project budget) — утвержденное запланированное распределение финансовых средств проекта по различным основаниям: по статьям затрат, по временным периодам, по участникам проекта, по решаемым задачам, по компонентам ожидаемых результатов, по элементам организационной структуры проекта и т. п.
Бюджет проекта — сметная стоимость, распределенная по периодам выполнения проекта [НТК].
Заинтересованные лица (Stakeholders) — физические и юридические лица, как непосредственно участвующие в проекте, так и те, чьи интересы могут быть затронуты процессами осуществления проекта и его результатами.
Участники проекта — физические лица и организации, которые непосредственно вовлечены в проект или чьи интересы могут быть затронуты при осуществлении проекта [PMBOK].
Источники, по которым цитируются определения:
  1. [BS2] Британский стандарт BS 6079-2:2000. Project management. Part 2 Vocabulary. (Перевод авторов статьи.)
  2. [ISO] ISO/TR 10006: 1997 (E). Quality Management — Guidelines to quality in project management. (Перевод Г. Е. Герасимовой.)
  3. [MW] Wideman Comparative Glossary of Project Management Terms. PMForum, 2000 (www.maxwideman.com).
  4. [PMBOK] A Guide to the Project Management Body of Knowledge. PMI Standards Committee.1996 Edition. (Перевод М. Грашиной.)
  5. [QMPP] Quality Management for Projects and Programs. Lew Ireland. Project Management Institute. 1991. (Цитируется по [MW], перевод авторов статьи.)
  6. [НТК] Основы профессиональных знаний и национальные требования к компетентности специалистов по управлению проектами. Под ред. В. И. Воропаева, 2001.
  7. [ОУП] Основы управления проектами. В. И. Либерзон.
  8. [УП] Управление проектами. Справочник для профессионалов. Под ред. И. И. Мазура и В. Д. Шапиро, 2001.
  9. [УПП] Управление программами и проектами. 17-модульная программа для менеджеров — «Управление развитием организации». Модуль 8. М. Л. Разу, В. И. Воропаев и др., 1999.

Не говори красиво, говори правильно… или Глоссарий управления проектами

Поделитесь материалом с коллегами и друзьями

Методические основы управления ИТ-проектами — тест 2

Главная / Менеджмент / Методические основы управления ИТ-проектами / Тест 2 Упражнение 1:
Номер 1
Что такое организационная структура проекта?

Ответ:

&nbsp(1) последовательность фаз проекта, через которые он должен пройти для гарантированного достижения целей проекта&nbsp

&nbsp(2) выделение ролей исполнителей, которые необходимы для реализации проекта, определение взаимоотношений между ними и распределение ответственности за выполнение задач&nbsp

&nbsp(3) деятельность, связанная с использованием или созданием некоторой информационной технологии&nbsp


Номер 2
Что такое жизненный цикл проекта?

Ответ:

&nbsp(1) последовательность фаз проекта, через которые он должен пройти для гарантированного достижения целей проекта&nbsp

&nbsp(2) выделение ролей исполнителей, которые необходимы для реализации проекта, определение взаимоотношений между ними и распределение ответственности за выполнение задач&nbsp

&nbsp(3) деятельность, связанная с использованием или созданием некоторой информационной технологии&nbsp


Номер 3
Какие действия относятся к организационной структуре проекта?

Ответ:

&nbsp(1) определение взаимоотношений между исполнителями проекта&nbsp

&nbsp(2) выделение ролей исполнителей, которые необходимы для реализации проекта&nbsp

&nbsp(3) распределение ответственности за выполнение задач&nbsp


Упражнение 2:
Номер 1
К какой области знания проектного управления относится процесс тестирования программного продукта?

Ответ:

&nbsp(1) управление интеграцией&nbsp

&nbsp(2) управление качеством&nbsp

&nbsp(3) управление содержанием&nbsp

&nbsp(4) управление человеческими ресурсами&nbsp


Номер 2
Какие процессы относятся к управлению качеством?

Ответ:

&nbsp(1) оценка альтернатив развития проекта&nbsp

&nbsp(2) приемка результатов&nbsp

&nbsp(3) тестирование&nbsp

&nbsp(4) качественный анализ рисков&nbsp


Номер 3
Какие процессы не относятся к управлению качеством?

Ответ:

&nbsp(1) оценка альтернатив развития проекта&nbsp

&nbsp(2) тестирование&nbsp

&nbsp(3) качественный анализ рисков&nbsp

&nbsp(4) приемка результатов&nbsp


Упражнение 3:
Номер 1
Для чего разрабатывается технико-экономическое обоснование ИТ-проекта?

Ответ:

&nbsp(1) для наглядного отражения ситуации, складывающейся на предприятии в результате качественных или количественных изменений в его деятельности&nbsp

&nbsp(2) для обоснования необходимости приобретения дополнительного оборудования&nbsp

&nbsp(3) для отчета о финансовом состоянии ИТ-проекта&nbsp


Номер 2
Какие из перечисленных бизнес-выгод являются наименее определенными?

Ответ:

&nbsp(1) качественные&nbsp

&nbsp(2) измеримые&nbsp

&nbsp(3) количественные&nbsp

&nbsp(4) финансовые&nbsp


Номер 3
Какие из перечисленных бизнес-выгод являются наиболее определенными?

Ответ:

&nbsp(1) качественные&nbsp

&nbsp(2) измеримые&nbsp

&nbsp(3) количественные&nbsp

&nbsp(4) финансовые&nbsp


Упражнение 4:
Номер 1
Что такое функция качества?

Ответ:

&nbsp(1) инструмент для оценки качества проведенного тестирования&nbsp

&nbsp(2) инструмент для работы с заказчиком, который позволяет встроить его требования в проект&nbsp

&nbsp(3) инструмент для оценки квалификации участников проекта&nbsp


Номер 2
На каком этапе происходит определение наиболее значимых условий заказчика?

Ответ:

&nbsp(1) подготовка требований заказчика &nbsp

&nbsp(2) определение требований проекта &nbsp

&nbsp(3) формирование матрицы взаимосвязей &nbsp

&nbsp(4) формирование матрицы отношений &nbsp


Номер 3
На каком этапе выполняется формулировка требований в терминах конкретных действий, при помощи которых команда планирует и реализует проект?

Ответ:

&nbsp(1) подготовка требований заказчика &nbsp

&nbsp(2) определение требований проекта &nbsp

&nbsp(3) формирование матрицы взаимосвязей &nbsp

&nbsp(4) формирование матрицы отношений &nbsp


Упражнение 5:
Номер 1
Какие данные учитываются при определении степени детализации иерархической структуры проекта?

Ответ:

&nbsp(1) количество участников проекта&nbsp

&nbsp(2) количество уровней в иерархической структуре проекта&nbsp

&nbsp(3) количество и средний размер пакета работ, принятые в отрасли&nbsp


Номер 2
Какая информация имеет ключевое значение для составления описания содержания проекта?

Ответ:

&nbsp(1) устав проекта&nbsp

&nbsp(2) технико-экономическое обоснование&nbsp

&nbsp(3) количество уровней в иерархической структуре проекта&nbsp

&nbsp(4) формулировка требований организации-заказчика&nbsp


Номер 3
Что такое иерархическая структура проекта?

Ответ:

&nbsp(1) описание того, что нужно сделать в рамках проекта&nbsp

&nbsp(2) ориентированный на результаты способ группировки элементов проекта, который упорядочивает и определяет общее содержание проекта&nbsp

&nbsp(3) описание характеристик и границы проекта, а также связанных с ним продуктов и услуг&nbsp


Упражнение 6:
Номер 1
Что определяют технологические границы проекта?

Ответ:

&nbsp(1) все системы и существующие интерфейсы, которые связаны с реализацией ИТ-проекта или будут им затронуты&nbsp

&nbsp(2) территориальное распределение проекта&nbsp

&nbsp(3) подразделения (включая юридические лица), которые должны участвовать в проекте&nbsp

&nbsp(4) бизнес-направления и бизнес-процессы, охватываемые проектом автоматизации&nbsp


Номер 2
Что определяют функциональные границы проекта?

Ответ:

&nbsp(1) все системы и существующие интерфейсы, которые связаны с реализацией ИТ-проекта или будут им затронуты&nbsp

&nbsp(2) территориальное распределение проекта&nbsp

&nbsp(3) подразделения (включая юридические лица), которые должны участвовать в проекте&nbsp

&nbsp(4) бизнес-направления и бизнес-процессы, охватываемые проектом автоматизации&nbsp


Номер 3
Что определяют организационные границы проекта?

Ответ:

&nbsp(1) все системы и существующие интерфейсы, которые связаны с реализацией ИТ-проекта или будут им затронуты&nbsp

&nbsp(2) территориальное распределение проекта&nbsp

&nbsp(3) подразделения (включая юридические лица), которые должны участвовать в проекте&nbsp

&nbsp(4) бизнес-направления и бизнес-процессы, охватываемые проектом автоматизации&nbsp


Упражнение 7:
Номер 1
Какие условия являются критическими факторами успеха?

Ответ:

&nbsp(1) привлечение конечных пользователей&nbsp

&nbsp(2) компетентный состав команды&nbsp

&nbsp(3) принятие системы сотрудниками&nbsp

&nbsp(4) продуманная стратегия коммуникаций&nbsp


Номер 2
Для чего предназначена иерархическая структура работ?

Ответ:

&nbsp(1) для определения списка работ&nbsp

&nbsp(2) для оценки взаимосвязи и длительности работ&nbsp

&nbsp(3) для упорядочивания и определения общего содержания проекта&nbsp


Номер 3
От чего зависит степень детализации операций проекта?

Ответ:

&nbsp(1) от количества участников проекта&nbsp

&nbsp(2) от количества контрольных событий&nbsp

&nbsp(3) от количества конечных пользователей&nbsp


Упражнение 8:
Номер 1
Как называется весь перечень работ, запланированных для выполнения?

Ответ:

&nbsp(1) список контрольных событий&nbsp

&nbsp(2) список операций&nbsp

&nbsp(3) план управления проектом&nbsp


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

Ответ:

&nbsp(1) список контрольных событий&nbsp

&nbsp(2) список операций&nbsp

&nbsp(3) план управления проектом&nbsp


Номер 3
Что такое список контрольных событий?

Ответ:

&nbsp(1) весь перечень работ, запланированных для выполнения&nbsp

&nbsp(2) перечень основных событий, которые должны быть включены в расписание для мониторинга хода выполнения и управления проектом&nbsp

&nbsp(3) перечень действий, необходимых для определения, подготовки, интеграции и координации всех вспомогательных планов&nbsp


Упражнение 9:
Номер 1
В рамках какого пакета работ выполняется формирование и согласование плана проведения интервью?

Ответ:

&nbsp(1) исследование&nbsp

&nbsp(2) описание бизнес-процессов&nbsp

&nbsp(3) разработка системы&nbsp

&nbsp(4) тестирование системы&nbsp


Номер 2
В рамках какого пакета работ выполняется разработка решений по функциональной архитектуре?

Ответ:

&nbsp(1) обследование&nbsp

&nbsp(2) описание бизнес-процессов&nbsp

&nbsp(3) разработка системы&nbsp

&nbsp(4) тестирование системы&nbsp


Номер 3
В рамках какого пакета работ выполняется подготовка тестовых данных?

Ответ:

&nbsp(1) обследование&nbsp

&nbsp(2) описание бизнес-процессов&nbsp

&nbsp(3) разработка системы&nbsp

&nbsp(4) тестирование системы&nbsp


Упражнение 10:
Номер 1
При использовании какого метода построения сетевых диаграмм расписания проекта операции изображаются в виде прямоугольников (узлов), а зависимости - соединяющими их дугами?

Ответ:

&nbsp(1) метод стрелочных диаграмм (операции на дугах)&nbsp

&nbsp(2) метод предшествования (операции в узлах)&nbsp

&nbsp(3) метод опережений и задержек&nbsp


Номер 2
При использовании какого метода построения сетевых диаграмм расписания проекта операции представляются в виде дуг, которые соединяются в узлах, показывающих их зависимости?

Ответ:

&nbsp(1) метод стрелочных диаграмм (операции на дугах)&nbsp

&nbsp(2) метод предшествования (операции в узлах)&nbsp

&nbsp(3) метод опережений и задержек&nbsp


Номер 3
Какая информация отображается на сетевых диаграммах расписания проекта?

Ответ:

&nbsp(1) плановые операции проекта&nbsp

&nbsp(2) логические взаимосвязи между операциями&nbsp

&nbsp(3) текущие финансовые затраты проекта&nbsp


Упражнение 11:
Номер 1
Какая информация определяется при оценке ресурсов каждой плановой операции?

Ответ:

&nbsp(1) какие ресурсы будут использоваться&nbsp

&nbsp(2) в каком количестве будут использоваться ресурсы&nbsp

&nbsp(3) когда каждый из ресурсов будет доступен для выполнения проектных операций&nbsp


Номер 2
Что относится к ресурсам проекта?

Ответ:

&nbsp(1) персонал&nbsp

&nbsp(2) оборудование&nbsp

&nbsp(3) расходуемые предметы&nbsp


Номер 3
Какая информация является исходной для определения трудоемкости?

Ответ:

&nbsp(1) список операций&nbsp

&nbsp(2) наличие ресурсов&nbsp

&nbsp(3) план управления проектом&nbsp


Упражнение 12:
Номер 1
Какие утверждения являются верными?

Ответ:

&nbsp(1) длительность операции не может изменяться в ходе выполнения проекта&nbsp

&nbsp(2) на оценку длительности операции влияет содержание операции&nbsp

&nbsp(3) доступность ресурсов не влияет на оценку длительности операции&nbsp

&nbsp(4) оценка длительности операции выполняется с помощью иерархической структуры работ&nbsp


Номер 2
Какие утверждения являются неверными?

Ответ:

&nbsp(1) длительность операции не может изменяться в ходе выполнения проекта&nbsp

&nbsp(2) на оценку длительности операции влияет содержание операции&nbsp

&nbsp(3) оценка длительности операции выполняется с помощью иерархической структуры работ&nbsp

&nbsp(4) доступность ресурсов не влияет на оценку длительности операции&nbsp


Номер 3
В каком случае оценочная величина длительности операций вычисляется путем умножения количества работы на производительность труда?

Ответ:

&nbsp(1) при использовании оценки по аналогам&nbsp

&nbsp(2) при использовании параметрической оценки&nbsp

&nbsp(3) при использовании оценки по трем точкам&nbsp


Диаграмма контрольных событий — Набор инструментов для управления проектами — Драган Милошевич — rutlib5.com

Диаграмма контрольных событий

Что такое диаграмма контрольных событий?

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

Построение диаграммы контрольных событий

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

Сбор исходной информации.Качество диаграммы контрольных событий определяется качеством исходной информации, к которой относятся:

•содержание проекта;

•области ответственности;

•система управления расписанием;

•расписание проекта, возможно с показом взаимозависимостей.

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

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

КТО ВЛАДЕЕТ РАСПИСАНИЯМИ?

Веха

— Викисловарь

английский [править]

Этимология [править]

миля + камень .

Существительное [править]

этап ( множественное число этап )

  1. Каменный верстовой столб (или, как продолжение, из других материалов), один из серии пронумерованных маркеров, размещенных вдоль дороги через равные промежутки времени, обычно на обочине дороги или посредине.
  2. Важное событие в жизни или карьере человека, в истории нации, в жизни какого-либо проекта и т. Д.
    • 1933 , Стивен Спендер, «Похороны»:
      Смерть — еще одна веха на их пути.
    • 2012 март-апрель, Терренс Дж. Сейновски, «Хорошо связанные мозги», в American Scientist [1] , том 100, номер 2, страница 171:

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

Синонимы [править]
Связанные термины [править]
Переводы [править]

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

  • Японский: マ イ ル ス ト ー ン (ja) (mairusutōn), キ ロ ポ ス ト (kiroposuto), 里程 標 (ja) (り て い ひ ょ う, riteihyō)
  • Латиница: mīlliārium n
  • Македонский: милјоказ m (miljokaz)
  • Норманн: Пьер-де-Милль f
  • норвежский:
    Букмол: milestein m , milepæl (no) m , milepel m , milestolpe м
    нюнорск: milestein m , milepåle m , milestolpe
  • Польский: kamień milowy (pl) m
  • Португальский: marco miliário m , marco miliar
  • Русский: ми́льный ка́мень м (mílʹnyj kámenʹ), километро́вый столб m (kilometróvyy stolb)
  • Шотландский гэльский: clach-mhìle f
  • сербохорватский: miljokaz (sh)
  • Словацкий: míľnik m
  • Испанский: hito (es) m , mojón (es) m , cipo (es)
  • Шведский: milsten c , milstolpe (sv) c
  • Тагальский: batong-milyahe
  • Украинский: віха f (vixa), мильовий камінь m (мыльный камень)
  • Вьетнамский: cột mốc, cây số (vi), cột cây số, cột dặm
  • Volapük: liölaston

Глагол [править]

веха ( вехи в единственном числе от третьего лица, простое настоящее вех , причастие настоящего вехи , простое прошедшее и причастие прошедшего времени вехи )

  1. Для размещения вех (дороги и т.).
  2. Чтобы спланировать проект как серию основных шагов.

Анаграммы [править]

.

milestone — Перевод на русский примеры английский

Предложения: важная веха важная веха

На основании вашего запроса эти примеры могут содержать грубую лексику.

На основании вашего запроса эти примеры могут содержать разговорную лексику.

9 июля была достигнута еще одна важная веха — диабета в Италии.

9 июля была достигнута еще одна важная веха для лечения диабета в Италии.

Если бы он был реализован надлежащим образом, это было бы вехой в этой истории.

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

Таджикистану и Туркменистану следует присвоить рубеж 1.

Что касается Таджикистана и Туркменистана, то для них должен быть указан этап 1.

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

Со времени проведения Каирской конференции 1994 года мир преодолел важный этап .

За отчетный период был достигнут исторический рубеж — с введением всеобщего среднего образования в 2006 году.

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

Уровень углекислого газа в атмосфере перешагнул долгожданный рубеж — .

Уровень углекислого газа в атмосфере превысил пугающий рубеж .

Сегодня — ключевой рубеж в наших коллективных усилиях.

Сегодняшний день одной из важнейших вех в наших коллективных усилиях.

Конференция отметила веху на пути к устойчивому развитию.

Конференция сообщает вехой на пути к устойчивому развитию.

Успешное внедрение IPSAS стало важной вехой в наших усилиях по реформированию управления.

Успешный переход на МСУГС явился знаменательной вехой в наших усилиях по исполнению реформы управления.

Это рубеж в истории Организации Объединенных Наций.

Это стало вехой в истории Организации.

Несомненно, это веха, в усилиях по провозглашению нового политического устройства Сомали в августе.

Это, бесспорно, является важной вехой на пути к установлению в Сомали в августе нового политического строя.

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

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

Первая демократическая передача власти в Афганистане — это еще одна веха в политическом переходе страны.

Еще одной вехой в процессе перехода в Афганистане является первый случай перехода страной демократическим путем.

ГРУЛАК приветствует новую Лимскую декларацию, которую она считает вехой в истории ЮНИДО.

ГРУЛАК приветствует новую Лимскую декларацию, которую она говорит вехой в истории ЮНИДО.

Принятие 10 сентября 2012 года резолюции 66/290 Генеральной Ассамблеи стало важной вехой на пути к обеспечению безопасности человека.

Принятие резолюции 66/290 явлением Ассамблеи 10 сентября 2012 года выступило вехой в продвижении концепции безопасности человека.

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

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

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

вехи в области социальной социальной политики.

Г-н Хан (Пакистан) говорит, что Конвенция стала вехой в области контроля над вооружениями и разоружения.

Г-н Хан (Пакистан) говорит, что Конвенция является национальной вехой в области контроля над вооружениями и разоружения.

Событие стало еще одной вехой в 2013 году, в год ИКТ и повышения безопасности дорожного движения.

Данное мероприятие стало одной из вех 2013 года, года ИКТ и повышения безопасности дорожного движения.

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

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

No related posts.

Leave a Reply

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *