CC BY
114
УДК 004.023
СТРАТЕГИЯ УПРАВЛЕНИЯ МЕДИА-ПРОЕКТАМИ
В 1Т-ОРГАНИЗАЦИИ
Кублашвили Оксана Вячеславовна
доцент кафедры экономики и менеджмента медиабизнеса, кандидат экономических наук Московский государственный университет печати имени Ивана Федорова 127550 Россия, г. Москва, ул. Прянишникова, д. 2А [email protected]
Иванова Юлия Сергеевна
студентка института коммуникаций и медиабизнеса Московский государственный университет печати имени Ивана Федорова 127550 Россия, г. Москва, ул. Прянишникова, д. 2А daisywheel_92@inbox. гы
Аннотация. Проанализирована разработка стратегии управления проектами. Авторы рассматривают стратегию медиапроектирования с точки зрения ее эффективности и структуры. Представлены основные положения методологии реализации программы, концепция модели стратегического планирования в 1Т-организации.
Ключевые слова: управление проектами, информационные технологии, медиа, медиа проекты, стратегия управления.
Для укрепления положения компании на рынке разрабатывается специальный управленческий план — он называется стратегией. Основная задача стратегии — разработка направлений развития деятельности организации, достижение поставленных целей, план привлечения новых потребителей и сохранение существующих.
Проект — совокупность действий, которые направлены на достижение и/или разработку определенных решений в рамках обозначенного времени и ресурсов, взаимосвязь этих действий и их координированное выполнение.
Однако проект, в отличие от производственной системы является однократной деятельностью, хотя в последнее время имеет место тенденция применения проектного подхода к процессам производственных систем.
Управление проектами — специализированная область менеджмента, суть которой в координировании проектной (временной) деятельности, балансирование между ресурсами, временем, целями проекта и другими факторами, что в итоге приводит к достижению уникальных результатов. Отличительными признаками проекта являются ясно сформулированные цели, которые будут достигнуты после выполнения ряда требований (технических, экономических и других): координация взаимосвязи задач, ресурсов; сроки начала и окончания проекта; ограниченные ресурсы; уникальность целей проекта и условий его осуществления; форс-мажорные ситуации и пути их преодоления.
Концепция управления проектами — основа современного подхода к объекту управления (Project Management). На сегодняшний день управление проектами — признанный многими странами способ осуществления инвестиционной деятельности.
Основные принципы управления, применимые к проектам:
1. Планирование. Это оптимальное определение задач для достижения конечных целей. Это процесс прогнозирования, установление различных показателей развития, разработка плана возможных действий в определенных ситуациях
2. Организация. Управление проектом подразумевает подбор необходимых средств для выполнения запланированных задач. Эти средства называются ресурсами. Ими могут быть люди, финансы, материальные составляющие и все, что может понадобиться для реализации проекта. Помимо ресурсов, организация проектного управления включает разработку четкой структуры, необходимой для выполнения плана, в которую будут объединены все подобранные ресурсы.
3. Контроль. Когда создана единая структура проекта, необходимо сопровождать ее во время реализации и осуществлять контроль. Контроль — определенная система отчетности в рамках жизненного цикла проекта. Важно понимание того, что отчетность — это не просто хронология процессов проекта, а инструмент для обнаружения и своевременного исправления всевозможных отклонений от плана и незапланированных ситуаций.
4. Изменения. В большинстве проектов после осуществления контроля, выявляются ситуации, требующие внесения изменений в основной план. Существуют специальные процессы внесения изменений (графики Ганта, тесты для сопровождения проекта и др.), которые являются составными частями хода управления проектом [10].
Исходя из этого, можно рассматривать управление проектом как процесс осуществления действий, которые используются для планирования, организации, анализа и контроля поставленных целей, и заданий, внесение в них изменений с целью реализовать ко-
нечный продукт, услугу или мероприятие в заданные сроки и в рамках заданных ресурсов.
Для управление реализацией IT-проекта на основе этих принципов был разработана стратегия «Четырех ступеней реализации ГГ-проекга». Каждая ступень стратегии разбивается на этапы, а этапы, в свою очередь, разбиваются на предлагаемые дальнейшие действия.
Ступень 1. Планирование. Стратегический уровень является очень важным для проекта, однако, часто возникает ошибочное мнение, что главная задача управления проектом — в его планировании. В действительности, планирование должно сопровождать проект, выполняться на протяжении его жизненного цикла, а его сущность состоит в создании целей и разработке способов их достижения с помощью работ, действий, мероприятий, которые будут осуществляться.
На уровне планирования в проекте определяются:
• основные этапы, производственные мощности, сроки начала работ (тайминги);
• оценка технического задания и сопоставление его с таймингами;
• сроки завершения работ, сроки на доработку проекта, если возникнет такая необходимость;
• временные ресурсы, выделенные для подготовки работ;
• подбор аутсорс-организаций и оценка их производственных мощностей;
• потребности в ресурсах с распределением по годам и предполагаемым срокам реализации проекта.
В ходе создания иерархии и содержания проекта разрабатывается иерархическая структура работ (Work Breakdown Structure). Она помогает «уточнить» составляющие проекта и имеет два вида:
• «верх-низ» (Top-down approach или метод дедукции) — определяются общие задачи, на основе которых далее осуществляется детализация уровней проекта;
• «низ-верх» (Bottom-up approach или метод индукции) — определяются частные задачи, а затем происходит их обобщение.
Такая структуризация помогает увидеть логическую последовательность промежуточных процессов и этапов и выявляет их направленность (ненаправленность) к конечным целям проекта, что позволяет непродуктивные части плана переработать, дополнить или исключить.
Ступень 2. Определение (инициация). Инициацией называется процесс утверждения проекта на формальном уровне. Суть определения проекта состоит в разработке его устава (и его утверждения).
В уставе содержится важная информация о проекте, которая имеется на данный момент. Смысл этого документа в том, чтобы помочь руководителям принять решение о запуске или отказе от проекта.
Помимо этого, устав проекта имеет следующее предназначение:
• информация о проекте для заинтересованных лиц (например, для инвестора или других руководителей);
• задание направления работ;
• определение возможностей, угроз, сильных и слабых сторон проекта.
При положительном решении о реализации проекта, устав становится базой для разработки детализированного плана работ. Данный документ служит справочным материалом по всем вопросам о проекте, по вопросам будущего направления работ. Устав содержит также информацию о правилах подбора персонала на проект. Помимо этого, устав является средством контроля для сообщения о состоянии работ и средством проверки оценки его эффективности в достижении поставленных целей и выполнении поставленных задач. В конечном итоге, устав проекта будет являться динамичным средством для проведения действий по планированию и внесению изменений, необходимость в которых, скорее всего, возникнет.
Тест для Устава проекта (проводится для каждого отдельного проекта) должен быть понятен для постороннего человека.
Устав проекта может быть использован для убеждения в продуктивности проекта (инвестора, руководство и т.д.). Его можно использовать для разработки плана действий.
Руководитель проекта будет планировать, реали-зовывать и управлять Уставом проекта.
Ядро группы, работающей над проектом, рассматривает и одобряет Устав проекта [41.
Ступень 3. Составление списка частных целей
Основные задачи проекта выполняются для достижения одной или нескольких его целей. Такие задачи называются частными целями или «вехами» проекта (его основными компонентами). Частные цели задают основное направление работ, поэтому они не являются конкретными рабочими заданиями, их сложно назвать вспомогательными.
Задание частных целей помогает представить проект в виде множества его основных составляющих. Они помогают получить общее представление о проекте, а это, в свою очередь, помогает лицам принимающим решения, и другим членам группы управления понять масштабы проекта. Они также служат основой для определения потребности в ресурсах и составления графика работ [2].
Частные цели формулируются более точно, чем основная цель, ориентированы на конкретные действия. То есть для достижения одной главной цели необходимо осуществить все множество частных целей. Для понимания принципа частных целей предлагается метод 8.М.А.Я.Т. (табл. 1).
Таблица 1. Детализация метода Б.ЫЛ.К.Т
Specific Точность постановки целей
Measurable Измеримость показателей состояния работ
Assignable Возможность перепоручения задания
Realistic Возможность определить, какие задания могут быть реально выполнены в срок и в рамках выделенных ресурсов
Time-releated Определение продолжительности выполнения задачи
Ступень 4. Критерии для определения успешности проекта.
Критерии определения успешности IT-проекта формулируются до его начала и утверждаются всеми заинтересованными сторонами.
На этой ранней стадии подготовки проекта специальная группа планирования может начать консультации с отдельными сотрудниками или группами, которые примут участие в проекте, для составления предварительного списка критериев успеха, по которым будут оцениваться результаты работы. Далее приведен список критериев оценки успешности IT-проекта.
Реализация ключевого функционала.
Этот критерий указывает на потребность клиента получить качественный и уникальный продукт. Данный критерий подразумевает описание функций, без которых запуск системы будет нецелесообразным. Однако, в силу своей обобщённости, этот критерий подходит только для небольших (2-4 месяца) или стандартизированных проектов.
Время запуска в эксплуатацию.
Срок выполнения проекта для многих заказчиков зачастую является даже более приоритетным, чем стоимость работ. В связи с этим, в большинстве случаев, устанавливаются жесткие рамки реализации проекта (deadline), что в свою очередь создает некоторые риски для проектной команды, связанные с длительным согласованием каждого этапа, возможными конфликтными ситуациями. Часто получается так, что частная цель «Проект сдан» не равна «Проект введен в эксплуатацию», что может сказаться на показателях успешности проекта. В связи с этим, рекомендуется в качестве критерия успешности использовать время запуска в эксплуатацию, вместо общего срока сдачи проекта.
Востребованность пользователями.
Данный критерий позволяет оценить качество внедрения системы или проекта. На самом деле, оценить предварительно востребованность пользователями IT-системы весьма затруднительно. И объективная его оценка возможна только через несколько месяцев после внедрения. Это трудозатратный аудит, но, тем не менее, очень показательный.
Соблюдение бюджета проекта.
Это не самый объективный показатель успешности проекта, но и пренебрегать им нельзя. Бюджет проекта рассчитывается на самых ранних его стадиях, поэтому его несоблюдение может значить неэффективную стратегию изначально. Больше всего критерий востребован, если в проект инвестированы заемные средств.
Это не самый объективный показатель успешности проекта, но и пренебрегать им нельзя. Бюджет проекта рассчитывается на самых ранних его стадиях, поэтому его несоблюдение может значить неэффективную стратегию изначально. Больше всего критерий востребован, если в проект инвестированы заемные средств.
Эффективность вспомогательных процессов.
Показатель соразмерности автоматизированных процессов и процессов, выполняемых персоналом, а также степень эффективности подрядчиков.
Ступень 5. Анализ требований к IT-проектам
Управление изменениями требований Управление требованиями и определение требований — основа успеха IT-проекта. По данным исследования, проведенного компанией IBM в области IT [8], 60% затрат времени разработчики программного обеспечения несут в результате неэффективного подхода к управлению требованиями. В организациях, пренебрегающих аналитикой, проекты в 3 раза чаще заканчиваются неудачей, чем успехом. Верное определение требований снижает расходы по проекту до 20%, так как сокращается количество некорректных, неполных, неэффективных требований.
Для управления требованиями следует разобраться в терминологии:
Управление требованиями — процесс, включающий идентификацию, выявление, документацию, анализ, отслеживание требований, достижение соглашений по требованиям и затем управление изменениями и уведомление заинтересованных лиц. Управление требованиями является постоянным процессом на протяжении всего жизненного цикла проекта.
Требование — это условие, которому должен соответствовать IT-проект. Требованием может быть возможность, которой проект должен обладать и ограничение, которому он должен удовлетворять.
В соответствии с Глоссарием терминов программной инженерии [1], являющимся общепринятым между народным стандартным глоссарием, требование — это:
• условия или возможности, необходимые пользователю для решения проблем или достижения целей;
• условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;
• документированное представление условий или возможностей для пунктов 1 и 2.
• Требование должно обладать следующими характеристиками:
• единичность — требование описывает одну и только одну вещь;
• завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует;
• последовательность — требование не противоречит другим требованиям и полностью соответствует документации;
• атомарность — требование нельзя разделить на более мелкие;
• отслеживаемость — требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и задокументировано;
• актуальность — требование не стало устаревшим с течением времени;
• выполнимость — требование может быть реализовано в рамках проекта;
• недвусмысленность — требование определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объекты и факты, а не субъективные мнения. Возможна одна и только одна его интерпретация.
Определение не содержит нечетких фраз, использование отрицательных и составных утверждений запрещено:
• обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования;
• проверяемость — реализованность требования может быть проверена.
В настоящее время распространение получили такие системы управления требованиями как IBM Rational RequisitePro, Telelogic DOORS, Sybase PowerDesigner [7].
Анализ требований включает: выявление и поиск решений по преодолению конфликтов между требованиями; определение границ задачи, решаемой IT-проектом; определение границ и содержания IT-проекта; детализацию системных требований и определение программных требований.
При этом в качестве результата анализа требований должны быть представлены только такие, которые могут быть интерпретированы: их реализация должна быть проверяемой, ресурсы и бюджет — подлежащими подсчету.
Параметры классификации требований:
• функциональные и нефункциональные;
• внутренние (имеющие другие требования) или внешние зависимости;
• требования к процессу или продукту;
• приоритет требований;
• содержание требований в отношении конкретных подсистем IT-проекта;
• изменяемость/стабильность требований. Существуют и другие варианты классификации —
они зависят от принятых в каждой отдельной организации подходов, методологий, практик и, конечно, специфики IT-проектов. Так же на подобную классификацию могут влиять требования заказчика к процессам разработки и формам предоставления отчетности.
Преодоление сложности многофункциональности требований.
Существует распространенная сложность при разработке IT-проекта. Характеристика различными источниками будущего проекта с разных сторон создает многие помехи при его реализации. Эта сложность именуется многофункциональностью требований.
Руководителю проекта важно понимание источников, которые могут предъявлять требования (помимо заказчика). Как правило, создается специальная группа, которая представляет интересы инициаторов проекта, и ее задача — выявление проектных перспектив, согласование различных требований к реализуемому проекту.
Это может быть реальная группа лиц, если у компании есть возможность их содержать, эпизодически собирающийся или дистанционно общающийся коллектив или даже просто ролевой кластер, заполняемый сотрудниками проекта. Примерный состав ролей такой группы следующий:
• представитель заказчика — отслеживает и представляет интересы тех, от кого получен заказ на разработку;
• представитель пользователя — отражает взгляд на систему со стороны пользователя;
• инвестор — предъявляет требования тех, кто вкладывает средства в разработку;
• менеджер по продажам — предъявляет требования со стороны распространения программного изделия;
• покупатель — предъявляет требования с точки зрения покупательского спроса.
Данная группа формируется с учетом эффективных контактов и координирования с разработчиками, группа осуществляет деятельность отдельно от проектной. Результат ее деятельности — аудит требований, их экспертиза. Производится проверка и оценка точек зрения по проекту (в том числе и внешних), производится расстановка приоритетов [3].
Взаимодействие с группой инициаторов со стороны исполнителей проекта осуществляется сотрудниками, выполняющими следующие роли: менеджер проекта; эксперт предметной области; специалист по пользовательскому интерфейсу; архитектор и проектировщики подсистем в качестве специалистов, отражающих реализационные аспекты разработки; тестировщики, ответственные за проверку работоспособности системы с точки зрения ее соответствия требованиям.
Ответственность по работе с требованиями, организации информации о них и ее хранение возлагается на разработчика IT-поддержки и делопроизводителя проекта.
Разработчик определяет виды доступа к информации: запросы к базе данных проекта, сохраняющей все сведения о требованиях, второй осуществляет администрирование этой базы.
Если такая группа не предполагается, то ее роли выполняют разработчики, указанные в качестве тех, кто взаимодействует с инициаторами работ.
Методология достижения понимания и изучения многофункциональности требований (а в конечном счете, потребностей пользователя или потребителя) включает мозговые штурмы, изучение прототипов, анкетирование, опросы и т.д. В качестве результата изучения таких сведений составляется список классифицированных требований в виде текста и/или ин-фографики, и уже из данной классификации, в порядке приоритетности, определяются требования для текущего проекта или разработки [5]. Составление спецификации проекта «Спецификация программных требований» или «Software Requirements Specification» (SRS) — термин, употребляемый для сложных систем/проектов. Он подразумевает под собой комплекс документов, требований, спецификаций для IT-проектов.
Эти документы систематически анализируются, в них вносятся изменения, они пересматриваются и утверждаются. Чаще всего, для описания комплексных проектов (в части требований) используется три основных вида документа: определение системы (system definition); системные требования (system requirements); программные требования (software requirements) [6].
Стратегический системный подход к управлению 1Т-проектами выделяется рядом преимуществ в сравнении с другими подходами, например, когда управление проектом происходит неформально — менеджер, не отвечающий за 1Т-проекты, пытается координировать команду разработчиков в качестве дополнительной функции к своей должности.
Системное, формализованное и стратегическое управление проектами выигрывает по той причине, что при его использовании шанс на успех каждого отдельного проекта возрастает в несколько раз.
Каждый проект успешно выполняется, а конкретные результаты достигаются в соответствии с принятым графиком и в рамках установленного бюджета. При реализации отдельного проекта способность организации вести успешную деятельность и ее общая ценность объективно возрастают.
Среди основных причин успешного применения принципов нового подхода к управлению проектами можно выделить следующие:
• компания принимает к реализации только те проекты, которые соответствуют уставу проекта, проекты, эффективность которых подтверждена анализом требований и т.д.;
• решение о возможности реализации принимаются только для реально осуществимых проектов: технических, бюджетных и реализуемых по срокам;
• ответственность за управление портфелями проектов, программами и проектами тщательно распределена и реализуется;
• каждый проект планируется, исполняется и контролируется (управляется) так, чтобы все обязательства по нему были выполнены;
• команды управления проектом должны работать совместно и в соответствии с обязательствами по целям, планам и графикам исполнения проекта [9].
БИБЛИОГРАФИЧЕСКИЙСПИСОК
1. ISO/IEC 2382-1:1993 Data processing [Электронный ресурс] — Режим доступа: http://www.iso.org/ iso (дата обращения: 20.03.16).
2. Зиссер Ю.А., Мелещенко А.А. Управление разработкой и продвижением программного обеспечения: учеб. пособие. — Минск, 2012.
3. Масловский В.П. Управление проектами: конспект лекций. — Красноярск: Сибирский федеральный университет, 2011. — 179 с.
4. Спецификация требований [Электронный ресурс] — Режим доступа: http://www.itbusiness.ru/?p=36 (дата обращения: 20.03.16).
5. Скопин И.Н. Основы менеджмента программных проектов — М.: Интернет-университет информационных технологий, 2006. — 336 с.
6. Управление требованиями к IT-проектам [Электронный ресурс] — Режим доступа: http://habra-habr.ru/post/114571 (дата обращения: 20.03.16).
7. Определение требований как основа эффективности поставки программного обеспечения [Электронный ресурс] — Режим доступа: https://www. ibm.com/developerworks/ru/library/ws-soa-bddhealth (дата обращения: 20.03.16).
8. Как улучшить управление ИТ-проектами в организации [Электронный ресурс] — Режим доступа: https://www.infostart.ru/public/418073 (дата обращения: 20.03.16).
9. Weiss J., Wysocki R. 5-phase Project Management. London, Bentley College, 2011.
10. Попов Д.И., Попова Е.Д., Некрасов А.В. Информационные технологии в издательском деле и полиграфии: основы проектирования баз данных — М.: МГУП имени Ивана Федорова, 2015. — 165 с.
MEDIA PROJECT MANAGEMENT STRATEGY IN
IT-COMPANY
Oksana Vyacheslavovna Kublashvili
Moscow State University of Printing Arts 127550 Russia, Moscow, Pryanishnikova st., 2А
Yuliya Sergeevna Ivanova
Moscow State University of Printing Arts 127550 Russia, Moscow, Pryanishnikova st., 2А
Annotation. Аnalyzed the development of the project management strategy and media projects management. The author examines the management strategy in terms of its efficiency and structure. The paper describes the main provisions of the project methodology, the concept and methods of creating project management strategy, its planning from the perspective of IT-organization. The appendix contains a management strategy developed media projects in the IT-organization.
Keywords: project management, information technologies, media, media-projects, management strategy.
