растущей кодовой базой Python в командах инженеров DevOps. Стандарты кодирования, которые мы изначально разработали, более не могут эффективно масштабироваться на эти языки, и попытки поддерживать их замедляют нас и создают враждебность между командами. Я полагаю, что пришло время переосмыслить цель стандартов кодирования, какую ценность они приносят и как мы ее достигаем в нынешних условиях. Вместо подхода «сверху вниз», который мы использовали в прошлом, я предполагаю, нам подойдет более совместный подход, который позволил бы каждому работнику и команде принять участие в обсуждении.
На ваш взгляд, как хорошо написан этот отрывок? Потратьте несколько минут на его изучение. Заметили формулировку «были разработаны» в первом предложении?
Это пассивный залог; непонятно, кто разработал стандарты. Я бы переписал это предложение в более ясной и прямой форме, убрав пассивный залог, например: «Мы разработали наши стандарты кодирования в другое время и в другом месте». Если вы не понимаете, о чем я говорю, не волнуйтесь, скоро я расскажу о пассивном залоге и его пугающем влиянии на текст.
На самом деле на данном этапе это единственное, за что можно критиковать этот текст. В конце концов, мы не знаем, кто слушатель, не знаем, какой контекст уже есть у аудитории. Уместно ли начать обсуждение с истории возникновения стандартов кодирования? Возможно, если у аудитории нет такой истории. Но если они ее знают, то повтор может оказаться пустой тратой времени. Дело в том, что коммуникация должна быть рассчитана на определенную аудиторию. Вы когда-нибудь сидели на собрании, где только и делали, что бубнили о том, что вы и так уже знаете? Вот вам и пример неверно структурированной истории.
Помимо этого, структуру моего примера можно немного улучшить. Наряду с акцентом на классическую сюжетную структуру путешествия героя, эффективное письменное общение следует подходу «проблема-контекст-решение», и вот как это выглядит:
[Сначала проблема] Стандарты кодирования, которые мы изначально разработали, более не могут эффективно масштабироваться на эти языки, и попытки поддерживать их замедляют нас и создают враждебность между командами.
[Контекст] Наши стандарты кодирования были разработаны в другое время и в другом месте. Первоначально целью было сделать код более читаемым, поэтому стандарты были сосредоточены на соглашениях об именовании переменных и функций. Со временем мы разработали базовые стандарты модулей, чтобы попытаться избежать увеличения кода, с которым столкнулись в его некоторых важных частях.
[Связь контекста и проблемы] Но тогда мы все использовали один и тот же язык программирования – C#. Сегодня организация превратилась в настоящего полиглота с большой кодовой базой C#, JavaScript и растущей кодовой базой Python в командах инженеров DevOps.
[Решение] Я полагаю, что пришло время переосмыслить цель стандартов кодирования, какую ценность они приносят и как мы ее достигаем в нынешних условиях. Вместо подхода «сверху вниз», который мы использовали в прошлом, я предполагаю, нам подойдет более совместный подход, который позволил бы каждому работнику и команде принять участие в обсуждении.
Если вы визуал, представить ситуацию вам поможет рисунок 12.1.
Мне нравится такая памятка, потому что она следует более четкому подходу к решению проблемы в контексте. Я хочу отметить кое-что особенно эффективное: написав «Мы разработали наши стандарты кодирования в другое время и в другом месте», автор позволяет сохранить лицо любому из присутствующих, кто, возможно, защищал первоначальные стандарты кодирования. Такая формулировка говорит: «Это не твоя вина. В свое время такой подход был правильным, но сейчас мы живем в других реалиях». Поступая таким образом, автор избегает ненужной конфронтации и при этом не тратит время на хождение вокруг да около.
Рис. 12.1. Модель эффективной коммуникации
Модель «Проблема-контекст-решение» в действии
Приведу пример этого процесса с помощью ситуации, которая произошла, когда я писал эту книгу.
В моей компании есть формальный структурированный процесс создания новых дизайнов для продуктов. Он хорошо работает в большинстве наших доменов, но один из них немного отличается. Обычные процессы в основном включают общение с клиентами и выяснение проблем, а также разработку продуктов для их решения. Но эта конкретная область включает научные знания, поэтому в компании работают эксперты в соответствующих научных сферах.
Проблема в том, что обычный процесс проектирования уменьшал значимость вклада экспертов. Мы стараемся избегать группового мышления и предвзятости, которые внутренние заинтересованные стороны могут привнести в дизайн, потому что хотим быть уверены, что прислушиваемся исключительно к нашим клиентам. Но наши заказчики не знают о науке, которая влияет на то, как они работают, и экспертам предстоит сыграть большую роль в процессе проектирования.
Кое-то из команды захотел решить этот вопрос и написал короткое послание, применив модель «Проблема-контекст-решение».
Проблема. Нашим экспертам не дают достаточно права голоса в процессе, хотя их знания необходимы для создания эффективного продукта. На практике это приводит к менее эффективным продуктам, мы должны исправить это.
Контекст. Хотя большинство проблем, связанных с дизайнерскими решениями, требуют специальных знаний, мы обнаружили, что заказчикам не хватает основных знаний о проблеме. Наши эксперты, опираясь на более чем столетний опыт науки, обладают этими важнейшими знаниями.
Связь. Конкретно для этого домена нам необходимо изменить стандартный процесс, чтобы дать право голоса экспертам. Они могут помочь нам интерпретировать то, что мы слышим от клиентов, и воспользоваться огромным количеством проверенных научных данных по этой теме.
Решение. Я рекомендую привлекать экспертов не на начальном этапе общения с людьми, а на более позднем этапе обобщения данных, чтобы они могли помочь нам лучше интерпретировать то, что мы услышали от клиентов, в контексте их научного опыта.
В итоге эта рекомендация была принята, и для некоторых членов нашей команды это был почти момент прозрения. Называя проблему, предоставляя общий контекст, связывая его с проблемой, а затем предлагая решение, автор создал пространство для понимания, экологичного совместного обсуждения и в конечном счете улучшил рабочий процесс.
Я знаю, внимание к технической и структурной частям письма может занять много времени. Но если вы будете заниматься этим постоянно, то постепенно улучшите этот навык. Человеческий мозг – удивительная штука, и он прекрасно улавливает то, что мы пытаемся сделать. Если вы будете достаточно практиковаться, в конечном итоге ваш мозг начнет активно заниматься структурным планированием, и вам не придется так много думать об этом.
Практика письма – одна из самых простых вещей в мире, которой можно заниматься с помощью Интернета. Заведите блог. Не волнуйтесь, если кто-нибудь его прочтет. В конце концов, закройте к нему доступ, если хотите. Но посвятите себя написанию текстов по крайней мере
