Автоматизация управления проектами на основе гибких методологий

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

Поставка:

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

осуществляется запуск системы в промышленную эксплуатацию и последующее сопровождение.

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

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

MS Project используется руководителем проекта для решения задач:

планирование стадий проекта с указанием сроков;

планирование и оценка трудозатрат задач внутри стадии;

Jira используется для решения задач:

постановка задач разработчикам;

уточнение информации по задачам;

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

В Jira используются стандартные типы запросов (issue): задача (task) и ошибка (bug), а также базовый бизнес-процесс (рисунок 13):

Рисунок 12. Организационная структура компании

Источник: https://wiki.teamlead.ru/pages/viewpage.action?pageId=85229701

Вся проектная документация хранится в отдельной папке проекта в Microsoft SharePoint, доступ к папке есть только у проектной команды и руководителей.

2.2 Обоснование выбора методологии проектного управления

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

Новые требования вызваны разными причинами:

изменение ответственных за процессы;

желание перейти на новую версию ПО;

реорганизация структуры компании-заказчика и внутренних процессов;

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

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

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

Для проверки возможности использования гибких методологий была проведена оценка применимости Agile-модели на выполняемых проектах. Анкету было предложено заполнить руководителям департаментов, менеджерам и руководителям со стороны заказчика на действующих проектах. Результат оценки представлен в таблице 4 и на рисунке 14.

Таблица 4. Оценка применимости agile на проектах компании

Категория	Вопрос	Критерий оценки	Ответ
Культура	Поддержка подхода	1 - Да 5 - Частично 10 - Нет	4
	Доверие в команде	1 - Да 5 - Вероятно 10 - Маловероятно	3
	Полномочия команды на принятие решений	1 - Да 5 - Вероятно 10 - Маловероятно	7
Команда	Размер команды	1-9 = 1, 10-20 = 2, 21-30 = 3, 31-45 = 4, 46-60 = 5, 61-80 = 6, 81-110 = 7, 111-150 = 8, 151-200 = 9, 201+ = 10	2
	Уровни опыта	1 - Да 5 - Частично 10 - Нет	5
	Доступ к заказчику	1 - Да 5 - Частично 10 - Нет	2
Проект	Вероятность изменений	1 - 50% 5 - 25% 10 - 5%	5
	Критичность продукта или услуги	1 - Время 2 - Несущественный деньги 5 - Существенные деньги 7 - Одна жизнь 10 - Много жизней	5
	Инкрементная поставка	1 - Да 5 - Возможно/иногда 10 - Маловероятно	3

Рисунок 14. Диаграмма применимости подхода agile в компании (Agile Practice Guide, 2017)

управление проект гибкая методология

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

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

Таким образом, необходимо, разработанная методология обладала следующими характеристиками:

требования к системе в целом и отдельно к MVP продукта (Minimum viable product, Минимально жизнеспособная версия продукта) формируются до начала разработки, но после каждой итерации могут быть изменены или дополнены;

разработка продукта осуществляется короткими (не более 1 месяца) итерациями;

по завершении каждой итерации заказчику для получения обратной связи предоставляется работоспособная версия продукта;

есть возможность пересматривать и изменять план следующих итераций;

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

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

События:

Sprint (спринт, итерация): разработка будет проводиться короткими итерациями (длиной от 2 до 4 недель в зависимости от проекта);

Sprint Planning (Планирование спринта): планирование спринта будет осуществляться руководителем проекта совместно с заказчиком и ведущим разработчиков;

Daily Scrum (Ежедневный стендап): ежедневные встречи с команды с руководителем проекта со стороны заказчика для обсуждения статуса задач;

Sprint Review (Анализ спринта): демо инкремента для заказчика (проводится при необходимости);

Артефакты:

Product Backlog (Бэклог продукта): набор задач, который формируется на основе проектной документации;

Sprint Backlog (Бэклог спринта): набор задач, которые обеспечивают реализацию необходимой функциональности инкремента;

Increment (Инкременты): работоспособная версия продукта, которая предоставляется заказчику по итогу каждой итерации.

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

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

Этап подготовки и согласования технического задания на проект до начала фазы разработки остается аналогичным предиктивной модели.

Таблица 5. Сравнение разработанной гибридной методологии с фреймворком SCRUM

	SCRUM	Гибридная методология	Специфика объекта в гибридной методологии
События	Спринт	Итерация	Итерация не будет называться "Спринт" для удобства действующих заказчиков
	Планирование спринта	Планирование итерации	Планирование осуществляется не командой разработки, а руководителями проекта (со стороны команды и заказчика) и ведущим разработчиком команды
	Ежедневный стендап	Ежедневный стендап	На ежедневном стендапе присутствует руководитель проекта со стороны заказчика; стендапы допустимо проводить не каждый день
	Анализ спринта	Демо	Проведение демо реализованного функционала для заказчика (на постоянной основе, или по требованию заказчика)
	Ретроспектива спринта	-
Артефакты	Бэклог продукта	Бэклог проекта	Перечень задач разного уровня сложности, сформированный на основе проектной документации (согласованной до начала обработки)
	Бэклог спринта	Бэклог итерации	Перечень задач, которые должны быть завершены в рамках итерации
	Инкремент	Релиз	Релиз подразумевает установку новой версии продукта на стенд заказчика
