71
доставки (lead time) рассчитывается с учетом времени нахождения в очередях
ожидания, в то время как время цикла не учитывает это время. Отслеживание
этих двух показателей в течении времени позволяет оценить изменения и
выполнить прогнозирование эффективности предстоящей работы.
Анализ пропускной способности потока выполнения задач
Пропускной способностью системы является среднее количество задач,
выполняемое за единицу времени. В качестве примера можно привести такие
метрики как: «количество выполненных задач в день», «выполненные задачи
за неделю» или «количество выполненных задач за итерацию».
Т.к. разработка программного обеспечения решает проблемы, решения
которых носят слабоструктурированный характер, как мы уже увидели это
ранее, то на результат выполнения проекта может влиять множество
факторов, которые сложно поддаются оценке в момент планирования
проекта.
Отслеживание пропускной способности системы позволяет
своевременно выявить отклонения в скорости выполнения и своевременно
принять меры по устранению негативных факторов, влияющих на
выполнение проекта.
Для более надёжной оценки с использованием анализа пропускной
способности системы следуем комбинировать данную метрику совместно с
анализом времени доставки (lead time) и временем цикла выполнения задачи
(cycle time).
Мониторинг данной метрики позволяет также выполнять
краткосрочные прогнозы по выполнению задач проекта.
72
Рисунок 18 Прогнозирование выполнения проекта
На рисунке выше представлен прогноз выполнения задач проекта.
Голубая линия показывает прогноз выполнения в случае, если пропускная
способность проекта не претерпит изменений. Зелёная линия показывает
выполнение проекта при увеличении пропускной способности системы на
одну задачу с 26 декабря. Жёлтая линия показывает прогноз выполнения
задачи при увеличении пропускной способности системы на три задачи с
первого января 2018 года.
В текущем параграфе мы рассмотрели мероприятия, выполнение
которых может повысить эффективность процессов принятия решений
проектного управления. Рассмотрели применение таких мероприятий как:
создание очередей ожидания выполняемых работ, ограничение объёма работ
на этап выполнения работ, учет блокированных задач, учет времени доставки
задачи и времени цикла задачи, а также анализ пропускной способности
потока выполнения задач.
73
В следующем параграфе будет выполнена оценка эффективности
предлагаемых мероприятий.
3.2. Оценка эффективности предлагаемых мероприятий
В потоковых системах, которые не стремятся к изменениям и в
которых все выбранные задачи будут доставлены, существует простая связь
между средним значением работы в процессе выполнения (WiP) и временем
доставки задачи (Lead Time). Данное отношение известно, как закон Литтла
(2).
(2)
где надстрочечная линия определяет арифметическое среднее
величины.
В теории массового обслуживания, разделе теории вероятностей,
законом Литтла (англ. Little's law, также результатом, леммой, формулой
Литтла[21]) называют сформулированную американским учёным Джоном
Литтлом теорему:
Долгосрочное среднее количество L заявок в стационарной системе
равно долгосрочной средней интенсивности λ входного потока, умноженной
на среднее время W пребывания заявки в системе. Алгебраически, L = λW.
Иными словами, при заданной интенсивности входного потока время в
системе пропорционально количеству заявок в системе. Хотя результат и
выглядит интуитивно понятным, он замечателен, так как выраженная связь
не опосредована распределением поступления, распределением
обслуживания, порядком обслуживания или другими посторонними
характеристиками.
74
Закон применим к любым системам, в частности, к подсистемам.
Например, очередь клиентов в банке может быть одной подсистемой, а
каждый из кассиров — другой. Закон Литтла применим как к каждой из
подсистем, так и ко всей системе в целом. От системы требуется лишь
стационарность и отсутствие вытесняющей многозадачности. Наличие этих
свойств исключает переходные состояния, в том числе запуск и остановку.
Ниже показана диаграмма отображающая применимость закона Литтла
к исследуемым данным.
Рисунок 19 Применимость закона Литтла к исследуемым данным
На рисунке выше мы выполнили аппроксимацию данных по задачам
находящимся в состоянии «Новая», представленных голубой линией и в
75
состоянии «Закрыта», представленных серой линией. И выполнили
исследование двух временных отрезков.
Первый временной отрезок представлен красной горизонтальной
линией на диаграмме, начинается на 13 неделе 2017 года и заканчивается 34
неделей 2017 года. За данный период времени было реализовано 41 задача –
отображены вертикальной красной линией . Средний темп доставки составил
1,863 задачи/неделя. Время доставки задачи до заказчика (customer lead time)
– 22 недели.
Второй временной отрезок представлен зелёной горизонтальной
линией на диаграмме, начинается на 30 неделе 2017 года и заканчивается 2
неделей 2018 года. За данный период времени было реализовано 46 задач –
отображены вертикальной зелёной линией . Средний темп доставки составил
1,84 задачи/неделя. Время доставки задачи до заказчика (customer lead time) –
26 недели.
Таким образом, по представленной диаграмме можно сделать вывод о
том, что с течением времени происходят изменения времени доставки задачи
до заказчика в большую сторону – 22 недели в перевом анализируем отрезке
времени, против 26 недель во втором. Дельта среднего темпа доставки не
выходит за границы погрешности, в первом случае 1,863 зад./нед., против
1,84 зад./нед. во втором, что согласуется с законом Литтла применительно к
потоковым системам.
Теперь, давайте выполним моделироваание гипотетической ситуации,
если бы рекомендуемые мероприятия по оптимизации проекта были бы
применены к существующим данным.
Диаграмма ниже представляет данные модифицированные с учётом
части рекомендуемых мероприятий. В частности, было уменьшено
количество задач находящихся на этапах «Новая» и «Инспекция».
76
Рисунок 20 Анализ данных модифицированных с учётом рекомендаций
Итак, голубая и серая прямые линии представляют
аппроксимированное значение количества задач находящихся в состоянии
«Новая» и «Закрыта». Красная горизонтальная линия показывает время
доставки задачи (customer lead time), теперь значение этого показателя
составляет всего 12 недель и это практически в два раза выше, чем при
анализе не оптимизированных данных. Количество задач в работе теперь
составляет 22 и гипотетически это должно привести к более быстрому
выполнению существующих задач, т.к. уменьшает время на переключение
контекста у исполнителя задачи. Впрочем, текущая диаграмма этих
изменений, естественно не отражает, так как основана на существующих
данных, в которых количество задач в работе фактически было больше. Темп
77
доставки (delivery rate) остался таким же, каким и был и равен теперь 1,83
зад./нед.
Таким образом, даже выполнение лишь части рекомендаций, в
частности таких как: выделение очередей и ограничение задач в работе
существенно повышает время доставки задач (customer lead time), что
благоприятно влияет как на возможность внесения изменений во время
выполнения проекта, так и на большее удовлетворение заказчика. Ранняя
доставка реализованной задачи до производственной среды позволяет
раньше понять эффективнсть того или иного решения и выбрать нужное, в
сроки требуемые текущей рыночной ситуацией.
В текущем параграфе мы рассмотрели закон Литтла, который
позволяет определить время доставки в системах не стремящихся к
изменениям. Показали применимость закона к исследуемым данным.
Смоделировали модификацию данных с учетом выполнения предлагаемых
решений и выполнили сравнение с фактически полученными результами.
Полученные результаты позволяет утверждать, что выполнение
рекомендованных мероприятий позволит увеличить скорость доставки
выполненных задач при сохранении темпа доставки задач.
78
ЗАКЛЮЧЕНИЕ
Цель и задачи исследовательской работы выполнены. В
исследовательской работе требовалось выполнить определение методов
оптимизации принятия решения в управлении проектами.
Рассмотрены основные понятия и определения проектного управления.
Выяснено, что проблемы классифицируются на стандартные, хорошо
структурированные, слабоструктурированные и неструктурированные.
Классифицированы проблемы, решаемые проектами, связанные с
разработкой программного обеспечения, как слабоструктурированные.
Установлено, что использование классического подхода к работе над
проектами по разработке программного обеспечения зачастую не подходит,
т.к. требует детальной декомпозиции на этапе планирования, что в случае
решения слабоструктурированных проблем невозможно.
В исследовательской работе была рассмотрена структура базы
исследования, схема информационных центров предприятия, а также схема
одного выделенного информационного центра в г. Набережные Челны, где и
выполнялась исследовательская работа. Определены факторы, относящиеся к
компонентам внешней и внутренней среды предприятия.
Во второй главе был выполнен анализ методов управления проектами в
деятельности ООО «Такстелеком».
Описаны применяемые методы управления IT-проектами
осуществляемые в пределах информационных центров объекта
исследования. Рассказаны преимущества гибких методологий управления IT-
проектами. Проведён анализ годовой накопительной диаграммы, обозначены
места требующие внимания. Проведённые исследования позволяют сделать
вывод о том, что в процесс разработки программного обеспечения могут
79
быть внесены изменения, способствующие более эффективному выполнению
задач.
В третьей главе исследовательской работы представлен комплекс
мероприятий, позволяющий выполнить совершенствование системы
управления проектами ООО «Такстелеком». В частности, были предложены
такие мероприятия как: создание очередей для задач, ограничение работ на
этапах процесса, маркировка блокирующих задач, учёт времени доставки и
времени цикла задач, а также анализ пропускной способности потока
выполнения задач.
Была выполнена оценка прогнозируемых изменений, на основе
существующих данных, при этом полученные расчёты показали, что
предложенные мероприятия являются экономически эффективными, поэтому
их можно рекомендовать к реализации.
80
СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ
1. Алешин А.В. [и др.]. Управление проектами: фундаментальный курс / А.В.
Алешин, В.М. Аньшин, К.А. Багратиони, В.Д. Барханов, С.С. Васильева [и
др.]., Нац. исслед. ун-т. «Высшая школа экономики», 2013. 620 c.
2. Вигерс К., Битти Д. Разработка требований к программному обеспечению /
К. Вигерс, Д. Битти, Microsoft Press, 2015. 736 c.
3. Гавренкова В.И., Гудин Ю.Г. Управление персоналом (Учебное пособие)
[Электронный ресурс]. URL:
https://abc.vvsu.ru/books/upravlenie_pers/page0004.asp (дата обращения:
11.10.2017).
4. Дафт Р.Л. Менеджмент / Р.Л. Дафт, Спб: Питер, 2003. 832 c.
5. Игнатишин Ю.В. Слияния и поглощения: стратегия, тактика, финансы /
Ю.В. Игнатишин, Спб: Питер, 2005. 201 c.
6. Любушин Н.П. Экономический анализ / Любушин Н.П., М.: ЮНИТИ-
ДАНА, 2010. 574 c.
7. Никонова И.А. Проектный анализ и проектное финансирование / И.А.
Никонова, М.: Альпина Паблишер, 2017. 153 c.
8. Уланова О.И. Микроэкономика / Уланова О.И., Пенза: РИО ПГСХА, 2014.
178 c.
9. Уолкер-младший О. Маркетинговая стратегия. Курс МВА / Уолкер-
младший О., М.: Вершина, 2006.
10. Фролова Т.А. Макроэкономика: конспект лекций Таганрог: ТРТУ, 2006.