Как написать кейс, если вы разработчик и вам кажется, что писать не о чем

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

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

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

Я всегда писала тексты для рекламного Digital-рынка, а там изначально есть цель в виде KPI (количество и стоимость лида, подписчики и другие измеримые вещи) и путь к ним. По пути ребята придумывают стратегию продвижения, креативы, офферы: это интересно читать.

У разработчиков обычно выходит уныло: пилили-пилили и запилили. KPI здесь один: сделать приложение/сайт так, чтобы оно работало стабильно. Так себе «грандиозный финал», учитывая, что проект может стоить больше двух миллионов рублей.

Мы работали с двумя заказчиками: один делает корпоративные сайты, второй — это компания Purrweb, они разрабатывают мобильные и веб-приложения, проектируют для них UX/UI дизайн. Ребята любезно разрешили мне написать эту статью на их примере.

Сначала я не была уверена, что кейсы вообще получатся: «вау-результат» неочевиден, донести его трудно. Но вот мы написали уже 6 материалов, и я поняла, как рассказывать истории о разработке интересно.

Все начинается с ТЗ. Тут может быть два пути:

1. Разработчик заказывает кейсы «под ключ» у контент-агентства, редактора или такого специалиста, как я. В этом случае исполнитель сам собирает фактуру для текста с помощью брифа (его вы найдете ниже). Редактор сам решает, на что сделать акцент, а какую информацию опустить. При этом пишет текст копирайтер, но редактор руководит процессом. Редактор — голова, копирайтер — руки.
2. Разработчик заказывает текст напрямую у копирайтера. Тогда исполнителю нужно четко поставить ТЗ: о чем писать, на чем акцентировать внимание, дать готовую фактуру для написания текста. Иначе копирайтер может не понять, в какую сторону копать и о чем вообще проект.

Есть 5 этапов написания кейса. Каждый этап важен, а если пропустить, это повлияет на финальный результат. И далеко не в лучшую сторону.

Что вы хотите про себя сказать?

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

1. Высокая конкуренция на рынке разработки и смежной с ней Digital-сферы. Почему пользователь должен подписаться на вашу рассылку, а не на письма от более известной компании, которая начала вести её еще 10 лет назад?
2. Копирайтер не придумает за вас ключевые смыслы бизнеса. Вы можете найти автора на бирже, и он напишет текст за вас. Но если вы не продумали детали, рискуете получить рерайт хрестоматийных текстов. Их в интернете и без вас много. А кейс без этого и вовсе не получится.
3. Штатный копирайтер или пишущий маркетолог тоже не придумает смыслы за вас. Сформулировать ключевую экспертизу должен владелец бизнеса, возможно, при участии команды.

Чтобы сформулировать экспертность, ответьте всего на 6 вопросов. И в результате копирайтеру, а также SMM-специалисту, email-маркетологу и всем, кто делает про вас контент, станет понятно, о чем писать.

Студия дизайна, SCRUM-студия? Само название часть аудитории оттолкнет: «какой такой SCRUM?», скажут одни, а часть притянет — «О, ребята, как и мы работают спринтами, круто!».

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

Бизнес может прекрасно существовать без Большой Идеи и миссии. А контент-маркетинг не может. Сильный контент-маркетинг всегда строится на идее основателя о том, как должен быть устроен этот мир.

Враг — это Большая Идея, только наоборот. Если вы нашли правильного врага и регулярно бьете ему морду, у вас всегда будут вовлеченные зрители. Это интересно, резонансно. Враг — это не конкурент, не клиент и вообще не человек. Это то, с чем вы боретесь в работе, образ мышления, который создает проблемы вам и вашей аудитории.

Недостаточно сформулировать Большую идею, надо применять ее на практике. Какие бизнес-процессы или инструкции могут это подтвердить?

За счет чего вы можете реализовать Большую идею? Ресурсом агентства или веб-студии может быть опыт работы с конкретными проектами, компетенции сотрудников, уникальная разработка. Уникальность — не обязательное условие, но экспертность нужна любому, кто пошел по пути контент-маркетинга.

Вот как ответили на эти вопросы Purrweb:

Кто это будет читать? Где у них болит? На каком языке с ними разговаривать?

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

Может, к вам приходят стартаперы, которые получили инвестиции, потратили их впустую и теперь пытаются на остатки сделать минимально работающий продукт, чтобы стрясти с инвесторов второй транш. Вполне конкретная аудитория 😄

Так выглядит портрет аудитории Purrweb:

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

Когда я спрашиваю специалистов компании (не только в разработке, но и в Digital) о деталях проекта, часто слышу фразу «проект шел “как по маслу”, ничего сложного». Если копнуть чуть глубже, окажется, что это не так. Людям, погруженным в проект, это не всегда очевидно — конфликт придется поискать.

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

Например, в одном из еще неопубликованных кейсов Purrweb переделывают веб-приложение в мобильное. Бюджет и сроки ограничены, поэтому решили воспользоваться формой WebView. Это когда приложение только выглядит мобильным, а на деле запускает внутри себя браузер, в котором и происходит вся работа. Но оказалось, что App Store и Google Play такие «приложения» не принимают. Это и есть конфликт: у вас было элегантное решение, но вмешались злодейские сторы.

С точки зрения разработчика здесь не произошло ничего особенного: он просто решит проблему иначе и пойдет дальше. Но с точки зрения драматургии в тексте это важно.

Конфликтов в проекте может быть несколько — найдите все и расскажите о них.

«Мы сделали, и оно работает» — не подходит. Хотя, конечно, тут вы тоже молодцы.

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

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

Например, такие вопросы я задаю в своем брифе, вы можете скачать его в моем чат-боте:

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

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

Но не превращайте её в ангелов от мира разработки. Иначе кейс приведет вам клиентов, которые будут просить скидку и чтобы вы поторапливались — проект нужен asap, войдите в положение — как в кейсе :)

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

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

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

Это легко, потому что разработчики говорят профессиональной лексикой. При этом клиент (ЦА кейса) не всегда профи в разработке. У него есть идея, а как ее воплотить он не в курсе. Он не понимает, что такое стэк, чем один язык программирования отличается от другого, что значит «прокидывать авторизационный токен», а значит ему это надо объяснить.

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

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

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

В разработке полно интересных кейсов. Вопрос только в том, кому они должны быть интересны. С коллегами по рынку разработчики вполне справляются сами — посмотрите, сколько технических статей на Хабре! А вот с кейсами для клиентов у них возникают проблемы: те их просто не понимают.

В кейсе обязательно должна быть история. В ней нужно показать:

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

Мы начали искать внешнего автора для написания кейсов по трем причинам:

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

Сначала мы заказали кейсы у контент-агентства. Результат от них был, а вот качество кейсов нас не устраивало, и повлиять на него мы не могли. А потом мы познакомились со Светланой. Она привлекла нас фокусом на экспертный контент: он давал надежду на более качественный результат.

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

• SCRUM, щеночки и 5 000+ скачиваний в Google Play: как мы делали немецкое приложение для владельцев домашних животных
• Как мы готовили захват рынка фриланс поваров России
• Как упростить жизнь организаторам мероприятий. Кейс Purrweb
• Давай упрощай: как с помощью дизайна привлечь новичков в сложный мир инвестиций. Кейс Purrweb

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

А если нет — обращайтесь ко мне, напишем кейс вместе. Разберем трудности и поставим процесс на поток.