Как построить работу над кейсами

Мой друг Даня спросил меня недавно:

«Максим, подскажи, как следует писать текст кейсов для компании. Понятно, что для этого нужны по крайней мере два человека: тот, кто вёл проект, и редактор. Но как распределить функции между ними? Как выстроить процесс?»

Постараюсь ответить в этом посте.

Как подойти к созданию кейса

По сути, чтобы написать кейс, нужны две вещи:

1. субстанция, из которой предстоит написать кейс: опыт ведения проекта;
2. форма кейса: структура повествования.

Можно провести аналогию с изготовлением статуи. Чтобы изготовить статую, нужна субстанция, камень, и форма статуи.

В случае с кейсом субстанция — это опыт ведения проекта. Все сложности, решения, ошибки и результаты — всё это субстанция, «порода», из которой лепится кейс.

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

Так что создание кейса сводится к двум функциям: 1) добыче субстанции 2) и приложении к ней формы. Поэтому чтобы выстроить процесс, нужно разобраться, откуда брать субстанцию, а откуда — форму.

Источник субстанции — это люди, которые работали над проектом. Обычно это проектный менеджер, иногда ещё ключевые специалисты: дизайнеры, разработчики.

Источник формы — это автор кейса, то есть редактор.

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

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

Пример 2. Недостаточно формы. Бывает и другая ситуация. Кейс просят написать сотрудника, который не занимается текстом профессионально. А редактору отдают на вычитку. Это тоже плохой вариант. Скорее всего, специалист не учтёт восприятия текста читателем. В результате текст не будет выполнять той задачи, для выполнения которой он был написан.

Как должна быть построена работа над кейсом

Работа над кейсом — это командная работа, которую организует редактор. Для этого редактор должен понять, какую форму он должен придать кейсу:

1. Для этого он разбирается в целевой аудитории. Обычно это потенциальные клиенты компании, поэтому интересы целевой аудитории как правило совпадают с тем или иным УТП компании.
2. Затем редактор разбирается в задачах и целях проекта. Узнаёт о результатах проекта: ищет способы показать, что проект свои цели выполнил. Собирает доказательства.
3. Пишет и публикует кейс. Смотрит на результаты, оценивает, как ему выполнить пункты 1 и 2 лучше в следующем кейсе.

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

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


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

Сегодня совет по редактуре. Рассказываю, когда стоит «разуплотнять» текст, то есть делать его более водянистым

Следите за плотностью информации на квадратный сантиметр. Чем больше смыслов автор вкладывает в одно предложение, тем сложнее этот смысл извлекать. Например, автор пишет о наследовании смарт-контрактов в Solidity:

В Solidity реализовано наследование смарт-контрактов. Это позволяет расширить функциональность программы, поддерживать разделение кода, уменьшая зависимости и увеличивая возможности повторного  использования существующего кода.

Через этот текст приходится как бы продираться. Мы как будто останавливаемся на каждом слове, чтобы понять, что имеется в виду. Мыслительная работа, при чтении этого текста происходит примерно так:

– Что такое функциональность программы? Это то, что программа делает.
– А что значит её расширить? Значит, программа сможет делать больше разных вещей.
– Что такое разделение кода? Видимо, это когда код разнесён на разные файлы.
– Получается, что наследование помогает сделать программу функциональнее и разносить код по файлам.
– А зачем разносить код по файлам? А вот дальше: «уменьшая зависимости и увеличивая возможности повторного  использования существующего кода».
– Что такое зависимости? Это когда одна часть кода может повлиять на другую часть, хотя мы этого не хотели. А наследование позволяет этот эффект снизить.
– Дальше речь о повторном использовании кода. Это когда мы один раз код написали, а потом вызываем его из разных частей программы, понятно.
– Получается, что наследование смарт-контрактов позволяет сделать программу функциональнее и разделить код по файлам. А это в свою очередь поможет избежать ошибок из-за ненужных зависимостей и повысить возможности повторного использоания.

По сути читатель мысленно выделяет в тексте ключевые блоки и пытается перевести на свой язык. Эту работу стоит выполнить за читателя:

В Solidity реализовано наследование смарт-контрактов. Это дает преимущества при написании кода:

