62
нужно лишь задать определенные критерии: ключевые слова, целевую аудиторию,
промежуток времени и т.д. Программа автоматически проведет сбор и анализ
данных, которые пользователи размещают на своих страницах, форумах или в
электронных СМИ. Сервисы также предоставляют самый широкий спектр
возможностей: определение тональности высказываний, визуализация данных
посредством графиков и карт, предоставление информации по охвату аудитории
(сколько человек прочитали данное сообщение?), возможности получения данных о
конкретном респонденте и связи с ним, а также многое др.
Однако на сегодняшний день возможности электронного мониторинга
практически не используются социологами. Сервисы позиционируются как системы
для маркетинговых исследований, поиска клиентов и анализа популярности своего
бренда, поэтому информация о них в основном изложена в виде рекламно-
ознакомительных статей [1] и топ-листов [2, 3]. Крайне мало книг и печатных
изданий. Едва ли не исключением в этом сегменте стала книга Д. Халилова
«Маркетинг в социальных сетях» [4].
Нами было проведено исследование, в ходе которого сравнивались различные
сервисы мониторинга социальных сетей. На основании результатов работы каждый
исследователь-социолог сможет выбрать наиболее оптимальный, необходимый
именно для его целей инструмент.
Для сравнения было выбрано шесть различных сервисов, функционирующих
на данный момент исследования: IQBuzz, «Крибрум», Semantic Force, Wobot,
YouScan. Сравнительные характеристики и оценки в работе представлены на
основании описания, рекомендаций, отзывов, общения с представителями и
самостоятельной работы с программами в демо-доступе.
В ходе исследования было выявлено, что большинство систем обладают
примерно одинаковым спектром возможностей, отличаясь лишь некоторыми
функциями и дизайном. Данные по сравнению характеристик представлены в
таблице. В качестве основного различия можно назвать количество
предоставляемых тем/документов исследований (зависит от выбранного пакета),
также необходимо обратить внимание на количество работников, которые могут
быть задействованы в исследовании (зависит от выбранного пакета).
Таблица 2.18
63
Сравнение сервисов
Параметры
Название
IQBuzz
«Криб-
рум»
Semantic
Force
Wobot
YouScan
География
распределения
(карта/ список)
+
+
+
+
+
Экспорт
исследования в
Microsoft Office
+
+
+
+
+
Возможность
редактирования
исследования в
системе
+
+
+
+
+
Сортировка и
группировка
упоминаний
(документов)
+
+
+
+
+
Доступ
информации о
каждом
респонденте в
системе
+
+
+
+
+
Сортировка/
отключение
заблокированных и
удаленных страниц
+
+
+
+
+
Доступные
социальные сети
для анализа
Все, кроме
«Одноклассников»
Все
Все
Все
Все
Определение
тональности
высказываний
+
+
+
+
+
Определение
первоисточника
+
+
Нет
данных
+
+
Предоставление
примеров
исследований
+
+
+
+
+
Ретроспектива
исследований
С любого времени
Нет
данных
Месяц
архивных
данных (в
демо-
доступе)
С
2005
г.
С
любого
времени
Цена в месяц
От 7900 ру
б
.
Индиви
дуально
От 250
долл.
От
6000
ру
б
.
От 1 990
долл. в
год
64
Количество тем за
минимальную
цену
3
Индиви
дуально
Нет
данных
5
5
Помимо заявленных характеристик, нужно также отметить точность
получаемых результатов. Важнейшим для социолога критерием выбора системы
является наиболее полная выдача результата по заданным критериям. Однако ни
одна система не идеальна, и часть данных упускается, т.е. при «ручном»
мониторинге можно найти больше информации. Был проведен тест: при
использовании демо-версии в каждый инструмент были заданы одинаковые условия
поиска, сравнивалось количество полученных результатов. Меньше всего
совпадений нашел Wobot; YouScan незначительно отстал от IQBuzz (разница в
несколько единиц); чуть выше оказались результаты остальных трех систем.
Наибольшее количество упоминаний обнаружил сервис Semantic Force.
65
3 ОЦЕНКА СТОИМОСТИ ПРЕДЛАГАЕМЫХ МЕРОПРИЯТИЙ И
ИХ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ
3.1 Расчет стоимости предлагаемых мероприятий по продвижению
интернет-магазина
Эффективность использования определенных видов маркетинговых
коммуникаций зависит от типа целевой аудитории, на которое направлено послание,
специфики продукта, а также от отрасли, в которой функционирует компания. Стоит
отметить, что категории целевых аудиторий воспринимают различные виды
маркетинговых коммуникаций по-разному.
Для разработки проекта плана маркетинговых мероприятий необходимо
использовать Agile.
Среди явных проблем процесса создания проекта можно выделить такие:
• Корректировка требований относительно процесса создания;
• Разделение ответственности за реализуемую работу и ее результат;
• Доступность потока мелких, срочных, приходящих требований,
отвлекающих программистов и управленцев от базового направления работ.
• Срыв срока, повышение расходов, потери качественного уровня.
Чтобы реализовать успешную организацию процесса создания, подготовлена
универсальная процедура создания проектов.
Модели, методики и подходы универсального управления проектами имеют
свое развитие в рамках сложных технических проектов, которые заключаются в
реализации больших программных комплексов. Универсальное управление можно
рассматривать как некую платформу, которая находится в рамках нескольких
методик контроля инновационными, а самое важно, ИТ проектами. Базовая суть
универсального управления проектами описана в работах Дж. Хайсмита [1], Г.
Аллемана [8], Г. Чина [11]. Сравнение разных прикладных методологий
универсального управления новейшими проектами также есть в трудах К. Лармана
[27] и П. Абрамсона и других [5]. Моментный подход к определяю наилучшей
методики универсального управления проектами указан ив работе А.С.Коха [3].
Дж. Хайсмит выделяет базовое качество данного подхода так: «Гибкость
(аgility) - это возможность сразу и создавать, и отвечать на корректировки, создавая
66
прибыль в изменчивых условиях экономики. Гибкость становится способностью
держать баланс между стабильностью и хаосом» [16]. Также он пишет, что: «Часто
многие склонны верить, что подвижность говорит об отсутствии структуры. Но
такое отсутствие порождает хаос. Также, избыток некой упорядоченности несет за
собой жесткость. Теория сложности описывает то, что процесс создания инновации
методами, которые не определены заранее, часто реализован в точке
соприкосновения порядка и хаоса, гибкости и стабильности. По словам ученых,
реализация нового возможна на границе хаоса [16]. Но на нахождение такого
баланса между порядком и хаосом и будут направлены все возможности
универсального управления проектами. Причем следует оно от упорядоченности
процессов, инструментов и методик, которые есть в традиционных школах
проектного управления в рамках деконструкции, деструктуризации множественных
упорядоченных реализованных условий протекания проектов, к выработке
понятных и логичных (направленных на персонал методов и инструментов, которые
имеют возможность плавно приспособиться к изменчивым условиям). Если
классическими параметрами управления проектами описывались планирование,
улучшение и отслеживание, то универсальное управление проектами основными
усилиями будет считать естественную эволюцию и приспособление.
В 2001 году основатели и последователи части близких по духу и сути
методик управления ИТ-проектами создали свод правил универсального контроля
проектами. Данный свод описал 4 базовые идеи и 12 параметров [17]. Создатели
свода правил, почитатели методик экстремального программирования, скрама,
адаптивного создания проектов и т.п., сознательно не стали сводить универсальное
управление проектами к моделям, инструментарию и средствам, но отразили его в
виде неких адаптационных идей и принципов, которые нужны для понятного
творческого воплощения в контексте отдельной ситуации. Суть и идеи
универсального проектного управления не нужно сводить к сложившимся законам
и правилам.
Базовая основа универсального управления заключена в:
• Персоналии и их работа важнее, чем инструмент и процесс;
67
• Применяемое ПО (в общем случае - ценный для клиента продукт или
реализуемая услуга) важнее, чем собранное документальное сопровождение (или
контроль плана бюджета);
• Работа с заказчиком важнее, чем обязательства по контракту;
• Реакция на коррективы важнее, чем простое следование плану.
Суть универсального управления проектами состоит их:
• Удовлетворенность клиента благодаря оперативной и надежной
разработки продукта, который имеет значение для клиента;
• Позитивное отношение к корректировке требований к продукту, даже
на финальной стадии, если это имеет значимую ценность для клиента и ведет к росту
конкурентных качеств продукта;
• Создание и поставка отдельно работающих модулей или обновленных
версий ПО (ежемесячно, еженедельно или чаще);
• Полноценное общение с заказчика с разработчиками в рамках всего
проекта, выходящее за рамки только контрактных обязательств;
• Повышенная мотивация участников проекта, имеющих все требуемые
материалы и средства, поддержку и доверие;
• Персональный разговор, как базовый метод передачи данных в рамках
проекта;
• Функционирующий и ценный для клиента продукт как лучший
индикатор успеха проекта;
• Все участники проекта, в особенности создатели и вдохновители,
должны без проблем поддерживать конкретный темп работы на требуемый срок;
• Рост технического мастерства исполнителей и улучшение самого
продукта;
• Переход к простоте, чтобы не реализовывать лишнюю работу;
• Самоорганизация и автономия на уровне команды проекта,
оптимальные тех. требования, дизайн и архитектура реализуются у лучше
организованной команды;
• Доступность изменений при смене обстоятельств.
Принцип схемы универсального управления проектами признается
циклическая модель ЖЦ проекта, которая разбивает проект на несколько процедур.
68
«Каждая процедура выглядит как некий программный файл в миниатюре, и состоит
из задач, которые нужны для реализации мини-прироста по скорости работы:
изучение требований, составление плана, проектирование, написание кода,
проверка, документирование. Каждая отдельная процедура зачастую не так
оправдана для реализации обновлённой версии продукта, тут понимается, что сам
по себе проект готов к реализации по факту каждой процедуры. В рамках окончания
каждой процедуры команда проводит переоценку основных задач разработки» [14].
Модель описывает, что проект проводится некое количество циклов
(процедур), и любой цикл имеет 4 фазы – определение требований, подготовка
проекта, реализация и оценивание. Любой следующий цикл ведет к корректировке
требований, изучению содержания, оптимизации продукта и процессов создания
проекта. В реальности процедурная природа универсального проекта сложнее, и
предполагает доступность перехода с этапа на этап, что часто отмечается в виде
названной хаотической модели ЖЦ проекта.
Такие понятия о ЖЦ проекта предполагают сторонний взгляд на то, что есть
в проекте. Понятно, что в отличие от классического управления проектами с
неизменно утверждёнными требованиями к итогу и границам содержания,
универсальное управление включает требования и содержание к изменённым
динамически [10]. Сама суть универсального управления проектами соответствуют
концепциям развитых и доступных проектов [7;6]. Если классические терминальные
проекты включают неизменное определение границ ЖЦ и сути проекта, при
достижении которых проект завершается, то развивающиеся проекты всегда
открыты для дальнейших корректив и изменений. Открытые проекты вообще
отражают содержание лишь в рамках общих направлений и индексов, которые
корректируют принцип выполнения.
Многие компании в РФ, которые делают бизнес на условиях уникальных или
закрытых отраслей, применяют каскадную схему реализации проектов. Плюсом
этой модели можно назвать организованность и минимизацию рисков при создании
солидных проектов. Минусом модели можно назвать управление проектами в ущерб
бюджету, длительности и качеству.
Сейчас есть ряд рисков, которые легко избегаются посредством
использования Аgile-методологий.
69
• Во-первых, риски того, что работа не будет завершена вовремя, в
рамках отсутствия плана проекта, ошибок, а также нестабильности релизов.
• Во-вторых, риски того, что реализовано не то, что требовалось, в
рамках неправильного сбора требований к проекту и малой обратной связи со
стороной заказчика. И итогом этого становится повышение времени на доделывание
проекта.
• В-третьих, это реализация самого проекта не самым удачным методом
из-за минимальной коммуникации между персоналом и разработчиками.
• В-четвертых, перестановки сотрудников ведут к тяжелому и
затратному по времени введению в курс дела всех участников проекта.
В нынешних стандартах контроля проектами — SCRUM становится одним из
самых простых в освоении и применении методом контроля проектами. Сам метод
основан на контроле процесса создания и качества итогового продукта.
Под методологией Scrum подразумевается несколько необходимых и
оптимальных компонент, ролевая модель команды и практические подходы к
созданию. В рамках процесса адаптации методологии иногда происходит замена
компонент и подбор оптимального для фирмы состава методов и средств работы с
компонентами. Далее будет описан перечень базовых компонент методологии и
факторы, которые оказывают влияние на результативность данных компонент в
рамках конкретной ситуации в компании:
• Итерация («спринт») – суть методики Scrum, которая становится
неделимым отрезком длительности более 6 недель (по стандарту Nоkiа), в рамках
которой реализуется процесс подготовки плана, создания, проверки и визуализации
функционала. Весь процесс подготовки проекта делится на такие итерации и все
задачи по проекту разделены на один или несколько спринтов.
• Беклог – очередь с приоритетами, в которую перемещают созданные
элементы в рамках работы над проектом [6]. Методика Scrum включает обязательное
присутствие беклога и поддержку его в рабочем состоянии.
• Планирование – методика отбора задач для последующего этапа из
беклога, обязательства по реализации которых берет на себя команда проекта [6].
Задачам ставится приоритет и проходит оценка по времени, число задач
70
определяется в рамках общей эффективности команды, которая была в прошедших
спринтах.
Процесс планирования становится нерезультативным, когда:
1. Нет нормальной детализации задач, есть большая команда и сложная
специфика проекта, при этом задачи трудно разбить по срокам и объему работ.
Методика Scrum включает разделение подобных задач на более мелкие, не более 12
часов [9]. В рамках тяжелой специфики работы команда часто принимает решение о
реализации дополнительных встреч по уточнению требований до начала работы над
задачей.
2. Огромная детализация задач на малом проекте, требование руководства
о четком соблюдении всех регламентов. Во избежание обширной формализации,
команда обязана иметь полномочия сама строить внутренние процессы работы в
рамках имеющегося опыта и ретроспективы.
Каждодневные собрания - важные утренние встречи, где любой член команды
в паре слов рассказывает о планах на новый день, итогах прошедшего дня и
проблемах, которые сейчас есть [9]. Длительность такого собрания обычно не более
15-ти минут. По итогу так поддерживается синхронизация всех членов команды. На
малом проекте часто собрания проходят реже, формат встреч и их периоды
определяются всей командой.
Отображение итогов итерации - встреча с заказчиками, где выполняется
представление созданного в рамках одной итерации функционала [9]. Недоделки до
показа не допускаются. Цель подробного представления – понять ожидания от
продукта между разработчиком и заказчиком, провести обратную связь по итогу
показа. Если фирма-заказчик не использует Scrum и не ждет от команды показа
функциональной части, представление может отменяться.
Ретроспектива – некая встреча команды по итогу спринта, чтобы
проанализировать выполненную в рамках итерации работу, понять проблемные
места и места роста команды [9]. В рамках такой встречи предлагаются решения по
оптимизации работы команды для минимизации выявленных недочетов.
Ретроспективное изучении итерации - важный компонент всего метода Scrum,
который включает синхронизацию цели компании и целей команды [2].
71
Отрешение командой от принятых на ретроспективе вариантов действий
сведет на нет большую часть пользы всего метода, и потому важно, чтобы в рамках
встречи все члены команды принимали участие. Неисполнение решений командой
может быть причиной:
1. Невысокого общего командного духа, непринятия корпоративной
культуры [5].
2. Неимение лиц, которые могут быть ответственными за каждый этап
принятия решения [5].
3. Некая личная разочарованность сотрудников.
Обязанностью руководителя команды становится выявление и устранение
всех этих проблем.
По итогу итерации в Scrum указывается, что в продукт внесены и проверены
все изменения. По итогу по каждому циклу на каждой итерации в самом продукте
появляются дефекты и растет уровень технического долга.
Также возможно, что несколько членов команды смогут в рамках ситуации
изменить модули проекта. Нельзя допускать фрагментация знаний и ротацию
специалистов, которые создают модули проекта, использовать Brain-Storm и
программирование парами [7], что позволит иметь совокупный код проекта.
Неверное планирование процесса установки Scrum часто приводит к
минимизации результативности команды. И очень часто характерны такие ошибки
[7]:
1. Нет понимания сути работы метода перед началом применения у
руководства, либо у все команды [4];
2. Установка всех без разбора компонент без адаптации к текущим
процессам бизнеса;
3. Планирование всего объема времени разработчиков;
4. Введение мер и санкций за несоблюдение сроков задач в процессе
обучения команды [8].
Описанные ошибки приводят к:
1. Реализации внутренних сопротивлений всем изменениям [6];
2. Повышение бюрократии и рост объемов административного
регулирования;