Диплом: Применение методов управления проектами и задачами оптимизации процессов принятия решений в ООО "Такстелеком"

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
61
Count
Количество задач
Now
Расчетная дата
В рамках текущей исследовательской работы, поле Tracker_id не будет
использовано, ограничившись анализом лишь в пределах родительских
проектов. Tracker_id может быть использован для идентификации
внутренних подпроектов, таких, например как «Документирование проекта»,
«Адаптация для внешней подсистемы N» и других. Для получения данных в
разрезе недель будем использовать следующий запрос SQL к базе данных:
with a as (
select project_id, status_id, sum(count), now
from stat.cumulative_flow
group by project_id, status_id, now
) select a.*,
extract(week from a.now) week,
extract(month from a.now) mnth,
extract(year from a.now) yr from a
where project_id = 12
Листинг 1 Запрос на получение данных в разрезе недель и месяцев
Более подробно с кодом, использованным для получения
анализируемых данных, можно ознакомиться в приложении «Модификация
СУП Redmine для формирования CFD».
Поскольку анализ каждого из существующих проектов может занять
значительный объем, ограничимся анализом одного, но наиболее
интересного проекта, доступ к исходному коду, которого недавно был
предоставлен для широкой публики. Это проект с идентификатором – 12,
кодовое имя проекта pgCodeKeeper, исходный код проекта и история
изменения кода проекта можно посмотреть в открытом доступе на сайте
GitHub по адресу: https://github.com/pgcodekeeper/pgcodekeeper
62
Таблица 4
Категоризация статусов выполнения задач
Идентификатор
Описание статуса задачи
1
Новая. Задача создана и ожидает выполнения
2
В работе. Задач находится в работе
5
Закрыта. Работа над задачей завершена.
8
Инспекция. Требуется инспекция выполненной
задачи.
Типичный рабочий процесс работы над задачей может выглядеть как
последовательное перемещение по статусам: «Новая», «В работе»,
«Инспекция», «Закрыта». На большинстве этапов задача может быть
отклонена, в случае, если задача перестала быть актуальной.
На рисунке ниже представлена годовая накопительная диаграмма,
полученная в результате сбора данных на объекте исследования ООО
«Такстелеком». Далее, в текущей главе, мы рассмотрим накопительные
диаграммы более детально.
63
Рисунок 17 Годовая накопительная диаграмма
Какие выводы можно сделать по годовой диаграмме? Нижняя голубая
линия показывает количество задач, дошедших до производственной среды.
Линия растёт достаточно с некоторым приростом по скорости в феврале и
марте 2017 года.
Оранжевая линия показывает количество отклоненных задач.
Причинами отклонения задач могут выступать различные причины. В
первую очередь, это потеря актуальности задачи у заказчика.
В процессе выполнения задач может быть также решено о
нецелесообразности выполнения некоторых задачи в силу технических
ограничений. После консультации с заказчиком такие задачи тоже могут
переходит в состояние отклонено. Можно видеть, что за анализируемый
период количество отклоненных задач выросло незначительно с 47 в декабре
2016 года до 57 в ноябре 2017. Необходимо отметить, что количество
отменённых задач не входит в количество задач в работе (WIP), и
64
соответственно оказывает влияние на время доставки задачи до
производственной среды (production lead time). Для того, чтобы исключить
влияние данного показателя на расчеты количества задач в работе и времени
доставки задачи до производственной среды в последующих, более
детализированных диаграммах, количество отменённых задач будет
исключено из диаграмм.
Серая линия показывает количество задач, которые находятся на
инспекции. В масштабе года и относительно задач отклоненных и новых
(синяя линия) количество этих задач кажется небольшим. Можно заметить,
что в течении года количество задач, находящихся на инспекции меняется от
большего в начале года, уменьшения ближе к середине и последующего
увеличения к завершению года. Мы ещё не раз будем наблюдать за этим
показателем на более детальных диаграммах в разрезе недель.
Желтая линия практически слилась с серой. Текущий масштаб
диаграммы не позволяет увидеть общее количество задач в работе. Лишь по
расшифровке в таблице с данными мы видим, что количество задач на
данному этапе колеблется от 2 до 5 в течении исследуемого периода
времени.
Наконец, синяя линия показывает общее количество задач,
находящихся в состоянии «Новая». Пожалуй, это единственный показатель,
который можно подвергнуть анализу на диаграмме подобного масштаба. Для
нас будет важно отметить следующее: рост задач непрерывен в течении всего
анализируемого периода и общее количество задач в состоянии «Новая»
никогда не уменьшалось меньше значения 32 в октябре 2017 года, что в свою
очередь говорит о том, что:
Состояние «Новая» используется как общий резерв проекта, а не
выделяется для отдельных итераций.
65
Значительный объем задач в состоянии «Новая» влияет на время
поставки задач (lead time).
Анализ текущей накопительной диаграммы потока позволяет сделать
следующие выводы (с учётом того, что одновременно над проектом работало
не более трёх программистов):
Общее количество задач в состоянии «Новая» достаточно велико и
влияет на время доставки решения до производственной среды.
Этап «Инспекция» переполнен выполненными задачами.
Темп доставки задач до производственной среды непостоянен.
Некоторые временные участки содержат значительно большее
количество задач «В работе», чем на тот период работало над
проектом программистов. Например, в феврале-апреле было
зафиксировано 5 одновременно открытых задач «В работе», при
максимально возможном количестве программистов не более трёх.
Общее время доставки настолько велико (с учётом первых двух
пунктов), что невозможно выполнить прогноз времени выполнения
задачи попавшей в резерв выполнения задач. Т.е. если провести
горизонтальную линию времени доставки задачи от крайней левой
точки синей линии (состояние «Новая»), то пересечения с голубой
линией (состояние «Закрыта») не произойдёт в пределах
анализируемого периода – т.е. фактически 12 месяцев.
В текущей главе мы ознакомились с объектом исследования –
предприятием ООО «Такстелеком». Описана схема информационных
центров, входящих в структуру предприятия и организация процесса работы
предприятия.
Были описаны как факторы внешней микросреды в которых находится
объект исследования, такие как географический фактор, фактор трудовых
66
ресурсов, профсоюзов, капитала, поставщиков, потребителей, конкурентов и
органов местной власти, так и факторы внешней макросреды среди которых
были рассмотрены: политическая ситуация, состояние экономики, инфляция,
законы и государственные органы, а также природно-климатические и
техногенные факторы.
Дополнительно даны характеристикам внутренней среды, таким как:
стратегия организации, структура организации, персонал и коммуникации.
В заключительном параграфе главы описаны применяемые методы
управления IT-проектами осуществляемые в пределах информационных
центров объекта исследования. Рассказаны преимущества гибких
методологий управления IT-проектами. Проведён анализ годовой
накопительной диаграммы, обозначены места требующие внимания.
В следующей главе будут даны рекомендации по устранению «узких»
мест анализируемого проекта и дана оценка эффективности предложенных
изменений.
67
Глава 3. Совершенствование системы управления проектами ООО
«Такстелеком»
3.1. Мероприятия по оптимизации процессов принятия решений в ООО
«Такстелеком»
В текущем параграфе рассмотрим ряд мероприятий, выполнение
которых с одной стороны увеличит скорость доставки выполненных задач
(delivery rate - DR), а с другой сигнализировать о возникновении проблем
значительно раньше, чем при текущей организации выполнения проекта.
Поскольку текущая проектная деятельность выполняется в рамках
потоковой системы, мероприятия по оптимизации процессов принятия
решения по выполнению проектов будут ориентированы на улучшение
потоковой системы. Как мы уже рассматривали в предыдущей главе
потоковый подход хорошо работает при выполнении проектов, решающих
слабоструктурированные проблемы.
Для оптимизации процесса принятия решения в рамках
исследовательской работы были предложены следующие мероприятия:
Создание очередей ожидания [24] выполняемых работ
Ограничение объёма работ на этапах процесса
Маркировка блокирующих задач
Учет времени доставки (Lead Time) и времени цикла (Cycle Time)
задачи.
Анализ пропускной способности потока выполнения задач
Ниже будут описаны каждый из вышеизложенных пунктов.
68
Создание очередей ожидания
Процесс формирует очередь, когда выполняемая задача завершена на
одном этапе выполнения работы и ожидает начала работы над следующим.
Зачастую выполняемая задача большую часть своего жизненного цикла
проводит непосредственно в очередях проекта, поэтому становится крайне
важным понимать какие задачи находятся сейчас в очередях, как долго они
находятся в очереди, общее количество задач в очереди и определить
непосредственное влияние находящихся в очереди задач на выполнение
проекта.
Наложение ограничений по времени нахождения задачи в очереди
помогает уменьшить общее время цикла выполнения задачи и сохранить
темп выполнение потока проекта.
Отслеживание времени нахождения задачи в очереди позволяет
формировать оценку эффективности выполнения работы, которую можно
представить, как отношение задач, находящихся в очереди (queued issues), к
общему количеству задач, находящихся в работе (work in progress).
(1)
где Кэ – коэффициент эффективности;
Q – количество задач находящихся в ожидании, в очередях;
WIP – общее количество задач находящихся в работе;
При достигается высокая степень эффективности выполнения
задач проекта.
На основании полученных данных можно также формировать
диаграмму эффективности в разрезе нескольких очередей ожидания, для
69
того, чтобы можно было наглядно увидеть какая именно очередь требует к
себе наибольшего внимания.
Применительно к объекту исследования сформированы следующие
рекомендации по созданию очередей:
1. Этап «Новая» разделить на три очереди:
o Долгосрочный резерв задач с низким приоритетом
выполнения. Резерв для задач с идеями, ценность которых на
текущий момент не выяснена.
o Среднесрочный резерв задач с нормальным приоритетом
выполнения. Данный резерв предназначен для задач на
ближайшее 2-3 итерации и содержит насущные задачи
удовлетворяющие потребности заказчика.
o Краткосрочный резерв задач с высоким приоритетом
выполнения, запланированные задачи в рамках текущей
проектной итерации.
2. Добавить этап «В работе - завершено» и «Инспекция -
завершено», как очереди ожидания для этапов «Инспекция» и
«Гарантия качества» соответственно.
Ограничение выполняемой работы на этапах (WiP Limit)
Отслеживание задач, которые уже начались, но ещё не завершились
помогает улучшить поток прохода задач через систему.
Введение и использование ограничения выполняемой работы на
этапах, меняет поведение системы с «выталкиваемой» на «вытягиваемую»,
т.е. такую, в которой новые задачи начинают выполняться лишь в том
случае, когда существующая работа завершена или что не менее редко –
отклонена.
70
Выполнение слишком многих частично выполненных задач приводит к
более продолжительному выполнению задач, расточительной трате ресурсов
на многочисленные переключения между существующими задачами.
Наблюдая, ограничивая и в последующем оптимизируя количество
выполняемой работы приводит к улучшению времени выполнения задач и
качества выполнения задач.
Добавить информацию о блокированных задачах – добавить ведение
информации о заблокированных задачах.
Вести отдельный учет времени выполнения этапа, время ожидания
этапа и время работы над этапом (lead time, queue time и cycle time)
Маркировка блокирующих задач
«Вытягивающие» системы часто выделяют заблокированные задачи
для того, чтобы отобразить, что задача не может быть выполнена.
Заблокированные задачи отличаются от тех, которые находятся в очередях,
ожидая, когда они будут взяты в процесс выполнения проекта тем, что
ожидают как правило события из внешней подсистемы.
Отслеживание показателя заблокированных задач является может
оказать значительную помощь в принятии решений над проектом, в поиске
путей улучшения работы над проектом.
Учет времени доставки (Lead Time) и времени цикла (Cycle Time)
задачи
Время доставки и время цикла – две полезных метрики, для понимания
того, как долго задачи выполняются в проекте. Несмотря на то, что эти
метрики достаточно похожи, они имеют значительное отличие. Обе эти
метрики позволяют понять, как долго работа проходила через систему, с той
лишь разницей, что измеряют различные этапы выполнения работы. Время

Смотрите также:

"Автоматизация обработки заявок ООО "Проектно-Строительная Компания"
"Автоматизация процесса аттестации персонала для ООО "Нэт Бай Нэт Холдинг"
"Анализ интернет-активности конкурентов ( на примере конкурентов "Газпром нефть")
"Бухгалтерский учёт и аудит расчётов с подотчётними лицами в организации на примере ООО "ЛОЦ 10""
«Психологическое сопровождение персонала в организации на примере ООО «Крокус»
Cовершенствование деловой оценки персонала в организации (на примере ООО "Даймонд кейтеринг развитие")
PR как средство продвижения организации (на примере ПАО "Тамбовский завод "Комсомолец им. Н.С. Артемова")
PR-коммуникации в сфере общественного питания (на примере кафе-кондитерской «Cream Cheese»)
SMM как средство повышения эффективности работы учреждений социокультурной сферы (на примере Малого театра)
Value-based education: ценности в системе образования и способы их реализации на уроке английского языка. Опыт Европейских стран