– Расширяет функциональность программы. Мы можем использовать в дочерних контрактах те методы, которые мы уже описали в родительском контракте.
– Разделяет код. Мы можем делить код на несколько контрактов. Каждый контракт будет выполнять свою уникальную функцию.
– Снижает зависимости участков кода. Это поможет избежать ошибок, когда одна часть кода влияет на другую. Так нам будет легче проектировать, использовать и тестировать код.
– Увеличивает возможности повторного использования кода. Благодаря этому мы можем упрощать логику кода и распространять его  для использования его другими разработчиками.

Мы разделили одно длинное предложение на 4 абзаца. Плотность информации снизилась, а потому её стало легче считывать.

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

Легко оперировать объектами, которые можно представить. Например, нам легко представить такую картину:

Иван купил у Петра айфон. Они встретились в кафе, Иван осмотрел айфон и перевёл деньги на карту.

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

С абстракциями работать куда сложнее:

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

Чтобы абстракции были понятно, их стоит с чем-то сравнить. Самый простой способ — привести пример:

Наследование в Solidity работает по следующим правилам. Дочерний контракт может обращаться к методам и переменным родительского контракта.

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

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

Иными словами, админ сможет делать всё то же, что обычный пользователь плюс ещё что-то.

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

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

Поэтому нам остаётся только связать новые понятия с уже понятными отношениями двух понятий. Мы помогаем сделать вывод читателю: дочерний элемент может.

Чтобы объяснить что-то, объясните противоположность этого

Чтобы усвоить понятие, нужно также усвоить отрицание этого понятия. Например, невозможно понять, что такое день, не зная, что такое ночь; что такое свет, не зная, что такое ночь.; что такое 1, не зная, что такое 0.

Поэтому для объяснения понятия важно объяснить противоположность этого понятия.

Например, мы объясняем, чем отличаются библиотеки от смартконтрактов:

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

Тут мы вводим новое понятие — цель библиотеки. При этом мы говорим, что именно цель библиотеки отличает её от смарт-контракта.

Но в таком виде цель непонятна, потому что непонятна её противоположность. В данном случае противоположность цели библиотеки — это библиотека смарт-контракта. Добавим объяснение цели смарт-контракта:

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

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

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

Иными словами: всё познаётся в сравнении. Так что наша задача как авторов и редакторов сделать это сравнение явным.

Клёвая схема. Сделана из говна и палок, а работает. Сразу становится понятна эволюция:

1. Сперва всех заставляли регистрироваться.
2. Потом профиль стали создавать через соцсети.
3. Теперь ключевым становится кошелёк.

Такая схема — это минус 5 минут времени и плюс 100 к ясности.

Разбивайте конструкцию «если — то» на два предложения

Иногда для сравнения двух сущностей подходит конструкция «если одно делает так, то другое эдак». Но такое случается редко, обычно эта конструкция раздувает предложение и его становится тяжело читать:

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

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

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

Мы добавили предложение «Смарт-контракты устроены иначе». Оно выполняет ту же функцию, что конструкция «если — то», но делает это лучше. При этом три коротких предложения читать проще, чем одно длинное.

Я до того заработался, что отупел и голова как забитая.

1868 год, 22 июня
46 лет

Друзья-редакторы! Есть предложение о работе. Мб кто-нибудь ищет фул-тайм, парт-тайм? Если интересно — пишите в личку @Maxim93

Я заметил в своей работе два вида непонимания

Бывает, читаешь текст и не понимаешь его. А когда пытаешься разобраться, почему не понимаешь, то говоришь: «Текст непонятный, потому что непонятно, зачем нужно то, что я читаю».

Это очень верно. Если понимаешь необходимость того, о чём читаешь, то понимаешь и сам текст. А если не понимаешь необходимости, то и текст становистя бессмысленным.

При этом забавно, насколько разным может быть это «зачем нужно». Допустим, вы читаете текст о том, как устроен компьютер и не понимаете его.

При этом:

1) Вы можете не понимать, зачем то, о чём вы читаете, нужно компьютеру. Например, вы читаете про оперативную память и не понимаете, какую роль она играет в компьютере.

2) Либо вы можете не понимать, зачем вам вообще знать то, как устроен компьютер.

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

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

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

Самое главное в образовании

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

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

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

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

Кто работал в эд техе, тот поймёт