Книги

Soft skills для IT-специалистов. Прокачай карьеру и получи работу мечты

22
18
20
22
24
26
28
30

Существует миф (из-за устаревших уроков письма и всех тех, кого приучили в это верить), что вы не должны участвовать в своем повествовании. То есть нельзя использовать слово «я». Более того, на подобных уроках учат избегать местоимений «ты», «вы», «мы» и других слов, которые относятся к конкретным людям. Лично я предпочитаю писать в непринужденном стиле, который мало чем отличается от того, как я разговариваю. Я использую сокращения и личные местоимения. Если мы с читателем собираемся сделать что-то вместе, например, провести демонстрацию, я буду называть нас «мы». Такой текст читается легче; сам он выглядит более естественно, конструкции предложений удобочитаемы. Более того, такой текст легче писать. Сегодня даже академические журналы, которые слишком долгое время были оплотом чрезмерно формального письма с пассивным залогом, стали более восприимчивы к тексту и делают его удобным для чтения и понимания.

Еще один пример: посмотрите на стиль, которым написана эта книга. Я постоянно использую сокращения (хотя иногда редакторы, руководствуясь определенным стилем, удаляют их). Я называю себя «я», а вас, читатель, – «вы». Все выглядит так, будто мы сидим вместе и болтаем. Такой способ повествования позволяет мне легче записывать аудиоверсии своих книг, потому что они уже представляют собой готовый сценарий. Лучший комплимент, который я когда-либо получал, сделал один читатель после того, как я закончил презентацию на конференции: «Слушать вас – это то же самое, что читать ваши книги, и теперь, когда я читаю ваши материалы, у меня в голове звучит ваш голос».

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

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

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

12.3 Структура вашей истории

Структура истории важна, потому что она возвращает нас к повествованию.

Эти дети бросили ведьму в духовку! Ты можешь в это поверить? То есть, конечно, очевидно, она собиралась их съесть; именно она и включила духовку. И да, они ели ее дом, но кто вообще делает дом из теста и конфет? Она явно хотела заманить детей в ловушку. С таким же успехом она могла бы водить подозрительный белый фургон без окон.

Не такая уж и хорошая история, не так ли? Текст технически верен, но структура страдает. Кто здесь герои? В чем их проблема и каков их путь? Когда вы пишете (или переписываете), спросите себя: «Описываю ли я действия в правильном порядке, который будет иметь смысл для моей аудитории, или они расположены хаотично? Предоставляю ли я достаточный контекст, чтобы история имела смысл для аудитории, или ухожу от темы?»

Создание хорошей истории требует, чтобы вы думали о своей аудитории, чего многие из нас не делают. Давайте рассмотрим этот отрывок:

Наши стандарты кодирования были разработаны в другое время и в другом месте. Первоначально целью было сделать код более читаемым, поэтому стандарты были сосредоточены на соглашениях об именовании переменных и функций. Со временем мы разработали базовые стандарты модулей, чтобы попытаться избежать увеличения кода, с которым столкнулись в его некоторых важных частях. Но тогда мы все использовали один и тот же язык программирования – C#. Сегодня организация превратилась в настоящего полиглота с большой кодовой базой C#, JavaScript и растущей кодовой базой Python в командах инженеров DevOps. Стандарты кодирования, которые мы изначально разработали, более не могут эффективно масштабироваться на эти языки, и попытки поддерживать их замедляют нас и создают враждебность между командами. Я полагаю, что пришло время переосмыслить цель стандартов кодирования, какую ценность они приносят и как мы ее достигаем в нынешних условиях. Вместо подхода «сверху вниз», который мы использовали в прошлом, я предполагаю, нам подойдет более совместный подход, который позволил бы каждому работнику и команде принять участие в обсуждении.

На ваш взгляд, как хорошо написан этот отрывок? Потратьте несколько минут на его изучение. Заметили формулировку «были разработаны» в первом предложении?

Это пассивный залог; непонятно, кто разработал стандарты. Я бы переписал это предложение в более ясной и прямой форме, убрав пассивный залог, например: «Мы разработали наши стандарты кодирования в другое время и в другом месте». Если вы не понимаете, о чем я говорю, не волнуйтесь, скоро я расскажу о пассивном залоге и его пугающем влиянии на текст.

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

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

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

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

[Связь контекста и проблемы] Но тогда мы все использовали один и тот же язык программирования – C#. Сегодня организация превратилась в настоящего полиглота с большой кодовой базой C#, JavaScript и растущей кодовой базой Python в командах инженеров DevOps.

[Решение] Я полагаю, что пришло время переосмыслить цель стандартов кодирования, какую ценность они приносят и как мы ее достигаем в нынешних условиях. Вместо подхода «сверху вниз», который мы использовали в прошлом, я предполагаю, нам подойдет более совместный подход, который позволил бы каждому работнику и команде принять участие в обсуждении.

Если вы визуал, представить ситуацию вам поможет рисунок 12.1.