66
производительности
- быстрый доступ к корпоративной
информации
Обычно ИТ–проекты представляют собою довольно затратное
мероприятие в плане ресурсов и времени, к тому же очень трудно точно
определить эффект от реализации подобного замысла. У каждой из
вышеперечисленных методик есть свои недочёты и положительные моменты,
но для более точной оценки помимо финансовых методов имеет смысл
использовать и нефинансовый анализ. Проводя оценку какого–либо ИТ–
проекта, необходимо отобразить два процесса – вложение капиталов и отдача
от них.
Применение ряда критериев оценки не позволяет принять точное
решение о реализации проекта. Его эффективность должна являться
комплексным показателем, который будет учитывать большое количество
факторов.
Анализируя перспективность проекта мобильного приложения нельзя
пренебрегать свойствами рынка, поэтому следует учитывать, что
перспективность любого ИТ–проекта строится на трёх «китах»: характеристика
продукта, характеристика проекта, характеристика рынка.
67
Рисунок 5. Cтруктура критериев перспективности ИТ–проектов
Необходимость создания мобильного приложения зависит от ряда
факторов: целевой аудитории, вида деятельности компании, предназначения,
цели, стоимости, предполагаемого срока окупаемости. Для принятия решения
нужно также понимать, откуда взялись мобильные технологии и каковы их
возможности.
Таким образом, мы можем сделать вывод, что для выбора и обоснования
целесообразности реализации проекта мобильного приложения сетевой
коммерции нужно учитывать не только расходы на разработку и прямой
экономический эффект от внедрения, но и его косвенное воздействие на
цифровой бизнес и текущие торговые тренды рынка виртуальных услуг.
Показатель перспективности проекта мобильного приложения должен являться
комплексным решением и основываться как на количественных, так и на
качественных параметрах оценки экспертов данного рынка.
Согласно прогнозам компании Gartner – исследовательской и
консалтинговой фирмы, которая специализируется на рынке ИТ – в 2020 году
более 75% предприятий станут использовать хотя бы одну платформу для
68
разработки мобильных приложений, чтобы ускорить собственную стратегию
преобразования электронного (и, как следствие, мобильного) бизнеса. С
появлением таких устройств, как мобильные телефоны, планшеты и карманные
компьютеры, множество компаний взялись за разработку приложений для
мобильных систем, чтобы упростить доступ своих клиентов к информации и /
или услугам.
Обычно самыми ключевыми моментами при разработке приложений для
мобильных устройств являются несколько взаимозависимых между собой
этапов:
1) бизнес–анализ целевого рынка предоставляемых услуг;
2) выработка согласованного решения;
3) стадия прототипирования;
4) написание конечного кода и внедрение технологий;
5) проверка работоспособности приложения;
6) создание предрелизной версии продукта;
7) добавление приложения в магазин покупок;
8) последующая техническая поддержка пользователей.
Перечисленные стадии разработки в своей совокупности будут
образовывать последовательность фаз жизненного цикла программного
обеспеченья. То есть это ряд событий, проистекающих в системе в процессе её
создания и последующей эксплуатации. Таким же образом жизненный цикл
может характеризоваться временем от первоначального момента принятия
решения о том, что необходимо заняться созданием программного обеспечения,
до самого момента его ввода в эксплуатационную базу.
Несмотря на то, что данная градация не способна претендовать на
строгую научность, тем не менее имеет смысл описать некоторые моменты
создания программного обеспечения для мобильных устройств более
развёрнуто.
Каждый из этапов жизненного цикла идентифицируется однозначными
задачами, методами их решения, исходной информацией, полученной на
69
предыдущем этапе, и последующими результатами. Результатами анализа, в
частности, являются функциональные и информационные схемы, и
соответствующие им диаграммы. Жизненный цикл программного обеспечения
носит итерационный характер. То есть результаты очередного этапа часто
вызывают определённые изменения в проектных задачах, выбранных для
решения на более ранних стадиях разработки проекта.
Первый и самым важным шагом является освоение ниши и
идентификация продукта. Заказчику потребуется точно определиться с тем, для
чего он намерен использовать разрабатываемое приложение и какова конечная
цель программирования интеллектуальной собственности подобного уровня.
Также предстоит ответить на несколько вопросов, прежде чем можно будет
переключаться на следующие стадии, принимаясь за какие–либо технические
работы:
– каких целей планирует достигнуть компания за счёт создания и
выпуска собственного мобильного приложения?
– планируются ли продажи либо конверсия переходов в продажу
товаров и услуг в рамках данного ИТ–проекта?
– какова основная целевая аудитория и за счёт чего она может
пополниться?
– насколько высок уровень конкуренции в той области, где планируется
работа по созданию мобильного приложения виртуальной коммерции?
– пересекается ли аудитория предприятия и аудитория конкурентов
между собой; готовы ли они использовать именно это, а не какое–нибудь
другое приложение взамен аналогичному?
– каков запланированный бюджет создания и продвижения мобильного
приложения для рынка онлайн–торговли?
Следующий шаг – выработка координированного решения. Перед тем,
как взяться за разработку, требуется составление так называемого технического
задания либо предоставление разработчику заполненного брифа, в котором
поясняется спектр его дальнейших работ по созданию приложения.
70
После получения брифа / технического задания можно переходить
непосредственно к прототипированию и составлению пользовательских
профилей для оценки потенциальных возможностей конечной цифровой
покупки. На основе видения дизайнера, бизнес–оценки и согласования
подробностей технического задания можно запускать процесс
непосредственной разработки программного продукта.
Разработанные дизайнером прототипы различаются между собой:
бывают как статические, так и интерактивные. Для идентификации класса
прототипа можно воспользоваться одним или несколькими приспособлениями
для прототипирования.
Статические прототипы и интерактивные диаграммы должны быть
составлены с учётом технической и программной базы, используемой при
разработке мобильных приложений.
С помощью прототипа можно сделать сразу несколько вещей –
установить более точно требования к приложению, проверить на
совместимость с аппаратурой, оценить требуемые ресурсы, быстро получить
тестовое окружение, провести убедительную демонстрацию и так далее [25, C.
337].
Здесь требуется оговориться, что существуют случаи, когда создание и
последующая разработка интерактивного прототипа приложения для
смартфонов являются нецелесообразными. Если в какой–то исключительной
ситуации этого не требуется, то можно не затрачивать на это лишнее время.
Как выразился в своей книге Джесси Шелл, американский дизайнер
видеоигровой продукции, прототипы обычно создаются для того, чтобы
получить ответ на один или на несколько вопросов [26].
Далее следует написание готового кода и внедрение технологий. Работа
над приложением целиком и полностью передаётся в руки разработчиков,
которые развёртывают соответствующие мероприятия. На фоне этого
программистам предстоит задача при использовании алгоритмов кодирования,
фреймворков и других разнообразных технологий просчитать мобильное
71
приложение в соответствии с техническим спецификациями, брифом и
утверждённым прототипом.
Затем проводится тестирование. На данном этапе выявляется половина
оставшихся ошибок в коде. Это – без сомнения немаловажный этап создания
мобильного приложения, на разных стадиях которого непременным
компонентом служит внутреннее исследование разрабатываемого приложения
как на симуляторах, так и на реальных устройствах. Целью данного
мероприятия является возможность убедиться в том, что взаимодействие
приложения с аппаратной и программной платформами портативных устройств
и многозадачного оборудования будет именно таковым, каковым оно
планировалось на стадии прототипирования. Необязательным, но и нелишним
окажется условие максимально возможной эффективности, чтобы у людей
возникла потребность в покупке современного смартфона, поддерживающего
её работу, и была оснащена GPS–маячком, чтобы давать клиентам пошаговые
инструкции по эксплуатации из любой точки мира.
При необходимости возможно предоставление дополнительных видов
услуг, таких как оказание технической поддержки пользователям,
последующий выпуск новых версий под обновляемые версии мобильных
операционных систем, а также последующее маркетинговое продвижение
продукта.
На любом этапе создания программного продукта можно также
осуществить аудит безопасности, в частности для проверки качества
программного кода. А непосредственно перед запуском приложения это нужно
будет сделать обязательно. Аудит помогает выявить все текущие уязвимости, а
также предугадать появление новых. Лишь после тщательной проверки можно
быть твёрдо уверенным, что данное приложение надёжно защищено от взлома
[24, c. 8–9].
Таким образом, после того, как разрабатываемое приложение окажется
на виртуальном прилавке, возникает возможность сопоставить полученные
72
результаты, что в дальнейшем поможет выяснить, подходит ли данная
программа покупателю.
Наравне с увеличением продаж услуг посредством интернета, а также с
помощью мобильного оборудования, с усовершенствованием информационных
технологий в целом требуется все меньше и меньше усилий для поиска
клиентов – они сами отыскивают поставщиков услуги, подчас это происходит
одним щелчком мыши с колёсиком. Вопрос донесения информации о себе и
своих услугах до потенциальных клиентов в действительности замещается
вопросом поддержания высоких стандартов качества. И в конечном счёте
потенциальный покупатель только выигрывает от этого.
Привлечение аудитории, повышение продаж, выявление основных целей
клиентов и прочие задачи решаются при помощи интерактивных программ. В
качестве вспомогательного инструмента разработка цифрового контента в
отрасли мобильных приложений является важным направлением,
охватывающим многие сферы ведения бизнеса. Первостепенная роль здесь, как
мы выяснили ранее, отводится постановке цели, которую приложение должно
достичь.
Ставя перед собой цель выхода на рынок мобильных приложений,
важно на начальных этапах определиться с направлением – это может быть,
например, не только серьёзная программа для ведения бизнеса, а простое
развлекательное приложение. В случае Alibaba Group целью разработки такого
приложения, безусловно, является максимизация всей прибыли фирмы. К тому
же, не следует недооценивать того факта, что 98% китайцев, пользующихся
Интернетом, являются пользователями мобильного интернета (рисунок 6).
73
Рисунок 6. Число интернет–пользователей в Китае, млн. чел.
Согласно современному определению из международного стандарта,
качество программного обеспечения, как и любого другого продукта, – это его
соответствие потребностям конечного потребителя, то есть программного
пользователя. Самый верный способ повышения качества данного товара –
постоянное улучшение и совершенствование процесса создания и
сопровождения продукта в масштабах всей компании, включая процессы
взаимодействия с внешней средой [25, с. 370].
При любых обстоятельствах успех дела, связанного с разработкой
мобильного приложения, будет зависеть в первую очередь от качественных
характеристик самого обслуживания, предоставляемого организацией,
охватывающего совокупность контента и самого программного обеспечения.
Капиталовложения в маркетинг нередко предоставляют возможность поскорее
заинтересовать пользователя, быстро охватив обширную аудиторию. Но
финальное мнение потребителя касательно продукта будет складываться не
благодаря величине маркетингового бюджета, а как бы то ни было за счёт
качества предоставленного сервиса.
74
Анализ нормативных документов показывает, что среди наиболее
важных показателей качества, основанных на обоснованных претензиях
пользователей мобильных приложений, можно выделить:
а) неадекватность функционирования программного продукта;
б) недостаточное взаимодействие продукта с другими программными,
аппаратными и телекоммуникационными средствами;
в) отказы программного продукта в процессе применения по
назначению;
г) замедленное время работы программного продукта и задержки
представления им промежуточной и выходной информации;
д) неполноту отражения информации;
е) несоответствие хранимых данных и информации, вводимой
оператором;
ж) потерю актуальности информации, циркулирующей в
информационной системе;
з) нарушения конфиденциальности информации;
и) содержание сопроводительной документации и справочной системы
программного продукта [25, c. 370–371].
Процесс стандартизации принятия решений должен происходить внутри
каждой организации постепенно, по мере её развития. Несмотря на то, что в
каждой конкретной ситуации всё будет зависеть от положения, которое
занимает организация на рынке предоставляемых услуг, следует предпринять
определённые шаги для поиска верного ответа, что поможет в конечном итоге
привести тот или иной этап в соответствие с нормой. Кроме этого, с течением
времени особое место нужно отводить процессу институционализации
принятых решений. Поскольку происходит увеличение числа возникающих
вызовов на определённую проблему, постольку дистанция между решениями,
принятыми в конкретной ситуации, станет возрастать.
Исходя из того, что практически любое современное предприятие как
правило берёт своё начало с небольшой команды людей, делается очевидной
75
необходимость принимать координированные действия для достижения
сформулированных целей и поставленных задач. Таким образом, на начальном
этапе локальные и глобальные решения для предприятия зачастую
равнозначны, так как поиск ответа на простые и незначительные вопросы в
дальнейшем, как правило, становится стандартной реакцией на подобные
ситуации. В данном случае принятие решений на локальном уровне
равносильно принятию основополагающих стратегических решений. Ещё это
связано с тем, что на принятие решений, к примеру, во второстепенном
предприятии с небольшим штатом сотрудников значительное влияние будет
оказывать личность какого–то конкретного отдельно взятого человека. Это
достаточно хорошо прослеживается по стартапам с ярко выраженным лидером,
где набор характеристик лидера и характеристики самой организации
отчётливо перекликаются одно с другим. С ростом самой фирмы подобная
корреляция будет уменьшаться в силу того, что в поиске решений будет
участвовать большее количество людей.
Если при возникновении предприятия в процессе принятия решений
пока нет определённого единого уклада, который учитывал бы основные
особенности вновь созданной компании, то рано или поздно начнётся
повышение количества решённых задач и умножение штата. Таким образом,
происходит процесс накопления опыта для создания стандартного процесса
принятия решений – совершается институционализация процесса.
При этом, как уже отмечено выше, принимаемые решения базируются
не столько на личностных качествах работника, сколько на ценностях самой
организации, распространяясь на корпоративную культуру. Такое
выстраивание процессов принятия решений позволяет не только экономить
силы на разрешении базовых ситуаций, но также ослабить зависимость
предприятия от конкретных сотрудников. Дополнительной преференцией
становится возможность отбора сотрудников, клиентов и партнёров, которые
вписываются в рамки существующего процесса принятия решений.