Культурная изоляция

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

Приведу пример компании Sagent Technology, занимающейся поставками систем управления данными для корпоративных вычислений. Главным экспертом по базам данных в этой компании является Влад Горелик – легендарный программист с невероятно высокими компетенциями. С ним лично доводится пообщаться только тем клиентам, которые способны вести столь же увлеченные беседы о «сегментировании запросов», «декомпозиции задач» и «кубических моделях представления данных», как и он. Оттого вовсе не вызывает удивления, что, по мнению Влада, обычный пользователь Sagent Information Studio глубоко информирован в области баз данных.

Элис Блэр, менеджер компании по продукту Information Studio, в свою очередь проводит значительную часть времени, общаясь с теми, кто может потенциально оказаться покупателем продукта. В ее задачи входит объяснение клиентам возможностей продукта и его базового функционала. В результате у Элис складывается впечатление, что среди пользователей присутствует много таких людей, которые либо совсем не знакомы с продуктом, либо умеют обращаться с компьютером только на базовом уровне. Оттого не вызывает удивления, что Элис считает важной необходимость технической поддержки для большинства клиентов.

Кендал Косби – специалист службы технической поддержки компании Sagent. Он не взаимодействует ни с экспертами, ни с неопытными пользователями. Чаще всего он сталкивается с конечными пользователями, уровень которых можно описать как средний. Так как продукт предназначен для упрощения принятия решений, Кендалу приходится постоянно контактировать с аналитиками в сфере финансов и рынка, которые имеют незначительное представление о компьютерах и базах данных, но которым тем не менее требуется иметь доступ к различным хранилищам данных и инструментам аналитики продаж для решения рабочих задач. Ввиду того что указанные специалисты, с которыми общается Кендал, не слишком подкованы во взаимодействии с компьютером, ему представляется удобным, чтобы программа не отображала функционал либо скрывала хотя бы самые сложные опции. Из трех упомянутых специалистов наиболее точно клиента видит Кендал, но у Влада и Элис гораздо больше возможностей повлиять на архитектуру продукта, в связи с занимаемыми должностями.

Существует одна старинная притча, в которой нескольким незрячим людям впервые попадается на дороге слон. Один из них подходит к ноге слона, ощупывает ее и делает вывод относительно объекта в целом, что «это, должно быть, дерево». Другой подходит к слону со своей стороны, ощупывает бок и объявляет, что «это, должно быть, стена». Третий ощупывает хобот слона и говорит, что «это, должно быть, змея». Равно как и эти незрячие, Элис, Кендал и Влад обладают весьма различными представлениями о сущности клиентов, ввиду того что им приходится общаться с непересекающимися подмножествами пользователей. Если не сказать больше – у каждого из них есть собственное эмпирическое подтверждение своих гипотез. Потому для получения точного объективного портрета потенциального пользователя необходимо заручиться поддержкой человека, который не втянут в ежедневные рутинные процессы как разработки, так и продаж.

Кровный интерес

Один из факторов в культуре разработки ПО, имеющий весомое значение, – уединенность. Программисты обычно работают поодиночке, каждый отдельный фрагмент кода пишет только один программист. Никто не видит, что именно он набирает, а впоследствии этот код, как правило, никто не читает. Читать код, написанный другим специалистом, – это все равно что пытаться разобраться в чужих конспектах, которые представляют собой непостижимые секретные письмена, а вовсе не художественный роман. Процесс программирования является настолько сложным, что требует от разработчика долгой многочасовой работы без перерыва с максимальной целенаправленной концентрацией. Программисты очень чувствительны к своему уединению и всему, что этому сопутствует. Поскольку никто не контролирует, что пишет в коде программист, программисты отдают себе полный отчет в том, что качество кода целиком лежит на их совести. Руководители могут требовать от них должного уровня качества, однако они не станут затрачивать лишнее время и усилия на проверку, что это качество действительно существует. На расшифровку кода может уйти в разы больше времени, нежели изначально было затрачено на то, чтобы его написать. Программисты прекрасно понимают, что от их собственных действий и решений – больше, чем от чего-либо другого, – зависит, что за продукт получится в итоге и насколько будет доволен пользователь. Они несут личную ответственность за успешность конечного продукта. Поэтому их заинтересованность в успехе всего предприятия очень высока.

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

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

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

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

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

* * *

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

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

Сложность ситуации возрастает из-за того, что в типичном процессе разработки проектирование взаимодействия и его реализация переплетаются слишком тесно. И хотя руководитель может потребовать от разработчика внести изменения в поведение программы, он не может заставить его использовать другие методы разработки. Однако именно из-за столь тесной взаимосвязи между поведением программы и его реализацией невозможно затронуть одно, не затрагивая другое. Это одна из тех проблем, которые Муди заметил в период его пребывания в Microsoft.

Большинство из тех, кто вовлечен в разработку программных продуктов, желают, чтобы уж их-то творения отличались простотой в применении. В результате они беспрестанно вмешиваются в деятельность программистов, а у тех, в свою очередь, обычно не бывает свободного времени, так что подобные вмешательства их крайне раздражают. Это вынуждает многих из них прибегать к изоляции от остальных и взаимодействовать с прочими участниками команды разработки, не занятых в программировании, лишь в самом крайнем случае. Тамра Хизершоу-Харт однажды рассказала мне, какие приключения ее поджидали, когда она занимала позицию технического писателя и нуждалась в информации от программистов.

Я обнаружила, что подкуп в случае с программистами работает гораздо эффективнее, нежели просьбы. Чаще всего мне в этом помогал шоколад. Метод подкупа оказался настолько хорошим, что однажды руководитель группы разработки на коленях перед всеми умолял меня простить его за то, что он забыл сказать мне о внесении изменений в продукт. (И да, он все равно получил свое лакомство.) А в одной компании мне довелось работать с инженером, который так «подсел» на шоколад, что даже рассказывал мне об изменениях, внесенных его коллегами, лишь бы только самому получить порцию шоколада, предназначенную им. До того как я испробовала метод шоколада, мне приходилось тратить уйму времени, пытаясь выяснить, что же изменилось в продукте. При помощи подкупа мне удалось больше чем в два раза сократить время переработок.

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

* * *

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

Чтобы изменить написанный код, в первую очередь вам нужно повлиять на сознание программиста. Он заинтересован одновременно и в том, чтобы сохранить уже написанное, и в том, чтобы не делать лишней (по его мнению) работы относительно изменения кода. При этом недостаточно потребовать или даже просто попросить, нужно привести рациональный, обоснованный довод в пользу изменений, причем представленный знакомыми инженеру концепциями, и исходить это должно из уст человека, кровно заинтересованного в положительном исходе.

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