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

Управляющий Директор EventPlatform Олег Крючков о случаях, когда излишнее геройство и передача всех работ inhouse-разработке вредят конечному результату.

Заказывать разработку очередного цифрового сервиса или пытаться «создать своё»? Вопрос вечный и актуальный для любого класса задач. Индустрия мероприятий и цифровизация корпоративных коммуникаций тоже не смогла его избежать. Мы нередко сталкиваемся с попытками клиентов и агентств создавать «цифровые сервисы мероприятий» собственными силами.

Стремление не расширять пул подрядчиков и «оптимизировать бюджеты» понятно, но так ли всё легко? Разбираем семь вредных советов, соблюдать которые строго НЕ рекомендуется.

Эффективная и выгодная реклама с сервисом от МегаФона

Широкий выбор рекламных каналов, более 100 параметров по интересам, подробная аналитика и другие возможности уже ждут в Личном кабинете. А еще кешбэк 100% за запуск рекламы в первый месяц и еще 10% — каждый месяц.

Узнать больше >>

Реклама. ПАО «МегаФон». ИНН 7812014560. ОГРН 1027809169585. ERID LjN8K1P7y.

Вредный совет 1. Отдавайте все задачи только собственной команде, все равно никто лучше не разбирается

Мы ни в коей мере не сомневаемся, что в рамках ваших мероприятий и коммуникаций действительно есть уникальные задачи. Задачи, которые никто никогда не решал. Или, может быть, решали схожие? Стоит ли делать наугад? Или обратиться к профессионалам, которые, во-первых, специализируются на этом классе задач, а во-вторых, работали над сотнями проектов, в рамках которых можно всё-таки найти некоторые ответы на вопросы, которые кажутся новыми?
Возможно, решить вашу задачу получится, не дописывая ни строчки кода. В нашей практике неоднократно были случаи, когда клиент, удивленный, что «не нужно ничего допиливать», оставался доволен и красотой решения, и экономией бюджета.

Вредный совет 2. Экономьте ресурсы за счет внутренней команды

А что, если сервис придётся тиражировать? Появятся две уникальные задачи, три, десять? Как вы будете это масштабировать?

Внешний подрядчик гарантирует отсутствие ресурсных просадок по проекту. Вот пара наиболее типичных примеров:

Вы много месяцев делали продукт и собрали под него полноценную команду IT-специалистов (продукт-менеджер, тимлид, бэкендер, фронтендер и QA).

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

Сроки горят, и вам нужно сделать функционал, на который необходимо «3 месяца за 2 месяца».

В таком случае внешний подрядчик добавит разработчиков в проект, чтобы уложиться в срок. А вашу команду ждут авралы, стрессы, выгорание. Нужна ли вам такая экономия?

Вредный совет 3. Опирайтесь только на себя ради безопасности

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

Но ведь и ваши разработчики (наверняка ваше внутреннее приложение базируется на талантах нескольких ключевых сотрудников) могут перейти на новое место работы. В этом случае дальнейшая судьба сервиса печальна, и с большой вероятностью придётся решать задачу с нуля.

Поставим вопрос так: что насчёт ответственности за результат? На первой стадии разработки основной риск связан с самим продуктом — будет ли он удобен, решит ли он проблемы пользователей, как он повлияет на ваши мероприятия. Создавая свою команду, вы берёте на себя ответственность за её будущее. Поэтому в случае, если проект не удаётся, это затрагивает не только вас, но и вашу команду, которая попросту теряет работу… а, возможно, и репутацию.

Вредный совет 4. Будьте своему мероприятию и маркетологом, и аналитиком, и консультантом

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

Работая с внешним подрядчиком, вы получаете постоянные обновления и работаете с продуктом, который соответствует веяниям времени.

Вредный совет 5. Ограничьте возможности пользователей

Вы смотрите на ситуацию с позиции организаторов, которым важно донести до участников расписание и некоторые важные анонсы. И всё?

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

Информирование/Релевантность

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

Коммуникации/Нетворкинг

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

Мотивация/Геймификация

Вы или ваш внутренний заказчик организуете всё это, чтобы аудитория выполняла некоторые задачи. Чтобы повысить вовлеченность, увеличить «трафик», востребованность и интенсивность выполнения этих задач, используйте принцип, описанный ещё Марком Твеном: пусть они в это играют.

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

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

Вредный совет 6. Выбирайте только свои серверы

Риски в области безопасности данных — вопрос настолько разносторонний, что этот фактор совсем не является определяющим. Мы понимаем и уважаем желание заказчика разместить инфраструктуру приложения «on premise», но для нас, как разработчиков, перенос решения «за периметр», на инфраструктуру клиента — вполне себе будничный процесс. Заказчик может выбрать, где хранить данные и само приложение.

Не забудьте, что хранение персональных данных — а вам неизбежно придётся с ним столкнуться — подлежит чёткой, законодательно регулируемой регламентации. Компания-разработчик, которая фокусируется на создании подобных решений, является зарегистрированным оператором персональных данных. А вы?

Вредный совет 7. Не тратьте ни копейки

Внутренняя разработка — это ваши собственные ресурсы. Следовательно, прямые расходы. Но собственная команда разработчиков — это не только затраты на зарплату, но и необходимость покрывать больничные, отпуска, страховые выплаты, пенсионные взносы и налоги. Кроме того, процесс поиска или «подстройки» квалификации разработчиков займёт как минимум полтора месяца — и это тоже затраты.

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

Разворачивая «внутреннее» решение, вы столкнётесь с вопросами поддержки, обучения пользователей, сложностью восприятия — всем, что в «большом IT» называется внедрением. А передавая техническую часть на аутсорс, вы можете сосредоточиться на стратегических аспектах вашего бизнеса, таких как продажи, маркетинг и коммуникации с клиентами.

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

Сроки.

Приложение, запущенное на день позже даты мероприятия — это провал и потери. Если корпорация разрабатывает такой сервис собственными силами, нужно понимать, что запуск приложения — это всё ещё запуск «пустого» приложения, а контент-план, регистрация участников, обработка программы и данных о площадке и ещё десятки пунктов — далеко впереди.

Иными словами, не только inhouse development, но и inhouse production. С его непредсказуемостью («вот программа, но накануне у нас наверняка будут изменения») и неравномерной загрузкой («коллеги из отдела обучения пришлют всё в пятницу вечером, будьте готовы»).

Собственно, выбор, озвученный в заголовке — это не выбор «кто разрабатывает». Это выбор «кто реализует», причём продакшен — это что-то, что нельзя сделать один раз и навсегда. Это перманентный запрос на ресурсы и постоянные затраты. Здесь возможен целый спектр решений от «всё своими силами» до «внутренний заказчик — подрядчик приложения — продакшен-агентство», но это тема для отдельной статьи.

Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.