Роли	Product owner	Руководитель проекта Руководитель проекта со стороны заказчика	За бэклог задач отвечают руководители проекта со стороны компании и заказчика
	Scrum master	-
	Команда разработки	Проектная команда	В проектную команду входят руководитель проекта, аналитики, разработчики и специалисты по тестированию
Единица спринта	Пользовательская история	Задача
Единица оценки	Story Point	Час

Для визуализации задач будет использоваться SCRUM-доска со следующим набором столбцов:

BACKLOG;

TO DO;

ANALYSIS;

IN PROGRESS;

TESTING;

DONE.

Описание критериев, по которым задача перемещается между столбцами, представлено в таблице 6.

Таблица 6. Описание столбцов SCRUM-доски

Наименование	Описание	Лимит незавершенных задач	Переход
BACKLOG	Перечень задач, которые должны быть выполнены в течение итерации	-	в столбец TO DO
TO DO	Перечень задач на текущий день	-	в столбец BACKLOG или ANALYSIS
ANALYSIS	Задача в работе у аналитика	Равен количеству аналитиков в команде	в столбец IN PROGRESS, TO DO или BACKLOG
IN PROGRESS	Задача в работе у разработчика	Равен количеству разработчиков в команде	в столбец TESTING или ANALYSIS
TESTING	Задача в работе у тестировщика	Равен количеству тестировщиков в команде	в столбец IN PROGRESS, DONE или ANALYSIS
DONE	Задача выполнена	-	в столбец TO DO или BACKLOG

2.3 Обоснование выбора программного обеспечения для управления проектами

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

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

Microsoft Project;

Jira Software;

Asana;

Slack;

Trello.

Microsoft Project

Microsoft Project - это программное обеспечение (ПО) для управления проектами от компании Microsoft. Инструмент предназначен для анализа сложности проекта, планирования задач и распределения ресурсов (Microsoft Office, 2019).

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

этапы выполнения;

количество участников;

затраты;

используемые ресурсы;

затраченное время.

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



Рисунок 15. Диаграмма Гантт

Источник: https://professionali.ru/Soobschestva/upravlenie_proektami/upravlenie-proektami-diagramma-ganta-v/

Решаемые задачи.

Microsoft Project позволяет решать следующие задачи управления проектами:

формирование плана проекта, который включает в себя сроки исполнения работ и бюджет;

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

определение схемы финансирования работ и поставок необходимого оборудования;

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

создавать иерархию участников процессов и задач;

контроль выполнения плана проекта с возможностью его корректировки;

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

Преимущества.

Microsoft Project имеет ряд преимуществ:

возможность интеграции с другими продуктами Microsoft Office;

возможность реализации модели с несколькими сценариями;

возможность создания интерактивных панелей мониторинга с использованием Power BI;

синхронизация с корпоративной почтой и мессенджерами;

может внедряться как полностью независимый инструмент, так и взаимодействовать с уже налаженной экосистемой классических или облачных решений от Microsoft;

высокий уровень защиты данных;

хранение данных в БД MS SQL Server;

интеграция с библиотекой проектной документации на базе SharePoint.

Недостатки

Microsoft Project имеет следующие недостатки:

является сложным для освоения инструментом, так как перегружен функционалом;

не поддерживает совместную работу нескольких пользователей;

не user-friendly интерфейс;

высокие цены за полный пакет функций.

Jira Software

Jira Software -- это инструмент управления проектами для agile-команд, разработанное австралийской компанией Atlassian.

Jira состоит из ряда компонентов, которые можно настраивать:

рабочий процесс (Workflow);

типы задач (Issue Types);

пользовательские рабочие пространства (Custom Fields);

окна (Screens);

настройка рабочих пространств (Field Configuration);

уведомления (Notification);

решения (Permissions).

Решаемые задачи.

Jira Software позволяет решать следующие задачи управления проектами:

разработка дорожной карты проекта (Roadmap) и подключение ее к процессам команды (рисунок 16);

планирование работ: создание пользовательских историй и задач, планирование спринтов и распределение заданий в команде;

контроль выполнения работ проекта:

создание Scrum-досок (рисунок 17): агрегирует всю информацию о работе, которая должна быть выполнена командой. Scrum-доска позволяет использовать спринты при планировании работ;

создание Kanban-досок (рисунок 18): отображает актуальные статусы задач;

формирование Agile-отчетов (рисунок 19) с информации о прогрессе во время спринта;

контроль релизов.

Рисунок 16. Roadmap в Jira

Источник: https://www.atlassian.com/ru/software/jira/features



Рисунок 17. Scrum-доска в Jira

Источник: https://www.atlassian.com/ru/software/jira/features

Рисунок 18. Kanban-доска в Jira

Источник: https://www.atlassian.com/ru/software/jira/features



Рисунок 19. Agile-отчеты в Jira

Источник: https://www.atlassian.com/ru/software/jira/features

Преимущества.

Jira Software имеет ряд преимуществ:

совместная работа команды;

привязка задач к коду: возможность добавления информации из инструментов управления версиями и сборками;

детализированная информация по каждой из задач;

интеграция с Confluence и Bitbucket;

возможность настройки кастомизированного процесса и правил для каждого проекта;

