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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сроки.

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

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

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

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