Советы по внедрению технических проектов в редакциях

Автор Juan Manuel Casanueva
Oct 30, 2018 в Цифровая журналистика

Внедрение технических проектов в редакциях или медиаорганизациях, традиционно не имевших технической поддержки, может стать непростым делом.

Вот пять советов для тех, кто начинает вводить такие перемены, основанных на моем опыте работы с программистами и СМИ в Латинской Америке.

1. Выберите правильного технического партнера (партнеров)

  • Во-первых, важно помнить, что технические задачи могут быть очень разными и что лучше всего заранее определить желательную специализацию вашего будущего партнера. Подумайте, существуют ли какие-то определенные технологические задачи, которые должны быть решены в ходе работы над проектом. Такие задачи могут быть связаны с необходимостью поиска и анализа данных, системами управления контентом, созданием мультимедийной продукции или веб-дизайном.
  • Если в ходе работы над проектом нужно будет решать различные технические задачи, то всегда лучше работать с партнерской организацией, которая имеет специалистов разного профиля. Если вы сотрудничаете с разными партнерами, они должны работать в тесном взаимодействии и в соответствии с общим представлением о будущем продукте и общим планом работы.
  • И, если вы будете работать с уже существующим программным обеспечением, вы должны познакомить вашего партнера с кодами или сообществом людей, связанных с этой технологией. Связь с сообществом технических специалистов может облегчить доступ к техническим и практическим знаниям. Если ваша цель – разработка новой технологии, убедитесь, что ваш партнер имеет опыт работы с аналогичными задачами.

2. Поставьте реалистичные задачи и начните с малого

  • Авторы технических проектов должны иметь четкое представление о дизайне и объеме будущего проекта. Если проект не продуман в подробностях, очень вероятно, что придется потратить дополнительные ресурсы (которые становятся все более дорогостоящими по мере того, как проект увеличивается в объеме) и что возникнут напряженные отношения между членами команды, работающей над проектом. Обычный документ, содержащий описание будущего продукта, и план должны быть ориентирами для всех, кто работает над проектом.
  • В дополнение к основной технологии вы можете ввести дополнительные технические возможности. Но продукт должен отвечать основным потребностям пользователей, и команда разработчиков в первую очередь должна заниматься решением этой задачи. Довольно часто приходится видеть, как простые проекты превращаются в долгие, напряженные и сложные "технические франкенштейны" из-за того, что руководители предлагают добавить разнообразные дополнительные функции.
  • Когда будет создана и начнет работать базовая технология, вы начинаете получать отзывы пользователей. Я рекомендую сначала устранить все неотложные, влияющие на пользовательский опыт проблемы, и уже после этого начинать работать над добавлением новых функций.

3. Оценка ежедневной работы

  • В ходе работы над техническими проектами у членов команды может возникать дополнительная работа. После запуска проекта очень важно оценивать, как меняется ежедневная нагрузка сотрудников. Иногда будут возникать новые задачи – включая публикацию объявлений о вакансиях, – необходимые для решения технических задач, анализа данных и создания контента.
  • Во многих случаях для запуска проекта необходима новая команда, особенно на этапе разработки и после того, как проект начинает работать в полную силу. Создание такой команды должно быть предусмотрено в бизнес-планах проекта.
  • Убедитесь, что ваш технический партнер и/или ваша команда воспринимают работу по поддержке развертывания проекта и по технологической поддержке как часть своей деятельности.

4. Технологии нуждаются в обслуживании

  • ИКТ-решения не принимаются раз и навсегда. Все цифровые технологии нуждается в обслуживании как для решения внутренних проблем, которые могут возникнуть, так и для того, чтобы поддерживать свои технические возможности и связи с другими источниками и технологиями.
  • Кроме того, нет совершенных технологий. Особенно после того, как проект начнет работать, команда техподдержки должна знать, с какими проблемами сталкиваются пользователи, и решать их, чтобы проект работал как можно лучше.
  • Если у вас есть собственная команда техподдержки и вы пользуетесь услугами сторонних организаций или сервисов для создания платформы, вам необходим документ об условиях предоставления услуг, в котором будет четко прописано, какие проблемы команда должна решать, какую работу поддерживать и что модернизировать. Если у пользователей возникнут проблемы, то появится необходимость в новых функциях, или если оригинальное технологическое решение устареет через несколько лет, то очень вероятно, что понадобятся дополнительные расходы.

5. Приготовьтесь к успеху

  • Если все идет правильно, то работа станет более сложной, когда ваш сайт станет популярным и его будет посещать много пользователей. Подготовьтесь, чтобы быть уверенными, что технология, которую вы используете, предоставляет потенциал для увеличения производительности и позволяет быстро внедрять протоколы безопасности.
  • Большинство хостинг-провайдеров предлагают заранее определенные или динамические типы трафика, выбор зависит от потребностей пользователей сайта.
  • Кроме того, с ростом количества посещений на команду может обрушиться шквал обращений и запросов пользователей, так что очень важно создать протоколы для выявления проблем и оценки обратной связи, которые команда техподдержки сможет использовать, чтобы решать возникшие задачи и делать проект более удобным для пользователей.
  • Успех также может привести к проблемам, связанным с безопасностью. Протоколы и службы защиты от DOS- и других атак нужны для того, чтобы избежать сбоев в работе сайтов и потери или повреждения информации.

Основное изображение пользователя Texture X, лицензия СС сайта Flickr.