Навіщо писати кейс, навіть якщо взагалі не хочеться
Коли можна і потрібно писати кейс
Але вам і не треба! Це обман і завищені очікування. Кейси рівня конференцій «Знайди свій трафік» і RCM - це квінтесенція знань, а й ваш запас досвіду для когось видасться недосяжним. Їм теж можна і потрібно ділитися.
Кейси можна і потрібно писати, якщо:
- Відкрили новий спосіб роботи - зменшили витрати, запустили нову технологію, помітили помилки в старих бізнес-процесах і виправили їх. Перші результати, прогнози на майбутнє.
- Вийшло оновлення сервісу, послуги або продукту - описуємо, навіщо зробили, на що сподіваємося, і як тепер буде працювати. Якщо немає результатів, то вивертаємо кейс навиворіт і пишемо про те, які результати були, чому не влаштовували і чому оновлення має все змінити.
- Коли вдалося перевернути уявлення про щось. Наприклад, якщо вам вдалося запустити круту соціалку засобами Діджитал або розкрутити групу ВКонтакте одного з Краснодарських ЖЕКів. Або розробити додаток-гід по вагітності.
Коли краще нічого не робити:
- Коли велика частина роботи будується не на професіоналізмі і небанальних рішеннях, а на конвертах і дзвінках потрібній людині. А ось якщо вдалося вибити потрібний висновок або підпис з чиновника без зв'язків, може теж вийти відмінний кейс.
- Якщо ви працюєте підрядником і клієнт проти розголошення інформації.
- Якщо ви на субпідряд і під результатами роботи ваше ім'я не обговорювалося.
Як писати кейс? З чого починати?
Зверніть увагу на заяву в наступному анонсі «це не тест, а реальна кампанія, яка працює 8 місяців». Воно якісно виділяє керівництво на тлі інших.
Початкові дані. Прикро прочитати кілька сторінок тексту, щоб переконатися, що кейс не можна застосувати до твого власного бізнесу. Бюджет на роботу, відправна точка, обставини, компетентність і чисельність команди, дедлайн - все це важливо, якщо ви пишете / знімаєте / малюєте з метою принести користь, а не заради віртуальних оплесків.
У цьому анонсі є результат, але немає вихідних даних. У самому кейсі вихідні дані з'являються тільки після другої сторінки тексту на стадії, коли йде опис роботи. Кейс від цього не став провальним, але міг бути краще і зрозуміліше для аудиторії.
А тут з вихідними даними все відмінно і відразу ясно, кому буде користь від такого керівництва.
Якщо зобразити структуру кейса, оптимальна і всіма очікувана виглядає так.
Структура рідко відрізняється. Щоб було простіше, задайте собі питання перед тим, як приступати до роботи. Мій список, колись стягнутий з geektimes і доопрацьований, виглядає так:
- Хто замовник? Що за компанія?
- Яка місія проекту - кому він потрібен?
- Як все працювало раніше?
- Що не влаштовувало?
- Чи є щось незвичайне в задачі?
- Чи є обмеження по проекту - гроші, час, персонал, закони?
- Робили все стандартно або розробляли індивідуальне рішення?
- Команда, яка працювала над проектом?
- Які труднощі очікували? Які трапилися?
- Наскільки втягнули замовника в проект?
- Які інструменти залучали? Що з них власні напрацювання, що запозичили?
- Що взагалі складного було або, може, кожен другий впорається?
- Як виглядає результат?
- Це добре чи погано?
- Що говорить замовник?
- Вже працює або тільки придумали, як зробити?
- Що саме змінилося?
- А що було б, якщо не робити нічого?
- А якби не вийшло? Звідки знали, що вийде?
- Скільки коштує робота?
- Швидко впоралися?
- Що треба було зробити інакше?
- Кому і як можна використовувати результати роботи?
Відповідайте на питання, дотримуйтесь простій логіці і нічого вигадувати не варто. Хоча можна придумати, як поліпшити послідовність, якою користуються всі підряд.
Як можна поліпшити кейс?
Кейс - це спочатку історія. Історія успіху або провалу - не важливо. Тому елементи сторітеллінга повинні бути, щоб не перетворити розповідь в купу таблиць і діаграм. Які б скарби вони не зберігали, розбиратися буде нудно. Додайте околобізнесових фарб, введіть в оповідання персонажа і приправте емоціями. Якщо розповідаєте історію, говорите про клієнта, про його почуттях, коли він борсався, намагаючись виправити ситуацію. Опишіть весь шлях проб і помилок. Сід Сміт навіть радить взяти за основу класичний міф чи блокбастер:
Якщо говорите в кейсі про прорив і позитивному результаті, звертайтеся до аудиторії і змусьте асоціювати успіх. Читач повинен повірити, що сам теж так зможе або що ви такий же успіх організуєте для його проекту. Якщо говорите про негативний досвід, краще уникнути звернення до читача. Писати про те, що ми наламали дров, ми зрозуміли, як виправити, і ми більше ніколи не допустимо, а вас такий результат ніколи не торкнеться.
Використовуйте скріншоти і фотографії процесу. Робіть реальні фотографії під час мозкових штурмів і обговорень роботи, сфотографуйте з клієнтом на зустрічі, зробіть розповідь менш абстрактним. Але пам'ятайте - скріншот без пояснення не працює. Обов'язково повинна бути легенда або докладне пояснення, до чого цей графік. Ось хороший приклад того, як хоч і коротко, але цілком жваво і наочно хлопці розповідають, як відмили міст в комплексі Москва-Сіті. Сама ідея привертає увагу.
Оптимальна довжина. Спірне питання. Логічно думати, що якщо читач швидко не зміг оцінити контент, він піде. Але особисто моя думка, що докладніше кейс, тим краще. Зрештою, для цього ми окремо наголосили на важливості анонсів і чітко позначили вихідні дані в кейсі, щоб користувач заздалегідь оцінив, чи варті ці 5 сторінок витраченого часу. Цю ж точку зору підтримує Ніл Патель.
Що ще важливого запам'ятати?
