Как написать кейс про разработку, если ты не специалист в айти, а создать хорошую b2b-историю очень нужно

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

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

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

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

Так было и со мной. Год назад я пришла в компанию по заказной веб-разработке с опытом в онлайн-образовании, культуре и СМИ. Компания средняя (30 сотрудников), PR-директор и мой куратор — не кто иной, как CEO.

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

Я сделала много ошибок.

Писала тексты, мне их резали, критиковали и возвращали на доработку.

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

Для себя я выработала понимание и последовательность действий при создании таких историй. Основная часть статьи — это подход к написанию кейса в принципе, но под прицелом моего случая, айти-разработки. Рассказала и про свои ошибки (чтобы вы научились на моих и меньше сделали своих) :)

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

Есть чем дополнить, что посоветовать? — Пишите в комментариях, я буду им рада, продолжаю учиться и совершенствоваться.

Итак, вам поставили задачу — подготовить и опубликовать кейс про конкретную разработку.

1 — Не тушуйтесь и используйте свой опыт и талант в работе с текстом, сделайте даже айти-историю интересной

2 — Никогда не бойтесь спрашивать коллег обо всём, что вам непонятно

3 — Всегда держите перед глазами образ целевой аудитории кейса

4 — Соберите себе весь help-ресурс, который возможно собрать из опыта компании

5 — Помните, в начале всегда тяжело. Дальше точно будет легче и драйвовее.

А теперь лонгрид :) — подробно по этапам создания кейса.

1 — Есть ли согласие клиента, каковы особенности договора с заказчиком?

Ошибка: Приступить к созданию истории, решив, что согласие априори есть.

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

2 — Какой кейс готовим?

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

3 — Кто руководитель (менеджер) проекта?

Его вы будете опрашивать в первую очередь.

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

5 — Для кого мы пишем кейс?

Классика — пишем для потенциальных клиентов (и чтобы было приятно клиенту — вашему заказчику и герою кейса).

Кто с большой вероятностью будет читать? — Директор по маркетингу или директор по IT.

Мы помним, что пишем также с hr-целью (увидят специалисты в отрасли, которые захотят работать у вас, прочитав, какие интересные крутые проекты вы делаете).

Читать кейс будут и конкуренты — не выдаём лишнего, не надо постоянно фокусироваться на затруднениях и ошибках (надеюсь, в моей статье их не слишком много) :)

6 — Где будет размещена история?

Традиционно — на сайте компании. Адаптивы истории могут размещаться в соцсетях, рейтингах и СМИ.

Вы собрали ответы. И получили согласие клиента на публикацию кейса через руководителя проекта или лично (если менеджер попросил сделать так и соединил вас с представителем заказчика).

Это актуально, если таких документов в компании ещё нет.

Тогда вам нужно читать уже опубликованные кейсы и выписывать выводы:

1. Типовая структура кейса в моей компании

— анализ (глубинные интервью и что было обнаружено)

— проектирование процесса (определение приоритетных задач и разбивка на этапы)

— определение ролей, пользовательских сценариев

— дизайн (мудборды, прототипы, визуальная концепция)

— разработка, фронт- и бэкенд

— с какими сложностями мы столкнулись и как удалось их решить

— отзывом клиента

— планами клиента продолжать развитие проекта (вместе с вами)

— полученной наградой на конкурсе

— цифрами, метриками, динамикой (сайта и бизнеса заказчика)

2. Стиль и тональность кейсов

Если в компании есть готовый документ tone of voice, обратитесь к нему.

Если такого документа нет (как в моём случае), почитайте готовые кейсы и выпишите себе, какого подхода придерживается компания:

Здесь я сделала ошибку.

В одном из кейсов я выбрала стиль, которому я симпатизировала у известной мне айти-компании. Это стиль «первого типа» — всё очень лаконично, без сторителлинга. Создала кейс. И… мне полностью его завернули.

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