наличие мобильного приложения;

гибкость и масштабируемость.

Недостатки

Jira Software имеет следующие недостатки:

из-за многофункциональности инструмента может быть сложно найти необходимую опцию;

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

Asana

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

Решаемые задачи.

Asana позволяет решать следующие задачи управления проектами:

планирование работ (рисунок 20):

установка дедлайнов и приоритетов для каждой задачи;

распределение задач между участниками команды;

проверка наличия конфликтов при планировании (рисунок 21);

контроль выполнения задач на Kanban-доске (рисунок 22);

возможность проведения процессов согласований.

Рисунок 20. Планирование работ в Asana

Источник: https://asana.com



Рисунок 21. Проверка конфликтов в Asana

Источник: https://asana.com

Рисунок 22. Kanban-доска в Asana

Источник: https://asana.com

Преимущества.

Asana имеет ряд преимуществ:

совместная работа команды;

возможность настройки шаблонов и правил для каждого проекта;

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

наличие мобильного приложения;

интеграция со Slack;

до 15 участников ПО бесплатное.

Недостатки

Asana имеет следующие недостатки:

отсутствуют push-уведомления в web-версии;

отсутствует возможность настройки прав доступа к задачам и доскам;

отсутствует возможность отслеживать релизы и сборки;

отсутствие русскоязычной версии;

высокая стоимость для команд более 15 человек.

Slack

Slack - корпоративный мессенджер для командной работы. В отличие от других мессенджеров удобен для использования тем, что в нем можно создавать отдельные каналы (рисунок 23) для разных тем и предоставлять доступ к ним только тем сотрудникам, которым он необходим. Другим преимуществом является возможность создавать thread (ветка обсуждений) для обсуждения какого-либо вопроса на канале, таким образом, всегда понятно, к какому сообщению относится ответ. Кроме того, автор первоначального сообщения будет оповещен обо всех ответах на него.

Рисунок 23. Интерфейс Slack

Источник: https://slack.com/intl/en-ru/?eu_nc=1

Решаемые задачи.

Slack позволяет решать следующие задачи:

организация доступа всех участников команды к необходимой информации по проекту;

оповещение команды об изменениях и обновлениях;

создание задач, управление ими и отслеживание готовности;

обсуждение задач и обмен необходимыми материалами.

Преимущества.

Slack имеет ряд преимуществ:

совместная работа команды;

интеграция с большим количеством систем (Outlook, OneDrive, Trello, GitHub, Dropbox и другие);

сквозной поиск документов по всем каналам и чатам;

возможность аудио и видео-звонков;

наличие мобильного приложения;

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

Недостатки

Slack имеет следующие недостатки:

отсутствие русскоязычной версии;

высокая стоимость для крупных организаций.

Trello

Trello -- облачная программа для управления проектами небольших групп, разработанная Fog Creek Software в 2011 году (в настоящее время куплена компанией Atlassian). В основе инструмента лежит фреймворк Kanban. Trello -- это одна из самых популярных систем управления проектами в режиме онлайн, которая пользуется особенным спросом среди небольших компаний и стартапов.

Структура Trello также состоит из досок, которые разделены на списки с карточками. Каждую из досок можно выделять под конкретные рабочие процессы или отделы (рисунок 24). Каждую из карточек можно открыть и посмотреть детализированную информацию по задаче (рисунок 25).

Рисунок 24. Интерфейс Trello

Источник: https://trello.com/ru

Рисунок 25. Карточки для задач

Источник: https://trello.com/ru

Решаемые задачи.

Trello позволяет решать следующие задачи управления проектами:

формирование бэклога задач;

планирование: установка сроков выполнения задач и ответственных лиц;

контроль выполнения задач с использованием Kanban-доски.

Преимущества.

Trello имеет ряд преимуществ:

совместная работа команды;

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

возможность автоматизации рабочих процессов (триггеры на основе правил, настраиваемые кнопки создания карточек и досок, команды для календаря, команды по дате выполнения);

наличие готовых шаблонов для проектов разных типов;

наличие мобильного приложения;

интеграция со Slack;

наличие бесплатной версии ПО (количество интеграций и объем загружаемых файлов будут ограничены).

Недостатки

Trello имеет следующие недостатки:

функционала недостаточно для крупных компаний;

в бесплатной версии мало интеграций;

отсутствует возможность отслеживать релизы и сборки;

отсутствуют Swimlanes и лимиты Work in Progress;

отсутствует возможность задачи на спринты на одной доске;

отсутствует возможность реализовать Roadmap проекта;

высокая стоимость для команд более 15 человек.

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

Возможность построения дорожной карты (roadmap) проекта с учетом сроков, ресурсов и бюджета.

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

Возможность работы со спринтами.

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

Возможность приоритезации задач.

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

Распределение задач между участниками команды разработки.

Возможность обмена материалами по проекту и документацией.

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

Возможность совместной работы.

Контроль релизов и версий.

Интеграция с почтовыми сервисами.

Интеграция с продуктами MS Office.

Интеграция с репозиториями Bitbucket/Github.

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

Также есть нефункциональные параметры, по которым можно сравнивать инструменты управления проектом.

Наличие русскоязычной версии.

Цена.

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

Таблица 7. Сравнительный анализ инструментов управления проектами

