Адвокат пользователя: пересечение воображаемого разлома

23.09.2016

Фил Девис (Phil Davis) занимается управлением разработки документации в Integral Development Corp. в Калифорнии. За 20 лет работы он много раз сталкивался с мифами о работе технических писателей и в сегодняшней статье развенчивает один из них. Итак, могут ли программисты писать, а писатели программировать?

В последнее время я часто слышу много сплетен о мифе: писатели не могут программировать, а программисты не могут писать.

Большинство этих сплетен идут от несостоявшихся писателей и писателей-философов, которые заявляют, что этот миф — полнейшая ерунда.

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

Этот миф — продукт нашей профессиональной идентификации и доминирующей культуры разработки. Набор защитных механизмов, созданных, чтобы укрепить и расширить наше чувство собственной профессиональной значимости.

В начале (или где-то близко к началу) был вопрос: вы писатель или инженер, технический или нет?

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

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

Ощущающие угрозу инженеры убеждали себя, что программирование — требовательная дисциплина, требующая годы образования, врождённый талант к математическому мышлению и способность обращаться с технологиями, которые не подвластны пониманию смертных. Писатели были людьми, вмешивающимися в чужие дела и педантами, чьи способности в технике ограничивались проверкой орфографии в Microsoft Word и кто просиживал штаны, задавая тупые вопросы и выступая в пользу точки с запятой.

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

Другой защитный механизм, который укрепляет миф — самоназванная специализация: работа мне гарантирована, потому что она слишком сложна или важна, чтобы доверять её непрофессионалам.

Вы можете наблюдать эту реакцию во многих профессиях. Хотите заменить выключатель на реостат? Электричество таинственное и опасное. Вы должны позвонить электрику. Необходимо заменить масло в машине? Машины грязные и сложно устроены. Вы должны оставить машину механику.

Посыл такой: «Вы должны оставить работу профессионалам». В нашем случае миф выливается в предупреждение: программисты не должны писать, а писатели не должны программировать.

Почему же мы всё ещё говорим об этом? Почему фундаментальный разлом между техническим и нетехническим ведёт к росту кодерских лагерей для не-программистов и писательских лагерей для не-авторов?

На самом деле я не захочу пользоваться услугами непрофессионала для обновления электропроводки своего дома или модификации коробки передач своего автомобиля.

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

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

В теории такие модели разработки как «водопад» и его производные обещают эффективность. Тем не менее, эффективность получается из специализации. Нацельтесь на одну вещь, которой занимаетесь, и вы будете в ней лучшим. Если логически это расширить, если вы расставите всех специалистов в виде каскада от одного подчинения к следующему, то в конце цикла *POP* получите свой лучший продукт.

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

Единственное время, которое оставалось для обсуждения, было в конце. Мы называли его «постмортем» (посмертная фотография), что реально отражало ситуацию. Все группы садились в одной большой комнате. Это было единственное время, когда мы собирались вместе, исключая отмечание праздников и корпоративные пикники. С помощью обсуждения, которое вёл главный инженер, мы проходили через череду разочарований к концу водопада, пытаясь найти ошибки в творческом пути и силясь найти успехи, которые стоит отметить. Затем мы должны были поклясться в том, что учтём уроки от последнего цикла в следующем и попытаемся работать в следующий раз лучше.

По ощущениям, мы будто спотыкались в темноте и это приводило меня в замешательство. Я работал в связке с благородными, интересными, ужасно умными людьми. Свободная стартап-культура, смесь персоналий, и мои собственные позиции были неважными линиями, отражающими влияние на нашей структурной схеме организации. Например, перед тем, как Javadoc стал использоваться для внутреннего контента, я начал разрабатывать собственный доклет, чтобы снабдить его тэгом @internal (внутренний). Когда голова у меня пошла кругом, я проконсультировался с дружественно настроенным ведущим инженером. Он выслушал меня и дал несколько критически важных советов.

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

Но даже в стартапе миф «технический/нетехнический» будет закрадываться в голову. Например, реакция начальника на мои запросы о новом продукте была неприятной с заявлениями: «О, это слишком рано. Мы не можем терять твоё время. Тебе ещё не с чего делать скриншоты». Даже самые адекватные наши старшие инженеры позволяли себе не красящие их моменты: «Ну, Фил, этот билд-инструмент называется «муравей». Я вынужден был его перебить: «Чувак, группа документации создают собственные билды уже больше года».

Мы говорим о разрушении этого мифа, потому что старательные и любопытные профессионалы стали недовольными и разочарованными при использовании старых моделей разработки и их ролями, оставленными за бортом. Они идут в соцсети, чтобы выразить своё разочарование и собраться вместе, чтобы узнать об изменениях. Эти ребята являются драйверами эволюции в культуре разработки, от поэтапной, линейной и местной к непрерывной, итеративной и совместной. На современном языке этих ребят, мы становимся пробивными.

Не только писатели подрывают этот миф. Инженеры тоже недовольны, и они находят, что общение может быть эффективным подспорьем и прививкой от разочарования. Например, разработчик и консультант Томас Бьёркхольм (Tomas Björkholm), когда составлял свои принципы экономного документирования для эджайл-методологий, во многом опирается на основы технического писательства:

• Определите вашу аудиторию и её потребности
• Структурируйте свой контент для лёгкого доступа
• Сохраняйте направленность документации
• Используйте изображения
• Сохраняйте документацию актуальной и релевантной

Так почему это всё имеет значение?

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

Такие движения как DevOps и #writethedocs, построенные на признании способностей ваших коллег и на общем желании делать хорошую работу, создают хорошие продукты и делают пользователей счастливыми, расширяя традиционное определение «адвоката пользователя».

Как работа против мифа позволит вам лучше работать на благо пользователей? Снова же, по моему опыту (пожалуйста, простите программистский жаргон):

• Я создавал простые пользовательские интерфейсы в различных технологиях для собственных инструментов и макетов скриншотов. Я знаю достаточно, чтобы нажить себе проблем и установить контакт с командой в высшей степени талантливых разработчиков приложений. Я предлагаю компонентную систему справки для нашего нового адаптивного интерфейса. Разработчики предоставили мне несколько jQuery-плагинов и спросили о целесообразности написания обзоров продуктов для разработки. Работая совместно, мы все ждём в нетерпении того, как нам удастся поднять простой интерфейс на уровень требований пользовательского опыта на радость пользователям.
• Документируя новый REST API вместо спекуляций о том, как пользователи собираются его использовать или строить сценарии использования из названий методов и ресурсов, я попросил помочь нашего технического менеджера по работе с клиентами. Его прямой опыт работы с клиентами даёт плоды в разработке документации API, что даёт преимущества всем нашим пользователям со сценариями и примерами из реального мира.
• Наша команда разработки обратилась ко мне с предложением переработать 50-страничный PDF по «горячим вопросам» пользователей, части нашей системы, которая очень важна и трудна для понимания. Конечным результатом было тщательно выверенные 13 страниц обзора, написанного с использованием словаря, который клиенты реально используют, на основе опыта, годами собираемого техподдержкой.

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

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

Это имеет значение, потому что все мы, в конечном итоге, технические и не технические, являемся адвокатами пользователей.

Источник: Users’ Advocate: Crossing the Mythical Divide

Тэги: API, опыт, профессия, советы