Вы собрали структуру кейса и выводы по стилю. Покажите их руководителю (PR-директору), чтобы понять, верны ли они. Согласуйте или вместе поправьте.

PR-директор уже подсказал вам, кто вёл проект. Обратитесь к этому менеджеру, попросите его создать список команды разработки (дизайн, фронтенд, бэкенд, тестирование). Свяжитесь с каждым и установите, когда и как вы проведёте с коллегами интервью (включая самого менеджера). Кому-то нравится разговаривать лично (записывайте на диктофон). Кто-то любит зум-конференции. Есть ребята, которые любят отвечать на вопросы письменно.

У вас готов список участников, график интервью и способ связи.

Например, такой опросник собрала себе я, и постоянно работаю с ним. Очередность (да и состав) вопросов вы выстраиваете под себя.

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

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

Непонятна логика, неясен смысл предложения или термин? История не складывается в единую в вашей голове? Спрашивайте!

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

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

Вы собрали материал со всех, кого хотели опросить.

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

Материал готов для привязки к структуре кейса.

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

Не забывайте про правило «непонятно — спрашивай!». На этапе выстраивания истории у вас снова возникнут вопросы к терминам, технологиям, логике и общему смыслу участка работы (дизайн, фронтенд, бэкенд). Уточняйте всё непонятное вам!

Логика в истории выстроена.

Пусть дерево вашего кейса расцветёт :)

Теперь лично вам нравится всё в созданной истории.

Сократите ещё раз то, что уместно. Если нашли сломанную логику или не раскрытый термин — соедините разорванную нить истории и поясните термин (но кратко).

История готова для того, чтобы показать её команде.

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

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

Верно делать так:

собрать все предложения, обсудить с менеджером противоречивые замечания, договориться о верной формулировке и внести изменение в копию (!) черновика.

Прислушиваться, но «не вестись» на комментарии по структуре, стилю, формулировкам и запятым. Это ваша зона ответственности — и здесь согласовывает или критикует только PR-директор.

Зачем сохранять первую, полную версию черновика?

Она пригодится, если у главного по PR появятся вопросы, или он спросит, были ли идеи сформулировать мысль как-то иначе. У меня был опыт, что мои исходные формулировки согласовывались, а поправленные после замечаний коллег — нет.

Ещё раз вычитайте текст. Чистовик истории готов.

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

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

И снова ошибка, которая затягивала производство моих первых кейсов:

Не было установлено время ожидания ответа руководителя. Можно было ждать фидбека и неделю, и две, и месяц. Обсудив опыт, мы договорились так: если через неделю нет ответа, один раз нужно напомнить; если ещё через 2 дня ответа нет — считать чистовик согласованным и отправлять в упаковку.

История полностью готова и согласована по тексту.

Как это сделать?

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

1 — Попросите менеджера и главного дизайнера проекта оставить в чистовике (гугл-документе) комментарии, какой раздел или абзац текста как можно визуально подкрепить. Пусть коллеги сразу же оставят скрины или ссылки на изображения.

2 — После этого оставьте такие же пометки от себя, если что-то хочется дополнительно свизуализировать. Опирайтесь и на саму историю, и на готовый продукт (например, заходите на готовый сайт и гуляйте по нему).

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

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

3 — Из всех предложенных вариантов составьте итоговый набор иллюстраций. Действовать можно по такому принципу — кейс удобно читать и даже просто считывать, если структура такая: Заголовок — 1-2 небольших абзаца текста — иллюстрация. Оставьте итоговые комментарии в гугл-документе.

4 — Закажите производство иллюстраций. Учтите все размеры и нюансы вашего сайта, чётко сформулируйте задачу в своей системе (например, мы пользуемся Redmine), оцените трудоёмкость (по опыту, или просто спросите самих дизайнеров), сверьтесь с квотой специалистов на PR-задачи в этом месяце и займите слот в конвейерной ленте задач (мы работаем с гугл-таблицами).

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