Характеристика	MS Project	Jira	Asana	Slack	Trello
Построения roadmap проекта
Контроль выполнения задач
Работа со спринтами
Наличие Kanban-доски
Наличие Scrum-доски
Приоритезация задач
Установка сроков задач
Назначение задач команде разработки
Обмен материалами по проекту
Обсуждение задач внутри команды
Совместная работа
Контроль релизов и версий
Интеграция с почтовыми сервисами
Интеграция с продуктами MS Office
Интеграция с репозиториями Bitbucket/Github
Выгрузка отчетов
Русскоязычная версия
Наличие бесплатной версии

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

Решение MS Project позволяет реализовать подробный план как всего проекта, разделенного на этапы (вехи), так и план каждого их этапов отдельно. Большим преимуществом является интеграция с другими продуктами пакета MS Office, которые активно используются при работе с проектами.

На данный момент в рассматриваемой компании MS Project уже используется руководителем проекта для планирования фаз проекта и оценки трудозатрат отдельных задач внутри фазы. Для оценки и планирования задач, а также для построения дорожной карты проекта инструмент полностью подходит, так как с его помощью с большой точностью можно распределить ресурсы любого типа (как сотрудников с указанием их ставок, так и оборудования), и потом обмениваться файлом с планом с коллегами и клиентом (по этой причине отсутствие возможности совместной работы команды над проектом не критично). Системы Jira или Asana не обладают аналогичным функционалом в полной мере, поэтому не смогут заменить MS Office при планировании сроков и бюджета. Также MS Project позволяет отслеживать прогресс работ по всему проекту во времени с помощью диаграммы Гантта: и по плану можно легко определить, сколько прошло времени с начала проекта и какое наблюдается отклонение фактического результата от планируемого.

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

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

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

Создавать отдельные пространства для каждого проекта.

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

Использовать функционал связи между запросами.

Добавить запросам необходимые атрибуты (например, «Номер релиза»).

Настроить Scrum-доску и фильтры для неё.

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

За реализацию необходимых настроек в пространстве проекта отвечает руководитель проекта.

Также дополнительно к Jira следует использовать Confluence для структурированного хранения полезной для команды проектной информации.

Asana и Trello являются наиболее универсальными инструментами из представленных, но не обладают достаточным функционалом для ведения задач разработки: например, существенным минусом является отсутствие интеграции с репозиториями разработки и невозможность контроля релизов и версий. Но они могут быть использованы руководителем проекта для создания Scrum-доски с задачами аналитиков: это целесообразно для больших команд, в которых более трех аналитиков. Рассматриваемой компании лучше использовать Trello, так как у Trello и Jira один владелец (Atlassian), и между этими системами можно настроить интеграцию. В больших командах из-за большого количества задач на разработку и дефектов доска в Jira может быть перегружена. Руководителю проекта и аналитикам будет проще отслеживать свои задачи на отдельной доске. Кроме того, участники команд могут создавать индивидуальные доски в Trello для трекинга своих задач.

Slack представляет собой решение с конкретным функционалом - мессенджер. Это - многофункциональный мессенджер с удобным поиском документов, возможностью интеграции с большим количеством других систем (например, Trello) и возможностью создавать отдельные каналы и ветки обсуждения для разных вопросов. Рассматриваемой компании следует использовать Slack для обсуждения задач, хранения необходимой информации и оповещения команды об изменениях, но при этом для контроля задач использовать, например, Trello, и MS Project для планирования работ на проекте.

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

Таблица 8. Описание столбцов SCRUM-доски

Инструмент	Решаемые задачи	Пользователь
MS Project	1. Подготовка план-графика проекта с учетом трудозатрат и бюджета 2. Подготовка дорожной карты продукта 3. Контроль отклонения фактического темпа реализации от планируемого	Руководитель проекта, заказчик
Jira	1. Постановка задач на разработку и тестирование 2. Планирование релизов 3. Контроль выполнения задач	Команда, заказчик
Confluence	1. Хранение проектной документации, инструкций и другой полезной информации для команды и заказчика	Команда, заказчик
Trello	1. Создание Scrum-доски для распределения задач между аналитиками 2. Создание индивидуальных Scrum-досок для отслеживания личных задач	Команда
Slack	1. Обсуждение вопросов по проекту и задачам 2. Обмен файлами	Команда, заказчик

Идеального инструмента для управления ИТ-проекта не существует, но всегда можно подобрать подходящее для своего проекта ПО, из вариантов, представленных на рынке. MS Project не подходящий инструмент для agile-методов, если использовать только его, однако это хороший инструмент для планирования дорожной карты проекта любого типа в любой предметной области, поэтому в комплексе с другим ПО, в котором будет работать команда разработки, может оказаться очень эффективным инструментом. Jira - инструмент, эффективный и удобный для больших команд разработки, но слишком сложный для заинтересованных лиц со стороны бизнеса. Trello и Asana - универсальные инструменты для многих типов проектов, кроме разработки ПО, так как не содержат специфических для разработки функций. Slack представляет собой удобный мессенджер, но не может использоваться как самостоятельный инструмент для ведения проектов.

