Особенности создания контента для инженеров

Клиент: инжиниринговый центр «Механотроника РА».

Задача: подготовить тексты и схемы для буклета.

Сложность: сложная инженерная тематика, отсутствие готовых материалов у заказчика.

Решение: приезжать к клиенту, вместе с ним готовить материалы и сразу оформлять их в виде прототипа.

Срок: 1 месяц.

Объем: 16 полос.

Описание изображения

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

Среди прочего у «Механотроники РА» есть собственная разработка — программно-технический комплекс «Эгида». На базе «Эгиды» компания строит решения по автоматизации энергообъектов разной сложности и масштаба. 

Задача 

Компания участвует в отраслевых выставках, и ей нужны буклеты. Но что должно быть в буклетах? Чем они могут отличаться от материалов других компаний, предлагающих примерно то же самое? Любое решение должно соответствовать стандартам, отвечать требованиям ПАО «Россети», учитывать особенности объекта — иначе его не примет заказчик. Короче, не слишком разгуляешься.

Описание изображения

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

Описание изображения

Плюсы и минусы
build

Инженеры

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

group_add

Участие заказчика

В нашем распоряжении была целая команда, и какая! — инженер-проектировщик, главный инженер проектов, руководитель отдела автоматизации, заместитель генерального директора.

settings_input_composite

Специфика

Мы не разбираемся в автоматизации энергообъектов — в лучшем случае примерно представляем, как работает трансформатор.

access_alarm

Сроки 

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

Процесс 

Это хороший пример проекта с высокой неопределенностью. Мы не могли сразу разработать пошаговый путь до цели — слишком много неизвестных. Мы не могли проявлять самостоятельность — слишком сложная для нас тема. Тем не менее общий план действий у нас был. 

  1. Собрать требования заказчика. 
  2. Погрузиться в тему, изучить предыдущие буклеты компании. 
  3. Сформировать ожидания читателей. Кто возьмет этот буклет в руки и что его будет интересовать? 
  4. Получить от заказчика материалы, которые отвечают ожиданиям читателей, — самый загадочный пункт. 
  5. Проанализировать все материалы и предложить информационную структуру. 
  6. Отредактировать информационную структуру в несколько итераций. 

 

И еще нам нужно было четко определить, что мы делаем в этом проекте, а что нет. Например, дизайн и отрисовка схем не входили в наши задачи. Все это мы оформляем в короткий, но очень важный документ — обоснование проекта. 

Погнали 

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

Чтобы понять содержание, нужно понять, что интересует читателей. У нас выходило, что буклет может попасть в руки трем персонажам. 

  • Руководитель технических специалистов — тот самый человек, который принимает решение о сотрудничестве. Вряд ли он будет изучать буклет дальше первых двух страниц, вряд ли станет принимать решение только на основании буклета. Скорее, наоборот. В этом случае буклет работает как имиджевый промоматериал, сопутствующий переговорам. 
  • Технический специалист. Влияет на руководителя, оценивая предложенные решения с инженерной точки зрения. Интересуется техническими деталями и «докапывается до мышей». Сложная аудитория. С одной стороны, нужно избавить такого читателя от упоминания очевидных вещей (он и без нашей подсказки помнит ГОСТ), с другой — не забыть про то, что действительно важно. 
  • Проектировщик в проектном институте. Косвенно влияет на выбор поставщика еще на этапе разработки проекта. И отдает предпочтение тем, у кого есть готовые решения, подробная документация и консультации. 

Первым делом мы с заказчиком набросали список решений, написали пару слов для проектировщиков, прикинули содержание первого разворота для руководителей. Ничего уникального и инновационного, просто структурирование, итерация первая. Результат — еще не прототип, но уже скелет будущего буклета. Для проектирования использовали онлайн-сервис RealtimeBord — простой инструмент для быстрого (очень быстрого) прототипирования без ненужных в данном случае тонких настроек и с возможностью выгрузки результатов в PDF.

Описание изображения

Что могло пойти не так? 

Теперь предстояло наполнить все это содержанием. Легко сказать! По факту дела обстояли так. 

  1. У заказчика нет материалов — текстов, схем. Точнее, есть немного по отдельным решениям, есть куча проектных документов, есть старый буклет. Но это едва ли 20% от содержания буклета нового. 
  2. Мы не могли проявить инициативу, написать «рыбу» или как-то еще начать создавать контент. Просто потому, что не знали, как выглядит схема упрощенной АСУ для подстанций — к примеру, указывать ли значение номинального тока в устройстве сопряжения с объектом, или это второстепенная информация. 
  3. Мы уже упоминали, что решения по автоматизации строятся на базе программно-технического комплекса «Эгида». Но и тут загвоздка. «Эгида» есть, а четкого представления о том, что это такое, нет. Классическая история в инженерной среде, когда собственные наработки уже давно превратились в продукт, но этот продукт еще никто не описал. 

Плюс ко всему перечисленному — сроки. Через две недели буклет надо отдать в типографию. 

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

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

«Пошел креатив» 

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

Описание изображения

Кроме того, произошло кое-что, на наш взгляд, еще более важное. Вместо туманного названия «программно-технический комплекс “Эгида”» появилось четкое определение, из чего состоит этот комплекс, какие именно программные и технические решения в него входят. 

Описание изображения

Наша роль 

Прежде чем продемонстрировать финальный результат, нужно подытожить роль «Собаки Павловой» во всей этой истории. Поставим вопрос так: мог ли заказчик обойтись своими силами? Да, однозначно. Буклет — результат интеллектуальной деятельности инженеров «Механотроники РА». Что же тогда сделали мы? 

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

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

Фиксировали всё. Если кто-то из команды при обсуждении прототипа нащупывал точную формулировку, мы сразу ее записывали. 

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

 

Описание изображения

Предлагали изменения по структуре. Например, показывать готовые решения до описания состава программно-аппаратного комплекса — чтобы сделать конкретные предложения «Механотроники РА» более наглядными. 

Избавляли заказчика от рутинной работы вроде поиска формулировок, проверки орфографии, внесения мелких правок. 

Упаковывали результат в виде ТЗ для дизайнера. Чтобы дизайнер сразу получил прототип, тексты в Word (удобней копировать), картинки, разложенные по папкам.


Результат

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

Описание изображения

Смысл 

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

Нам кажется, что этот буклет — первый шаг к формированию продукта «программно-технический комплекс “Эгида”». Мы его описали. Что дальше? Дальше (если заказчик посчитает нужным) это описание еще предстоит упаковать. Как именно — надо думать. Желаемый результат — сделать «Эгиду» узнаваемым брендом, чтобы не описывать каждый раз состав продукта и перечень поддерживаемых протоколов.

 

У вас похожая задача?

Давайте поговорим

 Торопим события?