6 — Курируйте процесс, смотрите промежуточные итоги (мы работаем с Figma), отвечайте на вопросы дизайнеров.

7 — Получите итоговый набор иллюстраций и собранный в фигме кейс. Всё проверьте на соответствие заданному вами контенту, размерам и сборке. Покажите артдиректору и согласуйте визуал с ним.

Ура, вы собрали кейс!

Вспоминаем договоренность. Если через неделю нет ответа, один раз нужно напомнить; если ещё через 2 дня ответа нет — считать кейс согласованным и размещать на сайте.

Кейс согласован с директором.

Например, мы используем режим презентации проекта в фигме.

Вы помните, верно? — Согласовать можно через менеджера проекта или лично. Это зависит от типа коммуникации, которую выбрал менеджер разработки.

Договоритесь с PR-директором о регламенте: сколько дней нужно ждать ответа клиента, через сколько напомнить, а когда при отсутствии замечаний заказчика кейс считается согласованным. (Мы помним, что принципиальное согласие клиента было получено на самом первом шаге)

Кейс согласован с клиентом.

Оцените время и чётко сформулируйте задачу контент-менеджеру.

Если есть навык, то соберите кейс самостоятельно.

Здесь я снова расскажу о своей ошибке :)

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

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

Кейс собран на локалке.

Здесь мы договорились, что фидбек я получаю в течение 3 рабочих дней. Если его нет, то я однократно напоминаю. Если руководителям смотреть итог некогда, кейс переносится на рабочую версию сайта (проду).

Кейс перенесён на проду.

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

Соберите воедино всё то, что мы обсудили выше.

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

Зафиксируй плановый срок подготовки кейса, чтобы оценить возможности при составлении контентного плана на 3, 6 и более месяцев вперёд.

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

Вы провели отличную работу, поздравляю! :)

Как и обещала, я расписала личный опыт очень подробно.

0 — Вы получили задание создать кейс про конкретную историю разработки

1 — Уточните у постановщика задачи все вводные: есть ли согласие клиента на публикацию кейса и наличие нюансов; имя руководителя проекта; тип кейса; самое краткое резюме истории; для кого пишем кейс и где будем его размещать

2 — Соберите документ о структуре и стиле кейсов компании (в следующий раз он у вас уже будет)

3 — Определите, кого, когда и как вы будете опрашивать

4 — Создайте свой опросник (в следующий раз он у вас уже будет)

5 — Проведите интервью по установленному графику

6 — Обработайте собранный материал так, чтобы вам было удобно с ним работать

7 — Нарастите текст на структуру кейса

8 — Проверьте логику истории, добавьте интересных акцентов

9 — Прочитайте черновик через день и внесите правки и сокращения

10 — Покажите черновик команде разработки — обсудите и внесите правки

11 — Покажите чистовик PR-директору (вашему прямому руководителю) — согласуйте или внесите правки

12 — Получите набор иллюстраций к кейсу (какие-то схемы нарисуйте сами и передайте в отрисовку дизайнеру), получите кейс, собранный в фигме

13 — Покажите собранный кейс артдиректору и PR-директору — согласуйте с ними итог

14 — Согласуйте кейс с клиентом

15 — Соберите кейс на локальной версии сайта

16 — Внимательно проверьте, покажите руководителю (или договоритесь, что этот этап не нужен) и перенесите на рабочую версию сайта.

17 — Делитесь кейсом везде, где это возможно и уместно (делайте адаптивы иллюстраций, затачивайте текст под другие площадки перед размещением)

18 — Зафиксируйте полученный опыт, документы, структуры и регламенты

Всё готово, вы большие молодцы!

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

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

Делитесь и своими советами. Желаю вам успеха!

Автор статьи: Ирина Алымова, PR-специалист SVK.Group (Студии Валерия Комягина)