ГЛАВА 3. ОПТИМИЗАЦИЯ ПРОЦЕССА ВНЕДРЕНИЯ CRM-СИСТЕМЫ НА ОСНОВЕ ИСПОЛЬЗОВАНИЯ ГИБКИХ МЕТОДОЛОГИЙ

3.1 Описание ИТ-проекта внедрения CRM-системы

Проверка эффективности предложенного оригинального гибридного подхода будет осуществляться на действующем проекте внедрения CRM-системы в крупной российской компании-застройщике. Проект разделен на 4 независимых блока, каждый из которых предполагалось последовательно внедрять по предиктивной модели. Проект начался в октябре 2019 года (дата начала проекта: 23.09.19), на данный момент находится на фазе тестирования первого блока.

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

MS Project для построения план-графиков проекта и фаз;

Jira для постановки задач разработчикам (используются стандартные типы запросов: задача (task) и ошибка (bug), а также базовый бизнес-процесс);

Microsoft SharePoint для хранения проектной документацией (доступ к папке с документацией есть только у команды и руководителей).

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

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

анкеты клиентов;

документы клиентов;

поэтажные планы строительных объектов;

планы и метраж квартир в строительных объектах;

шаблоны документов для оформления сделок;

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

отдел продаж (сотрудники офиса продаж);

контактный центр (колл-центр);

отдел оформления сделок;

управление предпродажной подготовкой (занимается подготовкой файлов с данными по объектам недвижимости и строительным объектам) - косвенное взаимодействие с клиентом.

Таким образом, среднее время оформления сделки на продажу квартиры с момента первого обращения клиента до выдачи ключей - 3 недели (при условии, что клиент после первой консультации определился с выбором объекта недвижимости, и процесс оформления был запущен). Из-за длительного оформления сделок наблюдается отток клиентов к конкурентам компании. Цель компании - сократить среднее время обработки заявки до 5 дней.

Для внедрения CRM-системы Microsoft Dynamics CRM в консалтинговой компании была определена команда из 15 человек, включающая в себя:

руководителя проекта;

5 консультантов:

2 ведущих специалиста;

2 старших специалиста;

1 стажер;

6 разработчиков:

2 ведущих специалиста (front-end и back-end);

2 старших специалиста (front-end и back-end);

1 специалист (back-end);

1 младший специалист (back-end);

3 специалиста по тестированию (ручное тестирование):

1 ведущий специалист;

2 специалиста.

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

Определение проблемы и сбор информации.

Анализ (подготовка и согласование документации на проект).

Блок «Отдел продаж»:

анализ;

дизайн;

разработка;

тестирование и оценка системы;

сопровождение.

Блок «Контактный центр»:

анализ;

дизайн;

разработка;

тестирование и оценка системы;

сопровождение.

блок «Оформление сделок»:

анализ;

дизайн;

разработка;

тестирование и оценка системы;

сопровождение.

Блок «Управление предпродажной подготовкой»:

анализ;

дизайн;

разработка;

тестирование и оценка системы;

сопровождение.

Дата начала проекта: 23.09.19, планируемые даты завершения блоков проекта:

блок «Отдел продаж» - 29.07.2020;

блок «Контактный центр» - 20.11.2020;

блок «Оформление сделок» - 10.03.2021;

блок «Управление предпродажной подготовкой» - 07.07.2021.

Диаграмма Гантта для проекта внедрения CRM-системы представлена в приложении (Приложение 1).

После завершения общего этапа Анализа проекта начался этап разработки блока «Отдел продаж» (рисунок 26). Руководителем проекта был составлен план-график выполнения задач блока, после чего совместно с руководителем разработки были выделены отдельные крупные задачи (разработка процесса работы с заявкой, два веб-приложения) и распределены между разработчиками. График разработки блока «Отдел продаж» доступен в приложении (Приложение 2).

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

На данный момент проект перешел на фазу «Тестирование» блока «Отдел продаж». По диаграмме Гантта можно заметить, что дата перехода на этап была смещена на две недели; с 02.04.20 на 15.04.2020. План-график был скорректирован (рисунок 27), срок окончания блока изменился на 11.08.2020. Дата окончания всего проекта также сместилась на 20.07.2021 (была 07.07.2021).

Рисунок 26. Диаграмма Гантта для блока «Отдел продаж» (план).

Рисунок 27. Диаграмма Гантта для блока «Отдел продаж» (факт).

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

добавить новую роль пользователя и настроить для нее процесс;

изменить атрибутный состав экранных форм и тип данных некоторых атрибутов;

изменить бизнес-процесс обработки заявки (добавить новые этапы, внести правки в существующие);

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

реализовать веб-приложение для администратора на ресепшене, чтобы он мог контролировать очередь клиентов на консультации;

в веб-приложениях для подбора объектов недвижимости изменить набор фильтров и адаптировать функционал под использования нового формата поэтажных планов;

реализовать автоматическое сканирование документов клиента.

Большое количество замечаний было вызвано тем, что за длительный период реализации (между согласованием ЧТЗ и передачей функционала на тестирование заказчику прошло более 5 месяцев) произошли существенные изменения:

изменился процесс обработки заявки в связи с реорганизацией отделов внутри компании заказчика;

появились новые требования, которые не были учтены ранее, но в значительной степени влияют на процесс;

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

