|
пркт123. Тем не менее, несмотря на широкое распространение и наличие обширного инструментария, направленного на успешное достижение целей проекта, данная область знаний достаточно молода и нуждается в тщательном изучении
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Группа компаний Экстрим с 1994 профессионально и качественно занимается заказной разработкой ПО, является крупным уральским интегратором. Проекты компании преимущественно в государственном секторе, носят социально-значимый характер и приносят реальную пользу людям [17]. Направления деятельности компании: • Разработка и внедрение информационных систем, программных решений. • Проектирование ИТ-инфраструктуры и организация работ по защите информации. Группа компаний Экстрим является партнером всех ведущих производителей средств защиты информации в России. Группа компаний специализируется на автоматизации деятельности в сферах: жилищнокоммунального хозяйства и учета услуг, транспортной сферы, архивной деятельности, бюджетно-финансовой деятельности и др. Все реализованные продукты социально значимы и приносят реальную пользу людям, например, ГИС, ЖКХ, монетизация льгот ЖКХ, система по предоставлению субсидий на оплату жилья, социально-транспортная карта, АИС питания школьников, технологическое присоединение и другие. Система ГИС ЖКХ является основной средой сбора и обмена информацией в сфере ЖКХ в России. Для контроля за деятельностью организаций, работающих в сфере ЖКХ, созданы специальные государственные и муниципальные инспекции, которые работают на портале ГИС ЖКХ. Жители домов могут направить в такую инспекцию жалобу, по результатам рассмотрения которых могут быть назначены проверки и вынесены предписания по устранению нарушений. Компания разработала несколько подсистем ГИС ЖКХ, благодаря которым: • В реестре проверок подсистемы «Инспектирование» открытой части ГИС ЖКХ можно узнать о планируемых и совершенных в отношении вашей управляющей организации проверках и их результатах, а в в реестре административных правонарушений – о назначенных штрафах и других наказаниях. • Автоматически контролируются сроки запланированной проверки, субъекту и проверяющему направляются оповещения о предстоящей проверке, что помогает планировать и организовывать работу. • Информация о проверке в подсистеме позволяет найти контролирующий орган, связаться с ним, уточнить интересующие вопросы. 24 • Посмотреть программы и планы капитального ремонта. В 2012 году компания разработала систему «АИС Питание». Система является связующим звеном, которое объединяет всех участников процесса: от учеников и их родителей, школы, организаций питания, до банков и Департамента финансов Администрации г. Екатеринбурга. Прежний документооборот полностью заменен на полностью юридически значимый электронный (с применением электронных подписей). Теперь схема школьного питания улучшена и позволяет: • Вести электронный реестр учеников. • Ставить ученика на питание при входе в школу. • Посмотреть личный кабинет, где можно проконтролировать меню, установить лимиты на питание, посмотреть историю операций и другое. • Оплачивать за те дни, когда ученик ходил в школу и обедал. Компанией была создана система «Техприсоединение», упрощающая подключение к сетям на уровне региона. Система объединяет на одной интернет-площадке всех участников процесса: от рядовых граждан, до крупных сетевых компаний и органов государственной власти. Среди основных возможностей системы: • Возможность посмотреть на интерактивной карте электросети, подстанции, тэц, зоны тепло- и водоснабжения, узнать каким организациям они принадлежат, а также степень их загрузки на сегодня. Карта поможет выбрать организацию, в которую нужно подать заявку на подключение, а также оценить – удобно ли выбрано место для строительства подключаемого объекта. • Возможность подать заявку на подключение online и отслеживать ее исполнение. Весь документооборот можно осуществлять в электронной форме без единого визита в сетевую организацию. • Возможность согласовать прокладку новых сетей и других объектов параллельно со всеми нужными организациями, ускоряя процесс подключения в разы. В рамках консалтингового направления деятельности Группой компаний «Экстрим» были реализованы проекты для крупных государственных и частных заказчиков. Целью реализованных проектов являлся комплексный анализ IT-инфраструктуры клиентов, определение ключевых направлений развития и наиболее оптимальных способов достижения целей, стоящих перед клиентами. ГК «Экстрим» тесно сотрудничает со следующими российскими компаниями: • Системный интегратор КРОК. • Группа компаний Ланит. 25 • телекоммуникационная компания Ростелеком. • компания Инфотекс. Среди клиентов компании: • Администрация города Екатеринбурга. • УВД г. Екатеринбурга. • Центральный Банк РФ (Банк России). • Отделение Пенсионного фонда Российской Федерации по Свердловской области. • Федеральная таможенная служба России. • Правительство Свердловской области. • Коммерческие банки Уральского региона. Компания достаточно большая и имеет 11 отделов. Схема организационной структура компании представлена на рисунке 2.1. Рисунок 2.1 – Организационная структура компании Организационная структура ГК Экстрим построена по линейно-функциональному принципу. В данной структуре специалисты одного профиля объединены в специализированные структурные подразделения, при этом управление осуществляется как линейными, так и функциональными руководителями. К недостаткам такой структуры относится увеличение время принятия решений из-за необходимости согласования с руководителями. Руководство текущей деятельностью компании осуществляется единоличным органом – Генеральным директором. Чаще всего генеральный директор взаимодействует с руководителями отдела системного и бизнес-анализа, отделов разработки и руководителями проектов. В процессе разработки проектов активно участвуют руководители проектов, отделы системного и бизнес-анализа, разработки, тестирования и документирования. Остальные отделы участвуют косвенно или не участвуют в разработке программного обеспечения. 26 2.2 Оценка финансовой устойчивости фирмы Финансовый анализ предназначен для оценки результатов финансовой деятельности предприятия, определения финансового состояния предприятия, выявления сильных и слабых его сторон, выработки действий, которые бы дали возможность использовать имеющиеся преимущества и исправить возникшие трудности. Бухгалтерский баланс компании необходим для расчета финансовой устойчивости, который представлен в таблице 2.1. Таблица 2.1 – Расчет финансовой устойчивости компании № Показатель 2018 2019 2020 1 2 3 5 6 1 Собственный капитал предприятия, руб 38400000 33750000 37370000 2 Заемный капитал предприятия, руб 20840000 14630000 13330000 3 Общая величина капитала, руб 59240000 64640000 50700000 4 Коэффициент автономии 0,648211 0,522123 0,737081 5 Коэффициент финансовой зависимости 0,351789 0,477877 0,262919 6 Абсолютно ликвидные активы, руб 634000 1824000 6702000 7 Наиболее срочные обязательства, руб 4730000 20000000 4030000 8 Коэффициент абсолютной ликвидности 0,030422 0,124675 0,502776 9 Коэффициент критической ликвидности 11,92003 3,140745 1,653998 10 Общая величина текущих активов, руб 59240000 64640000 50700000 11 Общая величина текущих пассивов, руб 59240000 64640000 50700000 12 Коэффициент текущей ликвидности 2,84261 4,418319 3,803451 13 Собственный оборотный капитал, руб 37066000 29989000 42692000 27 Продолжение таблицы 2.1 1 2 3 4 5 14 Коэффициент обеспеченности предприятия собственным оборотным капиталом 0,663144 0,756404 0,667059 По данным таблицы 2.1 можно проследить, что заемный капитал уменьшается на протяжении нескольких лет. Коэффициент автономии увеличился по сравнению с 2018 годом, это значит, что у компании увеличились собственные источники финансирования. Коэффициент абсолютной ликвидности за несколько лет увеличился и находится выше нормы 0,5>0,2, это значит, что компания способна расплачиваться по краткосрочным обязательствам. Коэффициент текущей ликвидности в 2019 году вырос по сравнению с годом ранее, но в 2020 году снизился, но оказался выше чем в 2018 году. На протяжении последних трех лет коэффициент текущей ликвидности находится выше нормы 3,8>2,5. Коэффициент обеспеченности собственным средствами составляет 0,6, это значит, что структура баланса компании считается удовлетворительной и компания платежеспособна. 2.3 Анализ структуры и состава персонала В группе компаний Экстрим работают более 150 сотрудников. Сотрудники имеют возможность работать из двух офисов компании – в Екатеринбурге и Севастополе, также значительная часть сотрудников работают удаленно из других городов Российский Федерации. На рисунке 2.2 приведено соотношение мужчин и женщин, работающих в компании. Рисунок 2.2 – Соотношение мужчин и женщин 61% 39% Мужчины Женщины 28 По рисунку видно, что большая часть составляют мужчины. Это связано с тем, что в сферу IT преимущественно идут представители мужского пола. На рисунке 2.3 представлено соотношение по возрастам среди сотрудников компании. Рисунок 2.3 – Соотношение возрастов среди сотрудников По рисунку видно, что большую часть сотрудников составляют люди в возрасте от 20 до 40 лет. Сотрудники в возрасте от 41 до 50 лет составляют наименьшую часть в диаграмме. В компании активно привлекают студентов высших учебных заведений, поэтому видно достаточно большое соотношение сотрудников от 20 до 30 лет. Структура персонала по уровню образования показана в таблице 2.2. Таблица 2.2 – Структура персонала по уровню образования Показатель Численность, чел Удельный вес, % 2018 2019 2020 2021 2018 2019 2020 2021 1 2 3 4 5 6 7 8 9 Среднее 29 24 15 12 17% 14% 10% 8% Незаконченное высшее 10 2 1 2 6% 1% 1% 1% Высшее 135 140 139 144 78% 84% 90% 91% Всего 174 166 155 158 100% 100% 100% 100% По таблице 2.2 можно увидеть, что на протяжении четырех лет наибольшую долю занимают сотрудники с высшим образованием. На рисунках 2.4, 2.5, 2.6, 2.7, представлены диаграммы, показывающие процентное соотношение по образованию сотрудников по годам в соответствии таблице 2.2. 46% 48% 6% 0% 10% 20% 30% 40% 50% 60% от 20 до 30 лет от 31 до 40 лет от 41 до 50 лет 29 Рисунок 2.4 - Структура персонала по уровню образования за 2018 год Рисунок 2.5 - Структура персонала по уровню образования за 2019 год 17% 6% 77% Среднее Незаконченное высшее Высшее 15% 1% 84% Среднее Незаконченное высшее Высшее 30 Рисунок 2.6 - Структура персонала по уровню образования за 2020 год Рисунок 2.7 – Структура персонала по уровню образования на апрель 2021 года Проследив диаграммы на рисунках 2.4, 2.5, 2.6, 2.7, можно заметить, что на протяжении от 2018 года к 2021 растет число сотрудников с высшим образованием. На диаграмме за 2018 год показана диаграмма с достаточной долей сотрудников со средним специальным образованием, это связано с открытием службы технической поддержки и набором сотрудников в данную службу. Также на рисунке 2.4 заметна доля сотрудников с неоконченным высшим образованием, в данную категорию входят студенты последних курсов университетов, которые проходят оплачиваемую стажировку в компании. 10% 1% 89% Среднее Незаконченное высшее Высшее 8% 1% 91% Среднее специальное Незаконченное высшее Высшее 31 По рисунку 2.7 видно, что более чем 90% сотрудников имеют высшее образование, что обозначает квалифицированных специалистов. Наименьшая доля сотрудников имеют незаконченное высшее, так как в данное соотношения входят работающие студенты. Также была собрана информация по профильному образованию среди сотрудников организации. Рисунок 2.8 – Соотношение профильного и непрофильного образований По рисунку 2.8 видно, что больше половины сотрудников имеют профильное образование, связанное с информационными технологиями. Остальные 42% имеют непрофильное образование. В данное число входят сотрудники из администрации, отдела персонала, службы поддержки и некоторое количество специалистов. 2.4 Описание отдела системного и бизнес анализа Для представления информации об отделе сначала была собрана информация про каждого сотрудника отдела системного и бизнес анализа, собиралась следующая информация: пол, возраст, образование, должность, опыт работы в данной компании. В отдел системного и бизнес-анализа входит 18 сотрудников, из них: • 1 сотрудник – начальник отдела. • 5 сотрудников – ведущие аналитики. • 12 сотрудников – аналитики. Схема организационной структуры отдела представлена на рисунке 2.9. 58% 42% Профильное образование Непровильное образование 32 Рисунок 2.9 – Организационная структура отдела системного и бизнес-анализа На рисунке 2.9 представлена организационная структура отдела системного и бизнесанализа, по схеме видно, что руководитель отдела взаимодействует с ведущим аналитиком, а также напрямую с рядовым аналитиком. Руководитель отдела занимается организацией работы и направлений деятельности отдела, участвует в проектах в качестве ведущего аналитика, взаимодействует с ключевыми пользователями, анализирует и описывает бизнес-процессы, проводит аудит проектов, согласование сроков реализации по проектам. Ведущие аналитики собирают и формализируют требования, оценивают трудоемкости разработки постановки задачи, анализируют требования и прорабатывают концепцию реализации функционала, согласовывают концепции внутри команды и с заказчиком, пишут постановки и координируют других аналитиков, проводят проверки (ревью) написанных ими постановок, сопровождают процессы разработки и тестирования, консультируют команду по функционалу, вносят уточнения и изменения в требования, демонстрируют функции заказчику, проводят обучения по использованию системы. Аналитики собирают и проводят анализ требований консультируют команду по функционалу, сопровождают процессы разработки и тестирования, пишут постановки, вносят уточнения и изменения в требования. 33 Таблица 2.3– Функциональные обязанности отдела системного и бизнес-анализа Должность Функциональные обязанности 1 2 Руководитель отдела системного и бизнес анализа • Организация работы команды системного анализа в рамках подразделения; • Участие в формировании технического задания на разработку; • Участие в разработке интеграционных решений в рамках задач развития; • Планирование деятельности сотрудников в рамках поставленных задач; • Мотивация сотрудников на профессиональное развитие; • Планирование задач и проектов, оценка сроков и трудоемкости выполнения работ; • Качественное распределение проектов между сотрудниками; • Личное участие в значимых проектах / пресейлах в роли ведущего аналитика (личное выполнение аналитических задач в объеме 30-40% от рабочего времени. 34 Продолжение таблицы 2.3 1 2 Ведущий аналитик • Сбор и формализация требований, оценка трудоемкости разработки постановки задачи; • Анализ требований и проработка концепции реализации функционала. Согласование концепций внутри команды и с заказчиком; • Координация других аналитиков на проекте; • Написание постановок на реализацию функционала – как самостоятельно, так и путем координации работы других аналитиков. Проведение ревью написанных ими постановок; • Ведение технической документации в Confluence; • Сопровождение процессов разработки и тестирования – презентация требований команде разработки, ответы на вопросы, при необходимости внесение уточнений и изменений в требования; • Авторский надзор – приемка реализованного функционала; • Демонстрация функционала Заказчику; • Проведение обучения по использованию системы. Аналитик • Сбор, обобщение, анализ информации; • Разработка и поддержание в актуальном состоянии проектной документации. • Анализ требований и проработка концепции реализации функционала; • Написание постановок на реализацию функционала; • Сопровождение процессов разработки и тестирования; • Презентация требований команде разработки, ответы на вопросы, при необходимости внесение уточнений и изменений в требования; В таблице Таблица 2.4 представлена информация по сотрудникам, где была собрана информация по возрасту, опыту работы в компании, образованию, зарплате. Образование было выбрано как профильное/непрофильное, где профильное образование связано с 35 информационными технологиями, непрофильное – не связано.Таблица 2.4 – Данные по сотрудникам № Должность Пол Возраст Работа в компании, лет Образование Зарплата 1 2 3 4 5 6 7 1 Начальник отдела м 35 14 Профильное 95000 2 Ведущий аналитик ж 32 6 Профильное 80 000 3 Ведущий аналитик ж 30 5 Профильное 80 000 4 Аналитик ж 32 5 Непрофильное 55000 5 Аналитик ж 29 4 Профильное 55000 6 Аналитик ж 29 4 Профильное 55000 7 Аналитик м 31 5 Профильное 60000 8 Аналитик ж 32 5 Профильное 55000 9 Ведущий аналитик ж 33 3 Профильное 80 000 10 Аналитик м 27 4 Профильное 50000 11 Аналитик ж 24 2 Профильное 45000 12 Аналитик ж 27 3 Профильное 50000 13 Аналитик ж 38 8 Профильное 50000 14 Аналитик ж 22 1,5 Непрофильное 45000 15 Аналитик ж 24 1,5 Непрофильное 45000 16 Аналитик ж 24 3 Профильное 45000 17 Ведущий аналитик м 26 1 Профильное 80 000 18 Ведущий аналитик ж 34 1 Профильное 70 000 По таблице видно, что большая часть сотрудников имеют профильное образование, а также средний опыт работы в компании составляет 4,2 года. В отделе системного и бизнес-анализа 1 начальник отдела и 17 аналитиков. На данный момент существует 10 проектов, в которых участвуют аналитики. Один аналитик может участвовать одновременно в нескольких проектах. Возникают сложности в оценке работы по эффективности каждого аналитика, так как в отделе отсутствуют показатели эффективности, по которым можно отследить степень достижения цели и аналитик занят на нескольких проектах. 36 Рисунок 2.10 – Соотношение мужчин и женщин в отделе системного и бизнес-анализа В компании отсутствует материальная система мотивации сотрудников, которая может повлиять на производительность труда, увеличить качество выполненной работы, сориентировать на достижение результатов в указанные сроки. У сотрудников компании имеется оклад без квартальных премий, бонусов. Вознаграждение премией осуществляется раз в год. Размер премии определяется руководителем отдела. Также каждый год пересматривается заработная плата у сотрудников. На рисунке 2.11 представлена диаграмма зарплат сотрудников отдела. Рисунок 2.11 – Диаграмма зарплат сотрудников отдела системного и бизнес-анализа По рисунку 2.11 средняя заработная плата составляет чуть больше 61000 рублей. На рисунке 2.13 представлена диаграмма взаимодействия аналитиков на одном проекте. На рисунке 0 2 4 6 8 10 12 14 16 Количество Мужчины Женщины 0 20000 40000 60000 80000 100000 120000 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 Зарплата, руб. 37 видно, что исполнителем задачи является рядовой аналитик, а ведущий аналитик является проверяющим. Рисунок 2.12 - Диаграмма взаимодействия между аналитиками на одном проекте Данная диаграмма может работать и другим образом – ведущий аналитик может поручить рядовому аналитику проверять задачу, так как при проверке задачи другим лицом можно увидеть недочеты или ошибки. Такая последовательность действий как «Отправка задачи на проверку – проверка задачи - отправка замечаний по задаче – исправление решения задачи» может проходить в несколько итераций пока не будут исправлены все замечания. 2.5 Описание жизненного цикла проекта или функционала В каждом проекте участвует несколько сотрудников из отделов системного и бизнесанализа, разработки, тестирования и документирования. Схема взаимодействия участников команды на проекте представлена на рисунке 2.13. 38 Рисунок 2.13 – Взаимодействие участников команды на проекте На рисунке 2.13 отображен способ взаимодействия между группами. Каждая группа может взаимодействовать с другой группой как напрямую, так и через смежную группу. Например, при выявлении аналитиком ошибок в функционале, допущенных группой разработки, происходит обращение в группу тестирования. Далее группа тестирования проверяет ошибку и создает задачу на исправление группой разработки данной ошибки. Если необходимо уточнить что-либо, то группы взаимодействуют напрямую. На рисунке 2.14 представлена диаграмма последовательности взаимодействия между группами на одном проекте при реализации функционала. Действия, выделенные пунктирной линией, происходят не всегда. 39 Рисунок 2.14 – Диаграмма последовательности взаимодействия между группами По рисунку видно, весь процесс происходит за 18 действий, если не учитывать возможные действия, указанные пунктирной линией, то процесс происходит за 7 действий (действия №1, 2, 3, 8, 9, 17, 18). 40 Таблица 2.5 – Описание документов, необходимых при выпуске проекта № Название документа Описание документа Исполнитель Длительность выполнения 1 2 3 4 5 1 Техническое задание Документ, содержащий информацию для постановки задач исполнителям на разработку проекта Группа аналитики 8 дней 2 Программа и методика испытаний Документ предназначен для проверки реализуемого функционала. В документе указывается порядок испытаний и конечный результат действия. Группа аналитики 5 дней 3 Протокол проведения испытаний Документ, содержащий результаты испытаний, которые описаны в программе и методике испытаний Группа аналитики 2 дня 4 Постановка Документ, описывающий проект Группа аналитики В зависимости от объема проекта 5 Руководство пользователя Документ-инструкция, описывающий использование разработанной системы Тестирование 5 дней В таблице 2.5 представлена совокупность документов необходимы при выпуске проекта. По умолчанию принято, что техническое задание готовит исполнитель, а не заказчик. Связано с тем, чтобы прописать четкие обозначенные требования вместо общего описания будущего проекта. Из таблицы видно, что основную часть документов готовит группа аналитики. 41 Незначительную часть – группа тестирования. При этом группа разработки не участвует в создании необходимых документов, так как группа создает программное обеспечение. В столбце «Длительность разработки» указано среднее время в рабочих днях. Цикл разработки любого проекта состоит из шести основных этапов, наглядно цикл представлен на рисунке 2.15. Данный цикл не изменен и подходит как для разработки абсолютно нового проекта, так и для отдельного функционала в проекте [18]. Основные этапы разработки: 1. Планирование. 2. Анализ. 3. Дизайн. 4. Разработки, внедрение и развертывание. 5. Опытная эксплуатация и интеграция. 6. Поддержка системы. Рисунок 2.15 – Жизненный цикл разработки Этапы разработки можно выделить три роли – аналитика, разработка, тестирование. В каждом этапе цикла разработки принимает участие аналитик. На этапе планирования аналитик определяет проблемы и возможные их решения. На этапе анализа аналитик определяет требования конечного пользователя, а также делается технико-экономическое обоснование. На следующем этапе – дизайна, аналитик определяет элементы системы, дизайн. На четвертом этапе пишется код, который создает разработка, на данном этапе аналитик принимает участие в разработке в качестве консультанта. На этапе эксплуатации и интеграции тестирование проверяет функционал, аналитик может принимать участие также в качестве консультанта. На 42 последнем этапе аналитиком ведется мониторинг по работоспособности реализованного функционала и поддержание его работы. Все этапы жизненного цикла проекта или функционала проходят последовательно. Начинает жизненный цикл аналитика, после того как требования определены и описаны в постановке, задача переходит к разработке, после создания функционала происходит его тестирование. 2.6 Описание проблем, возникающих в ходе разработки проекта или функционала В ходе движения по жизненному циклу разработки аналитику приходится решать многие задачи. Перечень задач взят на основе анализа проекта «Региональный портал по технологическому присоединению к электрическим сетям, сетям газораспределения, к системам теплоснабжения, к централизованным системам водоснабжения и водоотведения, расположенным на территории Свердловской области» (Портал). Данный проект активно развивается с 2017 года и представляет собой электронную площадку технологического присоединения, призванная оптимизировать и автоматизировать бизнес-процессы технологического присоединения для всех его участников. Портал находится в стадии поддержки, благодаря которой происходит разработка и внедрение нового функционала в систему. В стадии разработки и внедрения могут возникать следующие задачи у аналитиков: • Постановка задачи (из технического задания или решение проблемы заказчика). • Сбор и формирование бизнес-требований. • Анализ требований. • Описание объекта разработки, редактирование страниц с описанием объекта разработки. • Правки макетов. • Написание постановок разработчикам. • Консультирование по описанному функционалу. • Правки страниц с описанием объекта по замечаниям команды. Рассмотрим решаемые задачи при внедрении нового функционала для Портала. Весь цикл разработки функционала проходил в период с сентября по декабрь 2020 года. В таблице 2.6 на примере реализованного функционала указаны этапы, которые возникали при внедрении функционала, отображено затраченное время на этап, а также оценен каждый этап. 43 Таблица 2.6 – Перечень этапов при внедрении нового функционала № ЭТАПЫ Рабочее время в часах сц - создание ценности, п - потери 1 2 3 4 1 Руководитель объясняет задачу Ведущему аналитику 0,25 п 2 Ведущий аналитик объясняет задачу Аналитикам 0,5 п 3 Ведущий аналитик обсуждает с Аналитиками общий порядок работ 2 п 4 Создание макетов главной страницы модуля 10 сц1 5 Обсуждение с ведущим аналитиком макетов 1 п 6 Правки макетов, подготовка к показу для команды 1,5 сц1 7 Показ макетов и выбор конечного варианта 1 п 8 Аналитики перечисляют конкретный функционал (страницы с постановками), который нужно поправить 3,5 п 9 Составление карты функционала, который нужно изменить в рамках одного пункта 15 сц1 10 Редакция постановок по функционалу 25 сц1 11 Демо аналитика (показ функционала команде), вопросы от команды 1,25 п 12 Подведение итогов по демо аналитике 1 сц2 13 Исправление постановок после демо 12 сц2 14 Обсуждение дальнейшей работы по функционалу 1 п 15 Исправление постановок по замечаниям 2 сц2 16 Обсуждение исправлений по замечаниям 0,25 п 17 Проверка всех постановок 6 п 18 Консультирование группы разработки 7 п 44 Продолжение таблицы 2.6 19 Слияние нового функционала со старым (мердж) 6,5 сц3 20 Ответы на вопросы от тестирования 0,25 п 21 Обсуждение вопросов 0,5 п 22 Исправление постановок из обсуждения вопросов 4 сц3 Итого 101,5 час в рабочих днях (8 часов рабочий день) 12,6875 дней В таблице перечислены этапы и затраты на этапы в часах, а также оценен этап по ценностям и потерям, где ценностью считается создание программного модуля с удобным интерфейсом на существующем платформе для помощи сотрудникам в выполнении некоторого бизнес-процесса. Создание ценности разделено на 3 этапа, где первый этап – создание функционала, второй этап – исправление по замечаниям, третий этап – небольшие исправления и перенос описанного функционала в документацию. Из таблицы видно, что в ходе разработки требований достаточно много времени тратится на обсуждение функционала и его изменение. В таблице 2.7 указано общее затраченное время на каждый этап. Таблица 2.7 – Оценка затраченного времени на этапы Процентная доля от всего затраченного времени Часы Полезность 1 2 3 50,74% 51,5 сц1 14,78% 15 сц2 10,34% 10,5 сц3 24,14% 24,5 п Из таблицы 2.7 видно, что самая большая часть времени уходит на разработку функционала. Значительная часть времени 24,14% уходит на потери в виде обсуждения задач по функционалу, что составляет почти одну четвертую от всего процесса. Возникновение потерь может быть связано с тем, что передача задач осуществляется последовательно по цепочке иерархии, тем самым тратится время на обсуждение и уточнение деталей по задаче, что влияет на сроки разработки функционала или проекта. 45 Рисунок 2.16 – Диаграмма по оценке затраченного времени На рисунке 2.16 визуально отображено соотношение по полезности этапов из таблицы 2.7. При внедрении нового функционала потери составляют 22%, что является средним, но не критичным результатом по потерям, но данное значение необходимо оптимизировать и снизить потери до 10-15%. Также была рассмотрена статистика по затраченному времени на каждую задачу. В статистике сравнивается планируемое и фактическое время, статистика представлена в таблице 2.8. В таблице указаны планируемые и фактические трудозатраты для ролей - аналитика, разработка и тестирование. В столбце План указано время, которое закладывается на реализацию задачи при планировании, в столбце Факт указано время, которое было затрачено по факту. В столбцах «Расхождение от плана по ролям» и «Общее расхождение от плана» сделан расчет по расхождению фактического времени от планируемого. Столбец «Расхождение от плана по ролям» был рассчитан по формуле 2.1: R = 100 − Aфакт ∙ 100 Aплан (2.1) где Aфакт, Aплан – часы по плану и факту соответственно. «Сумма план» и «Сумма факт» рассчитываются как сумма часов по каждой роли. Столбец «Общее расхождение» был рассчитан по формуле 2.2: Rобщее = 100 − ∑факт ∙ 100 ∑план (2.2) 78% 22% Создание ценности (СЦ) Потери (П) Таблица 2.8 – Статистика по затраченному времени на задачи Задача № План Факт Расхождение от плана по ролям Общее расхождение от плана Аналити ка, часы Разработ ка, часы Тестирова ние, часы Аналити ка, часы Разработ ка, часы Тестирова ние, часы Аналити ка, % Разработ ка, % Тестирова ние, % Сум ма План , часы Сум ма Факт , часы Общее расхожде ние, % 1 2 3 4 5 6 7 8 9 10 11 12 13 1 2 8 3 61 99 47 -2950 -1138 -1467 13 207 -1492 2 5 18 6 5,3 145,5 68,6 -6 -708 -1043 29 219 -657 3 7 24 8 17,4 11 4 -149 54 50 39 32 17 4 3 12 4 16,6 12 12 -453 0 -200 19 41 -114 5 2 8 3 61,5 19 2 -2975 -138 33 13 83 -535 6 5 16 5 33,2 19,5 9,6 -564 -22 -92 26 62 -140 7 1 5 2 2,6 6,2 3,3 -160 -24 -65 8 12 -51 8 23 80 27 20,3 150 40,3 12 -88 -49 130 211 -62 9 19 67 22 18,3 220,75 135,6 4 -229 -516 108 375 -247 10 27 94 31 6,5 11 6,5 76 88 79 152 24 84 11 82 288 96 269 55,4 121,4 -228 81 -26 466 446 4 12 27 96 32 8 88,5 61,4 70 8 -92 155 158 -2 13 11 38 13 2,2 39,5 22 80 -4 -69 62 64 -3 14 6 20 7 27,3 13,5 18 -355 33 -157 33 59 -78 15 75 262 87 0,6 308 176 99 -18 -102 424 485 -14 16 39 86 29 43,3 156,8 30,4 -11 -82 -5 154 231 -49,7 Сумма, часы 334 1122 375 593 1356 758 -78 -21 -102 1831 2707 -47,8 По таблице 2.8 видны как положительные значения так и отрицательные, где положительные значат, что планируемое время больше чем затраченное, отрицательное – затраченное время больше планируемого. Также можно рассмотреть, что большое количество значений в столбце «Общее расхождение от плана» имеет отрицательный знак. Значительное расхождение значений от плана повышает риск переносов сроков по выпуску нового функционала. На рисунке 2.17 визуально отображена сравнительная статистика по плановым и фактическим часам на каждую задачу аналитики. Рисунок 2.17 – Сравнительная статистика по затраченным часам на каждую задачу аналитики По рисунку 2.17 видно, что в большинстве задач фактическое количество, потраченное на задачу, превышает плановое. Также есть несколько задач, где запланированные часы соотносятся с фактическими или меньше их. Несоответствие плановых часов и фактических чаще всего возникает из-за: • Непроработанных задач на более ранних этапах разработки продукта. • Поверхностной проработки изменяемых страниц. 0 50 100 150 200 250 300 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Количество часов Номер задачи План Факт 48 Рисунок 2.18 – Сравнительная статистика по затраченным часам по командам Рассмотрим статистику по ролям – аналитике, разработке, тестированию, которая представлена в таблице 2.9. В таблице произведен расчет для понимания во сколько раз фактические часы превышают запланированные по каждой задаче. Для расчета воспользовались формулой 2.3: N = Aфакт Aплан (2.3) Таблица 2.9 – Статистика по ролям, показывающая превышение фактических часов от запланированных Задача № Аналитика Разработка Тестирование 1 2 3 4 1 30,5 12,4 15,7 2 1,1 8,1 11,4 3 2,5 0,5 0,5 4 5,5 1,0 3,0 5 30,8 2,4 0,7 6 6,6 1,2 1,9 Продолжение таблицы 2.9. 0 200 400 600 800 1000 1200 1400 1600 Аналитика Разработка Тестирование Количество часов План Факт 49 1 2 3 4 7 2,6 1,2 1,7 8 0,9 1,9 1,5 1 2 3 4 9 1,0 3,3 6,2 10 0,2 0,1 0,2 11 3,3 0,2 1,3 12 0,3 0,9 1,9 13 0,2 1,0 1,7 14 4,6 0,7 2,6 15 0,0 1,2 2,0 16 1,1 1,8 1,0 Среднее значение 5,7 2,4 3,3 Из таблицы 2.9. видно, самое максимальное среднее значение принадлежит аналитике, минимальное – разработке. У разработки незначительное превышение фактических часов в отличие от аналитики. У тестирования отображены средние значения между аналитикой и разработкой. Можно сделать вывод, что большинство задач недооцениваются по времени исполнения. Графическое изображение значений из таблицы 2.9 представлены на рисунке 2.19. 50 Рисунок 2.19 – График, показывающий превышение фактических часов от запланированных На рисунке 2.19 видна разница между планируемым временем и фактически затраченным. При этом разница между планом и фактом у каждой команды отличается в несколько раз, что приводит к нарушениям сроков. Любая постановка, переданная на исполнение разработке от аналитики, содержит двоякие трактовки или не до конца проанализированный функционал. В связи с этим тратится дополнительное время аналитики на изучение и исправление постановок функционала, поэтому необходимо закладывать и учитывать дополнительное время на мелкие доработки функционала после передачи в разработку. Если не закладывать дополнительное время, то сроки будут смещаться у всех ролей, так как все три роли зависят друг от друга, при превышении планируемого времени у аналитики, происходит сдвиг по срокам у разработки. При сдвиге времени у разработки, сдвигается время у тестирования. При сдвиге времени у тестирования сдвигается время релиза функционала, а затем и проекта. В случае нарушения сроков, указанных в контракте, начисляются пени за каждый день просрочки в соответствии ч.5, ч.7 ст. 34 Федерального закона №44-ФЗ, а значит уменьшается прибыль с проекта [19]. В случае, когда сроки сжаты и имеются четкие сроки сдачи, которые нарушить нельзя, а также превышено планируемое время у аналитики, то незначительно уменьшается срок у разработки, но существенно сокращается срок у тестирования, что влечет непроверенный функционал, что значит некачественный. В ходе просмотра сравнительной статистики рисунок 2.18 по затраченным часам на разработку нового функционала и таблицы 2.7 выяснились следующие проблемы: • Значительное время тратится на обсуждение и изменение функционала. 0 1 2 3 4 5 6 Аналитика Разработка Тестирование Превышение в количество раз План Факт 51 • Имеются риски по срокам. Следствия: • Недооцененное время на разработку функционала влияет на сроки реализации и качество будущего функционала. • Отсутствует дополнительное время на риски, связанные с недоработкой функционала, для исключения смещения сроков реализации. Одна из проблем – наличие рисков. В таблице 2.10 указана классификация рисков. Таблица 2.10 – Классификация рисков № Наименование риска Примечание 1 2 3 1 Неверное планирование сроков 2 Прошлые недоработки функционала препятствуют реализации нового Риски раскрываются на этапе реализации функционала В таблице 2.10 указаны два риска. Неверное планирование сроков является главным риском, так как при реализации нового функционала, наличие прошлых недоработок влияет на время реализации нового функционала, срок сдвигается на более поздний, тогда возникает просрочка, которая регламентируется в соответствии ч.5, ч.7 ст. 34 Федерального закона №44- ФЗ. В случае сжатых сроков возникают переработки По жизненному циклу функционала или проекта работа аналитики стоит на первом месте. Именно от аналитики зависит качество функционала, поэтому необходимо усовершенствовать работу аналитики и исключить риски, которые могут повлиять на роли, вступающие в работу после аналитики. Для решения данных проблем предлагается усовершенствовать проектный подход отдела системного и бизнес-анализа, для исключения смещения сроков передачи постановок в разработку. Для реализации усовершенствованного подхода планируется: • Найти решение для реализации функционала в срок. • Уменьшить потери в виде обсуждений и изменений. 52 3 РЕШЕНИЕ ДЛЯ СОВЕРШЕНСТВОВАНИЯ ПРОЕКТНОГО ПОДХОДА 3.1 Описание проблем и поиск решений Для совершенствования проектного подхода отдела системного и бизнес-анализа рассмотрим аналитический цикл создания постановок, который состоит из совокупности этапов, цикл представлен на рисунке 3.1. Рисунок 3.1 – Аналитический цикл создания постановок На рисунке 3.1 видно, что отсутствует этап по планированию и оценке задач. Рассмотрим матрицу ответственности по аналитическому циклу, которая представлена в таблице 3.1 Таблица 3.1 – Матрица ответственности по аналитическому циклу Участники Этапы Ведущий аналитик Аналитик 1 2 3 Постановка задачи И,О Сбор и систематизация информации И,О Анализ полученных данных И,О Написание постановок И,О Проверка постановок (ревью) И,О По таблице 3.1 видно, что имеется исполнитель и ответственный, где в каждом этапе две роли совмещаются в одном лице. В данной ситуации ведущий аналитик ответственен за постановку задачи и за проведение проверки (ревью), рядовой аналитик ответственен за постановку. 53 Также матрица ответственности может выглядеть по-другому, если ведущий аналитик дал задание рядовому аналитику на проекте на проверку своей постановки, приведена в таблице 3.2 Таблица 3.2 – Матрица ответственности по аналитическому циклу Участники Этапы Ведущий аналитик Аналитик 1 2 3 Постановка задачи И,О Сбор и систематизация информации И,О Анализ полученных данных И,О Написание постановок И,О Проверка постановок (ревью) И,О По таблице 3.2 видно, что в такой ситуации рядовой аналитик является ответственным только по проверке постановок, во всех остальных задачах ответственным является ведущий аналитик. Рассмотрим выявленные во второй главе проблемы и возможные их решения, которые представлены в таблице 3.3. Таблица 3.3 - Описание проблем и их решений в бизнес-процессе № Проблема Актуальность Показатель Решение № Сейчас План 1 2 3 1 2 3 4 5 6 7 8 1 Недооцененное время на разработку функционала влияет на сроки реализации и качество будущего функционала 1 Все три роли зависят друг от друга, при превышении планируемого времени у аналитики, происходит сдвиг по срокам у разработки. При сдвиге времени у разработки, сдвигается время у тестирования. При сдвиге времени у тестирования сдвигается время релиза функционала, а затем и проекта. Также у тестирования сокращается время проверки функционала, что влечет за собой некачественный продукт. 2 В случае просрочки накладывается штраф в размере 10 % от суммы до 3 млн.руб, то уменьшается прибыль с проекта, уменьшается доход компании, что влечет уменьшение премий, а это может сказаться на мотивированности сотрудников, которые, при ухудшении ситуации, уйдут 2 дня День в день Планирова ть время Закладывать дополнительн ое время на риски Следить за сроками выполнения задач, в случае отклонения от срока корректировать время 2 Значительное время тратится на обсуждение функционала В ходе обсуждения функционала сотрудники могут обсуждать возможные варианты (их генерация), отвлечься на нерабочие вопросы 2,25 1 Сбор всех вопросов, которые будут адресованы ответствен ному лицу Генерировани е возможных вариантов и их освещение их ответственно му лицу Обсуждать вопросы в письменном виде В таблице Таблица 3.3 указанные проблемы сформированы по актуальности, также предложены возможные варианты решения. Выделенные серым цветом решения предлагаются для внедрения в бизнес-процесс. Таким образом с помощью решения проблем будет усовершенствован бизнес-процесс и ожидается, что фактические сроки по разработке функционала не будут увеличиваться и будут соотноситься с запланированным временем. В ходе второй главы были выделены следующие проблемы: • Значительное время тратится на обсуждение и изменение функционала. • Имеются риски по срокам. Следствия из указанных проблем: • Недооцененное время на разработку функционала влияет на сроки реализации и качество будущего функционала. • Отсутствует дополнительное время на риски, связанные с недоработкой функционала, для исключения смещения сроков реализации. Также в ходе второй главы были поставлены задачи для решения выделенных проблем: • Уменьшить потери в виде обсуждений и изменений функционала. • Найти решение для реализации функционала в срок. Для решения данных проблем предлагается усовершенствовать проектный подход отдела системного и бизнес-анализа, для исключения смещения сроков передачи постановок в разработку и потерь. В усовершенствованном подходе планируется внедрить, следующие задачи, которые описаны в таблице 3.4: • Изменение порядка постановки задачи ведущему аналитику. • Изменение порядка постановки задачи внутри команды аналитиков. • Изменение оценки задачи. • Изменение планирования задачи. • Создание мотивационной системы. • Создание регламента по коммуникации. • Модернизация системы взаимодействия. 56 Таблица 3.4 – Перечень изменений для улучшения подхода № Наименование задачи Что нужно сделать Кто это будет делать В какие сроки Дополнительные ресурсы Ожидаемый результат 1 2 3 4 5 6 7 1 Изменение порядка постановки задачи ведущему аналитику Организовать собрание всей командой и озвучить задачу Руководитель проекта При последующих задачах Отсутствуют Потраченное время уменьшится ориентировочно на 0,25 часа 2 Изменение порядка постановки задачи внутри команды аналитиков Порядок работы прописать в чате/общем диалоге Ведущий аналитик При последующих задачах Отсутствуют Потраченное время уменьшится ориентировочно на 0,75 часа 3 Изменение оценки задачи 1. Использовать покер планирования. 2. Декомпозировать задачу и оценивать каждую подзадачу. 3. Оценивать время на "погружение" в задачу Группа аналитики При последующих задачах Отсутствуют Планируемое время будет приближено к фактическому 4 Изменение планирования задачи При оценке задачи по времени добавлять время на риски до 15% от оценки самой задачи Ведущий аналитик При последующих задачах Отсутствуют Функционал будет готов в указанный срок или ранее 57 Продолжение таблицы Таблица 3.4 1 2 3 4 5 6 7 5 Создание мотивационной системы За передачу качественной работы, раньше указанного срока, выплачивать бонус Менеджер по персоналу При последующих задачах Создание системы мотивации 1.Функционал будет готов в указанный срок или ранее. 2. Повысится производительность труда 6 Создание регламента по коммуникации 1.Установить временные рамки на ответ. 2. Определить общие часы работы Руководитель проекта При последующих задачах Отсутствуют Уменьшатся потери на "ожидание" ответа 7 Модернизация системы взаимодействия Установить программу, которая будет отслеживать документооборот и обратную связь по нему Руководитель проекта При последующих задачах Создание программы можно вынести на аутсорсинг Уменьшатся потери на "ожидание" ответа 58 В цикле, представленном на рисунке 3.1, отсутствует этап с планированием времени, так как разрабатываемый функционал оценивается по предположению сотрудника, который будет выполнять задачу по данному функционалу, при этом отсутствует первичный анализ для оценки времени выполнения. Исходя из таблицы 3.4 по пунктам 3,4 предлагается внедрить этап «Планирование выполнения», в который будет входить первичный анализ для оценки времени выполнения и дополнительное время на риски. Рисунок 3.2 – Усовершенствованный аналитический цикл создания постановок В целом выделенные проблемы связаны со временем, поэтому была сформулирована цель - совершенствование проектного подхода отдела системного и бизнес-анализа. Предполагается, что цикл улучшится при достижении поставленной цели. Для цели были сформулированы этапы и задачи, которые представлены на рисунке 3.3. Достигнув данной цели, планируется, что на будущие задачи будет закладываться грамотное количество времени, которое позволит реализовывать задачи в запланированный срок. Для достижения цели были сформулированы 5 этапов: 1. Постановка задачи. 2. Разработка инструкции. 3. Тестовое внедрение инструкции. 4. Корректировка инструкции. 5. Выпуск инструкции. К каждому этапу были сформулированы минимум 3 задачи. Предполагается, что при выпуске технологии не будет никаких ошибок, так как после тестового внедрения их проанализировали и были исправлены. 59 Рисунок 3.3 - Дерево этапов и задач 60 3.2 Внедрение и расчет затрат на усовершенствованного бизнес-процесса Была разработана диаграмма Ганта, по рисунку 3.3, которая отображает цель, этапы и задачи, а также их продолжительность по дням. Диаграмма представлена на рисунке 3.4. Диаграмма была создана в программе Microsoft Project. Для внедрения проекта необходимы следующие участники-исполнители: • Руководитель отдела системного и бизнес-анализа. • Менеджер по персоналу. • Руководитель проектов. Исполнитель задачи указан на диаграмме Ганта. 61 Рисунок 3.4 – Диаграмма Ганта 62 По диаграмме Ганта процесс внедрения занимает 45 дней, что означает достаточно длительный процесс. Самым длительным этапом является этап тестирования и внедрения инструкции, так как необходимо собрать информацию и ее обработать. Диаграмма Ганта показана на примере трех месяцев, поэтому для облегчения расчетов рассчитаем среднюю ставку по трем месяцам по формуле 3.1 где Зч.ср – Средняя часовая ставка. 𝑍– Заработная плата за месяц. N – Количество месяцев. H – Количество рабочих часов в месяце. По производственному календарю в третьем квартале количество часов в июле, августе и сентябре равняется 176 часам при рабочей неделе в 40 часов [28]. Рассчитаем среднюю ставку руководителя отдела системного и бизнес-анализа: Зч = 96000 ∙ 3 176 ∙ 3 = 545,5 руб/ч Средняя ставка менеджера по персоналу по формуле 3.1: Зч.ср = 68000 ∙ 3 176 ∙ 3 = 386,4 руб/ч Средняя ставка руководителя проектов по формуле 3.1: Зч.ср = 85000 ∙ 3 176 ∙ 3 = 483 руб/ч В программе Microsoft Project указываем полученные ставки и получаем расчеты на рисунках 3.5 и 3.6. На рисунке 3.5 указаны расчеты задачам, сгруппированные по исполнителю задач. На рисунке 3.5 отображены итоговые часы на планируемую задачу по каждой роли в проекте. На рисунке 3.6 указаны задачи в последовательности внедрения процесса, где под каждой задачей указан исполнитель. Зч.ср = Z ∙ N H ∙ N (3.1) 63 Зная, что ход реализации подхода может влиять на конечные сроки, заложим дополнительное время на риски. Оценим риски по 15% от затраченных часов на задачу каждым участником. Тогда диаграмма Ганта с дополнительным временем на риски отображена на рисунках 3.7, 3.8. 64 Рисунок 3.5 – Диаграмма Ганта с графиком используемых ресурсов без времени на риски 65 Рисунок 3.6 – Использование задач и их затраты без времени на риски 66 Рисунок 3.7 – Диаграмма Ганта с графиком используемых ресурсов со временем на риски 67 Рисунок 3.8 - Использование задач и их затраты с заложенным временем на риски На рисунках с 3.5 по 3.7 у менеджера по персоналу большое количество часов по сравнению с другими исполнителями, что связано с большим количеством задач. Наименьшие трудозатраты у руководителя проектов. По рисунку 3.6 определено общее количество затрат на внедрение подхода без рисков, что составляет 443294 рубля. По рисунку 3.8 общие затраты составляют 509436,3 рублей. Дальнейший расчет будем ввести от наибольшей суммы, в которую заложено время на риски. В таблице 3.5 представлено сравнение времени на внедрение подхода с рисками и без них. Таблица 3.5 -Сравнительная таблица по времени с рисками и без них Участник Без рисков С рисками Часы Часы 1 2 3 Руководитель отдела системного и бизнесанализа 310 355,5 Менеджер по персоналу 330 379,5 Руководитель проектов 304 350 Итого в часах 944 1085 в днях 45 63 Были заложены риски 15% от рассчитанного времени, данные были округлены в большую сторону. По таблице видно, что вариант со временем на риски займет 63 дня, вместо 45 и будет больше на 141 час изначального варианта. Определим итоговые затраты на оплату труда умножив полученную сумму на единый социальный налог 30%. В соответствии с постановлением Правительства РФ от 07.07.2016 №640 [29] срок амортизации компьютера может устанавливаться от 2 лет 1 месяца до 3 лет (25-36 месяцев). Зитог.труд = 509436,3 ∙ 1,3 = 662267,19 рублей (3.2) 69 где С – стоимость ресурса (компьютер, ПО и др.) (возьмем 40000 рублей), для данного проекта необходимо 4 компьютера, так как имеется 4 исполнителя.; Ср – срок полезного использования ресурса (компьютера, ПО и др.); Дл – число рабочих дней в году, в 2021 – 1972 часов. Возьмем срок использования компьютера равный 3 годам и рассчитаем почасовые затраты на компьютеры по выражению 3.3: Также рассчитаем затраты на ресурс ПО по выражению 3.6, Ср примем за срок полезного использования ПО для работы и возьмем равным 7 лет, стоимость оборудования 20000 рублей: Затраты на ресурс Internet рассчитаем по выражению 3.3, где C примем 2500 руб/мес, значит за год: 2500*12, а Ср примем за 3 года, предположим, что тариф будет одинаковым все это время: Суммируем все затраты на компьютеры, ПО и Internet в выражении 3.4: Трудозатраты всего проекта с рисками составляют 1085 часов. Вся работа происходит с помощью компьютера, ПО и Internet, поэтому рассчитаем затраты оборудования (Зоб) в зависимости от часов, потраченных на весь проект, по формуле: Трудозатраты по всему проекту по формуле 3.5 составляет: Зк = С ∙ 4 СР ∙ ДЛ (3.3) Зк = 45000 ∙ 4 3 ∙ 1972 = 30,42 руб/час Зк = 20000 ∙ 4 7 ∙ 1972 = 5,8 руб/час Зк = 2500 ∙ 12 ∙ 4 3 ∙ 1972 = 20,28 руб/час Зо = 30,42 + 5,8 + 20,28 = 56,5 руб/ч. (3.4) Зоб = Зо ∙ N = 61302,5 рублей (3.5) Зоб = 56,5 ∙ 1085 = 61302,5 рублей 70 В выражении 3.6 рассчитаем полностью все затраты на зарплату и на оборудование: Благодаря диаграмме Ганта рассчитаны все затраты на внедрение проекта, также посмотрели загруженность каждого участника проекта. В перспективе можно оптимизировать данный проект для снижения затрат.
|
|
|
Скачать 1.03 Mb.