Дипломная работа: Автоматизация контроля исполнения задач по проектам в ООО «Норс Студиос»
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
37
В указанных программных средствах присутствует примерно равный
функционал. А именно:
1. Создание карточек задач;
2. Перемещение задач между этапами ("Запланировано", "В работе",
"Готово");
3. Прикрепление исполнителей к задачам;
4. Отслеживание задач.
Данный функционал крайне необходим при использовании так
называемых "канбан-досок", чем по факту данные продукты и являются. Они
позволяют заводить задачи, перемещать их по статусам готовности, назначать
ответственных и разумеется вести статистику. Однако, в рамках поставленных в
бизнесе-процессе задач этот функционал не отвечает требованиям, а в некоторых
случаях избыточен.
Примером избыточного функционала в случае "Норс Студиос" является
возможность прикрепления исполнителей задач. В пайплайне (разъяснение
приводится далее по тексту) компании предусмотрено использование малых
команд, которые отвечают за строго определенный набор задач, которые
необходимо решать. Для определения таких задач существуют в компании так
называемые "Флоу" (от английского Flow - поток). Каждая команда отвечает за
свой Флоу, а каждый сотрудник команды отвечает за свой этап данного Флоу.
Таким образом получается некий трубопровод (отсюда и понятие пайплайна -
английское Pipeline переводится как трубопровод), на каждом вентиле которого
находится определенный сотрудник.
Отсюда можно сказать, что используя вышеописанные средства,
компании тем не менее придется использовать отдельно взятого сотрудника для
формирования дорожной карты проектов, поскольку механизм канбана не
позволяет в полной мере осуществлять контроль исполнения задач в
долгосрочной перспективе и на базе полных сведений о проекте (например, для
того, чтобы оценить текущие успехи и будущие цели проекта необходимо будет
38
просмотреть или несколько канбанов или же заранее сформировав удобно
отсортированный список).
Соответственно, в данном дипломном проекте должна быть
осуществлена разработка технологии автоматизации процесса экспортирования
задач в дорожную карту для автоматизации контроля их исполнения в проектах
"Норс Студиос", что, в свою очередь, ускорит процесс публикации обновленных
сведений, снизит риск утечки информации, которая не должна быть
предоставлена никому кроме сотрудников компании, и повысит обратный отзыв
о деятельности компании со стороны конечного потребителя. При этом
руководство компании получит удобный инструмент для контроля этой
деятельности.
1.3.2 Выбор и обоснование стратегии автоматизации задачи
Стратегией автоматизации задачи в случае с компанией "Норс Студиос"
была выбрана стратегия автоматизации по участкам, поскольку она позволяет
автоматизировать задачу с минимальными финансовыми вложениями и дает
сильный экономический эффект за счет последующего уменьшения штата
сотрудников.
Данная стратегия позволяет автоматизировать одну из задач в бизнес-
процессе, что в свою очередь в случае компании "Норс Студиос" также в
значительной мере изменит и сам бизнес-процесс. Это задача выгрузки данных
из единого реестра задач в компании с последующим формированием дорожной
карты. Данная задача тесно связана с другими задачами в бизнес-процессе, а
именно:
1. Создание задач;
2. Контроль исполнения задач;
3. Публикация дорожной карты.
В данный момент эта задача выполняется отдельным сотрудником
(копирайтером) и изредка привлечение сторонних сотрудников для уточнения
деталей по задачам.
39
Выбор этой стратегии обуславливается следующими причинами:
1. Значительное снижение ресурсозатрат компании при
автоматизации контроля исполнения задач по проектам;
2. Повышение оперативности публикации обновленных данных.
1.3.3 Выбор и обоснование способа приобретения ИС для автоматизации
задачи
Существует несколько различных способов приобретения
информационной системы для автоматизации поставленной задачи. К ним
относятся:
1. Приобретение стороннего готового решения в виде самодостаточного
программного обеспечения;
2. Приобретение стороннего самодостаточного программного
обеспечения с дальнейшей доработкой;
3. Приобретение стороннего решения в виде индивидуальной разработки
программного обеспечения под нужды и условия компании;
4. Приобретение продукта в виде собственной внутренней разработки
программного обеспечения.
Среди представленных решений, исходя из уже высказанного в данной
дипломной работе анализа существующего программного обеспечения, можно
сразу вычеркнуть вариант с приобретением готового продукта, поскольку таких
на рынке в данный момент не представлен.
Приобретение стороннего продукта с последующей доработкой также
является не оптимальным вариантом, поскольку бóльшая часть представленного
на рынке программного обеспечения является закрытым проприетарным
решением, внесение изменений в который не предусматривается продаваемым
лицензиям. Покупка с последующей разработкой модуля расширения же в свою
очередь обойдется в значительную сумму и в конечном итоге приведет к тому,
что разработка собственного решения будет экономически выгоднее.
40
Если обращаться к индивидуальной разработке, то стоит обратить
внимание на наличие корпоративной экосистемы и огромное количество
требований к реализации. Это приведет к значительному повышению цены
готового продукта и необходимого на его реализацию времени, поскольку
сторонней компании необходимо ознакомится со всеми требованиями,
экосистемой и рутине сотрудников (иначе говоря понять UX компании).
Собственная разработка имеет позитивный опыт, если говорить о
разработке внутри экосистемы и пользовательском опыте. Однако собственная
разработка занимает большое количество внутренних ресурсов компании,
включая не только инженеров, но и техническое обеспечение.
Основываясь на вышесказанном, была разработана сравнительная
таблица, представленная в таблице 6. Для оценки используется пятибалльная
система, где 5 - наивысший балл, а 1 - наименьший. Наиболее оптимальное
решение находится путем поиска максимума из сумм всех строк у каждого
варианта
Таблица 6
Сравнительный анализ способов приобретения
Вариант
приобретения
Расширяемость
Модульность
Стоимость
разработки
Время
разработки
Внедрение в
экосистему
Готовое решение
1
3
4
5
2
Готовое решение
плюс доработка
2
4
3
2
3
Заказное решение
4
3
1
1
4
Собственная
разработка
5
5
2
3
5
Исходя из полученных сведений можно сказать что самым оптимальным
решением будет разработка программного обеспечения собственными силами и
41
ресурсами компании, а учитывая основную деятельность предприятия
(разработка программного обеспечения) можно быть уверенным в качестве
разрабатываемого продукта и его полное соответствие потребностям компании.
1.4. Обоснование проектных решений
1.4.1 Обоснование проектных решений по информационному обеспечению
По выясненным ранее причинам было выбрано проектное решение,
включающее в себя собственную разработку программного продукта. К данным
причинам относятся:
1. Отсутствие на рынке готового решения удовлетворяющего
потребностям компании;
2. Необходимость возможности гармоничного встраивания в экосистему
компании и пайплайны сотрудников;
3. Необходимость интеграции с внутренними продуктами (встраивание в
экосистему с обратной связью);
4. Глубокое понимание внутренних процессов компании;
5. Функциональная независимость от сторонних компаний как
дополнительная причина, способствующая повышению безопасности
информационных активов.
Для информационного обеспечения реализации поставленной задачи
необходимы следующие объекты:
1. Входные и выходные документы;
2. Графический интерфейс соответствующий дизайн-линии компании
для ввода необходимой информации из входных документов,
настройки метода их обработки и вывода результирующих данных о
статусе обработки поданной информации;
3. Классификация и кодирования документов;
4. Информационная база данных;
Источник: https://baza.diplomsite.ru/previewfile/407