пользователям из фокус-группы было неудобно работать с системой (при согласовании ЧТЗ и макетов экранных форм их мнение не было учтено).

Руководителем проекта были определены критические замечания и доработки, без которых система не пройдет приемо-сдаточные испытания (ПСИ), доработки были оценены в 50 рабочих дней. Это значит, что срок всего проекта и бюджет будет изменен. Такой вариант не устроил заказчика: он уверен, что подрядчик допустил ошибки и должен исправить их без дополнительной оплаты, кроме того, перенос срока завершения проекта в 2,5 месяца недопустим.

Для того, чтобы не допустить конфликт, руководителю проекта потребовалось:

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

Оценить новые доработки и согласовать их в отдельном ЧТЗ. После согласования ЧТЗ команда приступит к разработке.

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

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

Таким образом, доработки были оценены в 1,5 месяца. Этот вариант устроил заказчика.

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

Было принято решение проверить возможность применения разработанного гибридного подхода управления проектом. Была проведена оценка применимости Agile-модели и возможности использования гибких методологий на проекте внедрения CRM-системы. Анкету заполнили следующие участники проекта:

руководитель проекта;

ведущие консультанты на проекте;

заинтересованные лица со стороны заказчика.

Также анкета была предоставлена руководителям отделов разработки, консалтинга и тестирования департамента CRM-систем. Результат оценки представлен в таблице 9 и на рисунке 28.

Таблица 9. Оценка применимости agile на проекте внедрения CRM-системы

Категория	Вопрос	Критерий оценки	Ответ
Культура	Поддержка подхода	1 - Да 5 - Частично 10 - Нет	3
	Доверие в команде	1 - Да 5 - Вероятно 10 - Маловероятно	5
	Полномочия команды на принятие решений	1 - Да 5 - Вероятно 10 - Маловероятно	6
Команда	Размер команды	1-9 = 1, 10-20 = 2, 21-30 = 3, 31-45 = 4, 46-60 = 5, 61-80 = 6, 81-110 = 7, 111-150 = 8, 151-200 = 9, 201+ = 10	2
	Уровни опыта	1 - Да 5 - Частично 10 - Нет	4
	Доступ к заказчику	1 - Да 5 - Частично 10 - Нет	1
Проект	Вероятность изменений	1 - 50% 5 - 25% 10 - 5%	5
	Критичность продукта или услуги	1 - Время 2 - Несущественный деньги 5 - Существенные деньги 7 - Одна жизнь 10 - Много жизней	5
	Инкрементная поставка	1 - Да 5 - Возможно/иногда 10 - Маловероятно	3

м

Рисунок 29. Диаграмма применимости подхода agile на проекте внедрения CRM-системы

Источник: Agile Practice Guide, 2017

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

3.2 Применение разработанной методологии для проекта внедрения CRM-системы

В рамках применения на проекте предложенного agile-подхода с элементами предиктивной модели руководителями проекта со стороны заказчика и подрядчика был разработан план мероприятий, необходимых для перехода к новой методологии управления на проекте внедрения CRM-системы:

ЧТЗ блока «Контактный центр» будет актуализировано, назначен ответственный аналитик со стороны подрядчика.

Процесс разработки блока будет разделен на итерации (длина итерации - 3 недели, первый день итерации - понедельник).

Руководителем проекта совместно с заказчиком определен функционал MVP (Minimum viable product) продукта - минимально жизнеспособный продукт, который будет представлен по итогу первой итерации.

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

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

Итогом каждой итерации будет релиз разработанного функционала. Релиз проводится в нерабочее время (начало в 21:00) в среду на последней неделе итерации.

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

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

Подробный план итерации изображен на рисунке 30:

Рисунок 30. План итерации.

Дополнительно был изменен подход к работе над проектом внутри команды разработки:

Ежедневно в команде будут проводиться daily-стендапы. 1-2 раза в неделю, в зависимости от необходимости, на daily-стендап планируется присутствие руководителя проекта со стороны заказчика.

За три дня до демо тестировщиками команды будет проводиться функциональное регрессионное тестирование процесса, направленное на проверку изменений в системе для подтверждения того факта, что существующая ранее функциональность работает корректно (ProTesting, 2020).

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

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

Создана Kanban-доска в Trello для руководителя проекта и аналитиков для планирования и отслеживания задач на текущий день (рисунок 31).

Провести реорганизацию процесса ведения задач в Jira.

Рисунок 31. Общая доска в Trello для аналитиков.

Реорганизация задач в Jira. Использование стандартных типов запросов и базового процесса не позволяет эффективно контролировать статус выполнения задач и ориентироваться в них. Было принято решение добавить новые типы запросов на настроить для каждого из них отдельный бизнес-процесс. Ниже перечислены типы запросов и описание задач, для которых необходимо их использовать:

Тип запроса - «История» используется для обозначения блока проекта, в рамках которого выполняются задачи. Например для блока проекта «Контактный центр» руководителем проекта в Jira создается запрос с типом «История» и наименованием «Реализация CRM для блока “Контактный центр”». В описании запроса указывается вся необходимая информация для реализации, такая как:

бизнес-требования;

план работ в MS Project (с оценкой трудозатрат и сроков);

план релизов;

ветка для разработки (UI).

Все запросы, созданные в рамках блока должны быть связаны с Историей (связь с декомпозированными задачами). Бизнес-процесс заявки с типом «История» представлен на рисунке 32.

Рисунок 32. Бизнес-процесс заявки с типом «История».

Тип запроса - «Анализ» используется аналитиком для следующих целей:

добавление актуальных версий спецификаций требований для разработчиков (в задачах на разработку достаточно добавить связь на эту заявку, чтобы не обновлять версию спецификации во всех запросах);

логирование времени, затраченного на анализ по задаче;

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

Запрос должен быть обязательно связан с Историей. Бизнес-процесс заявки с типом «Анализ» представлен на рисунке 33.

Рисунок 33. Бизнес-процесс заявки с типом «Анализ».

Тип запроса - «Разработка» используется аналитиком для постановки задач разработчикам. Запрос должен быть обязательно связан с Историей и, при необходимости, с запросом с типом «Анализ». Бизнес-процесс заявки с типом «Разработка» представлен на рисунке 34.

Рисунок 34. Бизнес-процесс заявки с типом «Разработка».

Тип запроса - «Тестирование» создается руководителем проекта для каждого релиза (пример наименования «Тестирование релиза №5») и используется специалистами по тестированию для следующих целей:

добавление тест-кейсов;

добавление дефектов по блоку.

Запрос должен быть обязательно связан с Историей и с запросом с типом «Анализ». Бизнес-процесс заявки с типом «Тестирование» представлен на рисунке 35.

Рисунок 35. Бизнес-процесс заявки с типом «Тестирование».

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

наименование стенда, на котором воспроизвелся дефект;

номер заявки, на которой воспроизвелся дефект;

ссылка на экранную форму, на которой воспроизвелся дефект;

шаги воспроизведения дефекта;

фактический результат;

ожидаемый результат.

Дефект назначается на аналитика, после чего аналитик переназначает его на ответственного за функционал разработчика. Бизнес-процесс заявки с типом «Дефект» представлен на рисунке 36.

Рисунок 36. Бизнес-процесс заявки с типом «Дефект».

В запросы добавлен атрибут «Номер релиза», в котором для каждого запроса с типом «Разработка», «Тестирование» и «Дефект» необходимо при создании выбрать номер релиза из выпадающего списка.

Для запросов настроен список меток, описание которых приведено в таблице 11.

Таблица 11. Описание меток для запросов в Jira

Наименование	Описание
Front-end	Используется для запросов с типом «Разработка», если задача относится к функционалу UI (разработка и доработка экранных форм).
Back-end	Используется для запросов с типом «Разработка», если задача относится к функционалу back-end (доработка модели данных, сервисов, интеграций).
Dictionary	Используется для запросов на создание/изменение справочников.
Смежная система	Для каждой из смежных систем создана метка с ее наименованием (например, SharePoint, Сайт). Метка добавляется к задаче на разработку, если она включает функционал интеграции с соответствующей системой.

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

3.3 Результат применения разработанной методологии проектного управления

Разработка нового блока проекта «Контактный центр» была реализована в соответствии с предложенным подходом. В таблице 12 представлено подробное описание событий, которые были проведены в течение итерации.

Таблица 12. Описание событий итерации

Дата	День недели	События	Результаты	Участники
30.04.2020	четверг	Определение MVP продукта	Определена минимальная функциональность продукта, которая будет передана на тестирование заказчику: экранная форма карточки "Звонок" в CRM с атрибутным составом входящего звонка и функционалом сохранения данных прототип панели для осуществления звонков из CRM (без интеграции с телефонией)	Руководитель проекта, руководитель проекта со стороны заказчика

Подобные документы

• Управление проектами и системы управления проектами

  Сущность управления проектами, этапы его реализации и необходимые для этого знания, порядок составления и назначение Плана управления проектом. Концепция тройственной ограниченности. Использование программы MS Oficce Project в управлении проектами.
  
  реферат [24,9 K], добавлен 16.11.2009
  

• Программы управления проектами

  Необходимая терминология и основные программные продукты для управления проектами. Краткое ознакомление с системами: Project, Primavera, Spider Protect и Open Plan. Корпоративное управление проектами. Отличительные черты программного обеспечения СКПК.
  
  контрольная работа [1,3 M], добавлен 13.09.2010
  

• Инженерный менеджмент и информационные технологии

  Понятие жизненного цикла программного обеспечения. Два вида деятельности, различаемые в технических проектах: проектирование и производство. Основные постулаты манифеста последователей гибких методологий. Базовые принципы экстремального программирования.
  
  презентация [170,8 K], добавлен 14.08.2013
  

• Управление проектами с использованием компьютерной программной системы MS Project 2003 для Windows

  Внедрение системы управления проектами Microsoft Project 2003 в Московский институт экономики, менеджмента и права для автоматизации учета выполнения дипломных проектов. Сравнительная характеристика систем управления проектами в России и за рубежом.
  
  дипломная работа [1,4 M], добавлен 25.10.2013
  

• Разработка детальной концепции и визуального дизайна сайта

  Обоснование выбора Microsoft Project - программы управления проектами, разработанной корпорацией Microsoft. Использование программы для определения критического пути проекта. Основные понятия и методы управления проектами. Составление плана работ.
  
  курсовая работа [2,7 M], добавлен 13.07.2014
  

• Open Plan - система управления проектами

  Обзор рынка Информационных технологий. Современные автоматизированные системы управления проектами и их классификация. Open Plan (Welcom Software) - система, предлагающая решение по управлению проектами масштаба корпорации. Основные модули Open Plan.
  
  курсовая работа [630,9 K], добавлен 24.02.2010
  

• Разработка ЭИС управления проектами для ЗАО "Диакон"

  Разработка системы управления проектами для компании ЗАО "Диакон". Экономические параметры разработки и внедрения электронной информационной системы. Технология разработки программного обеспечения. Выбор типа графического интерфейса, его составляющие.
  
  дипломная работа [1,4 M], добавлен 10.06.2014
  

• Microsoft Office Project 2007 Professional. Управление проектами

  Общие принципы управления проектами как процесс планирования, организации и контроля за состоянием его задач и ресурсов. Инструменты управления проектами от Microsoft. Описание ресурсов и затрат. Контроль хода выполнения, технология подготовки отчетов.
  
  лекция [1,6 M], добавлен 15.03.2014
  

• Компьютерное программное обеспечение, предназначенное для управления проектами

  Теоретические основания анализа компьютерного программного обеспечения. Анализ основных ведущих компаний по производству программному обеспечению для управления проектами, таких как Primavera, Spider Project, Open Plan Professional и Microsoft Project.
  
  курсовая работа [33,3 K], добавлен 11.05.2014
  

• Программная реализация надстройки над системой управления проектами "YouTrack"

  Изучение возможностей системы YouTrack. Аналитический обзор ее аналогов и их функциональности. Анализ требований к системе управления проектами и надстройке. Визуализация данных. Проектирование интерфейса надстройки. Определение технологий реализации.
  
  курсовая работа [2,3 M], добавлен 13.09.2017
  

• Информационные системы управления проектами

  Принцип работы и задачи информационных систем управления проектами. Методы критического пути, анализа и оценки планов. Сетевые модель и график, виды путей. Информационный обмен между предприятиями, классификация информационных систем и их рынки сбыта.
  
  контрольная работа [17,0 K], добавлен 18.11.2009
  

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

  Разработка системы автоматизации рабочего места руководителя по управлению проектами в сфере производства отдельных видов продукции. Учет и оперативное регулирование поставок для проектов и подготовки стандартных документов: ведомостей и накладных.
  
  курсовая работа [742,9 K], добавлен 19.11.2010
  

• Управение проектами средствами Microsoft Project

  Характеристика основных методик управления проектами, их отличительные особенности, критерии и обоснование выбора, анализ информационных технологий. Анализ возможностей, предоставляемых программой Microsoft Project, ее экономическая эффективность.
  
  дипломная работа [4,6 M], добавлен 28.06.2010
  

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

  Разработка методов сетевого планирования как способа управления проектами. Характеристика компьютерных программ Microsoft Project Server, Time Line and Sure Trak Project Manager, Open Plan, Primavera и Spider Project для автоматизации работы предприятий.
  
  реферат [152,4 K], добавлен 10.02.2012
  

• Разработка систем управления проектами по средствам Web интерфейса

  Методы и алгоритмы построения инструментариев для разработки систем управления проектами посредством Web интерфейса. Составление модели обработки информации "как должно быть". Годовой экономический эффект и прочие показатели экономической эффективности.
  
  дипломная работа [1,1 M], добавлен 28.09.2015
  

• Разработка SaaS-системы для успешного выполнения проектов

  Основные понятия электронно-вычислительных сетей. Стандарты проектного управления. Электронный проектный офис как система поддержки принятия решений. SaaS-приложения для управления проектами. Факторы, воздействующие на оператора ПК. Диаграмма базы данных.
  
  дипломная работа [1,5 M], добавлен 15.10.2013
  

• Проектирование информационной системы управления образовательной деятельностью по дисциплине "Управление программными проектами"

  Проектирование корпоративных информационных систем. Автоматизация процесса выполнения лабораторных работ по дисциплине "Управление программными проектами". Построение модели ИС учебного процесса: архитектура, формализация пользовательских требований.
  
  дипломная работа [1,1 M], добавлен 20.08.2017
  

• Инструментальные средства автоматизации процесса реализации инновационных проектов

  Ознакомление с современным состоянием и проблемами развития российской инновационной среды. Разработка системы автоматизации управления инновационными проектами на предприятиях. Рассмотрение интерфейса программного продукта и руководства пользователя.
  
  курсовая работа [2,8 M], добавлен 09.04.2012
  

• Модели проектных групп

  Применение промышленных технологий создания программного продукта. Описания принципов, методов, применяемых процессов и операций. Общие понятия методологии разработки программного обеспечения (ПО). Сравнение современных методологий проектных групп.
  
  курсовая работа [1,6 M], добавлен 04.12.2009
  

• Инструментальные средства разработки и реализации системы управления сайтом

  Исследование организационной структуры ООО "Трансэнергосервис". Обзор методологий проектирования интернет-представительства. Инструментальные средства разработки и реализации системы управления сайтом: разработка интерфейса пользователя и web-сайта.
  
  дипломная работа [1,7 M], добавлен 10.08.2014
  

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам