Одиночество программиста обостряет его ощущение собственной власти. Некоторые испытывают дискомфорт, но еще больший дискомфорт доставляет им передача полномочий тем, кто не столь заинтересован в исходе. К советам маркетологов, руководителей, проектировщиков программисты относятся со здоровой долей скептицизма. Они знают, что приняв совет, который окажется ошибочным, примут всю вину за произошедшее, потому что к моменту наказания советчика уже и в помине не будет.
Когда программистам разрешается самостоятельно выполнять проектирование взаимодействия, это приводит к некачественному проектированию, а кроме того имеет еще и дополнительный эффект: программисты теряют уважение к процессу проектирования.
Программисты уже так много раз успешно продирались через процесс проектирования, что привыкли игнорировать его ценность. Когда компания, наконец, нанимает проектировщика взаимодействия, программист само собой, относится к его работе снисходительно.
Это приводит к общему недостатку уважения к проектировщику, к процессу проектирования, и, что прискорбно, к собственно проектированию. Такое неуважительное отношение укрепляет внутрикультурную оценку проектирования, как мнения или туманного совета, тогда как на деле это четкое, конкретное и недвусмысленное указание. Поскольку программист, имея на это все основания, считает, что его прихоть имеет вес не меньший, чем чье-то простое мнение, он полагает себя вправе выбирать приглянувшиеся элементы архитектуры из спецификации. Он считает письменную спецификацию не чертежом, но страницей газеты, на которой публикуются письма в редакцию. Некоторые абзацы занимательны, но неверны, другие полезны, но не имеют отношения к делу. К несчастью, программист принимает эти решения, исходя из соображений реализации или собственных предпочтений, а потому решения часто ошибочны.
С другой стороны, каждый программист имеет в запасе ужасные истории о том, как хорошие продукты превращаются в неудачные из-за дурацких указаний, исходящих от руководителей, точно так же не понимающих, чего может хотеть пользователь. Мне вспоминается один высокопоставленный руководящий работник, который ненавидел клавиатуру, а потом требовал, чтобы все программы компании управлялись только мышью. А другой высокопоставленный руководящий работник, неуклюжий в обращении с мышью, заявил, что все программы компании должны управляться только с клавиатуры. Это пагубное проектирование, основанное на личных предпочтениях, вызвало в обеих компаниях взрыв отчаяния.
* * *
Конечно, существуют программисты, сознательно выбирающие злобное и разрушительное поведение, однако, если судить по тем многим программистам, что встречались мне, они столь же редки, как зубы у курицы. Программисты – как пилоты истребителей: после длительного обучения и трудного достижения пика своих способностей они неизбежно начинают считать непрограммистов менее компетентными. Разработчики программного обеспечения уважают других в привычных областях деятельности, но если непрограммист ступает в мир программирования, как описывал Муди, программисты ведут себя покровительственно или даже высокомерно.
Программист имеет все основания презрительно посмеиваться над дилетантами, сующими нос в мир разработки программ. Точно так же, если программист постучится в дверь финансового инспектора и начнет проверять выкладки по возвратам, инспектор сможет с полным правом посмеяться над самонадеянностью и заносчивостью сунувшегося не в свое дело программиста.
Сложность как раз в том, что проектирование взаимодействия и реализация взаимодействия тесно переплетаются в типичном процессе разработки. Руководитель может попросить изменить поведение программы, но не попросит программиста сменить методы разработки. Но именно потому, что поведение и реализация столь тесно связаны, невозможно посягнуть на одно, не создав впечатления покушения и на второе. Это одна из трудностей, наблюдавшихся Муди в Мiсrоsоft.
Люди, вовлеченные в создание продуктов, основанных на программном обеспечении, хотят, чтобы уж их-то продукты были просты в применении. Как следствие, они постоянно вторгаются на территорию программистов, у разработчиков же никогда нет лишнего времени, и такие вторжения могут делать их вспыльчивыми. Многие уединяются и лишь по крайней необходимости общаются с теми участниками команды, которые не занимаются программированием. Тамра Хитершоу-Харт (Таmrа Heathershaw-Hart) поведала мне о своих приключениях в роли технического писателя, которому требуется получать информацию от программистов.
Я обнаружила, что подкуп гораздо эффективнее уговоров. В основном использовала шоколад. Подкуп действовал настолько хорошо, что однажды руководитель группы, пав на колени, публично извинялся передо мной, что забыл уведомить об изменениях в продукте. (Да, свое угощение он все равно получил.) В одной компании пристрастившийся к шоколаду инженер рассказывал мне обо всех изменениях, внесенных его коллегами, чтобы получить и их шоколад. До открытия такого способа подкупа я потратила массу времени сверхурочно, пытаясь выяснить, каким образом изменился продукт. Подкуп же позволил сократить сверхурочную работу раза в два.
Эта история занимательна потому, что, обладая хоть каким-то опытом в деле разработки программного обеспечения, мы немедленно признаем, что она правдива. Услышь вы историю про инспектора, вынужденного подкупать шоколадкой клерка, работающего с дебиторскими счетами, чтобы получить информацию по сегодняшним депозитам, вы бы пришли в изумление, негодование и отнеслись бы к рассказу с недоверием.
* * *
Многие руководящие работники привыкли, что подчиненные немедленно реагируют на любое указание или даже мягкий намек, исходящий от начальства. Они воображают, что программисты (технический персонал) не слишком высоко находятся на тотемном столбе власти, и поэтому послушно будут следовать указаниям вышестоящих. С точки же зрения программиста руководящий работник в этой игре ничем не рискует, поэтому повиноваться не хочет. Независимо мыслящий разработчик программного обеспечения не изменит свой код просто потому, что кто-то этого потребовал, независимо от важности персоны попросившего.
Если вы хотите изменить существующий код, необходимо, прежде всего, изменить сознание программиста. Он заинтересован как в сохранении существующего кода, так и в том, чтобы избежать кажущихся ненужными усилий, направленных на изменение кода. Нельзя просто потребовать, а тем более попросить, но следует представить рациональную, обоснованную причину для изменений. Причем представить в терминах, понятных инженеру, и из уст человека, кровно заинтересованного в исходе.
В высшей степени точный и разоблачающий анализ образа мыслей и поведения программистов приводит в своей книге Пол Глен (Paul Glen)23. Искренне советую прочитать ее всем, кто хочет глубже изучить программистов и их культуру.
Проектирование программного обеспечения находится под влиянием фактора, который я называю «дефицитным мышлением». На создание этого фактора работают две силы. Новизна индустрии программного обеспечения широко известна, однако именно эта молодость противодействует самоанализу. Мы слишком заняты ассимиляцией новых технологий, чтобы задумываться о недоразумениях, окружающих более старые. Как следствие, индустрия программного обеспечения переполнена мифами и недоразумениями, которые никто не ставит под сомнение.
Изумительно, но простой и очевидный факт, что компьютеры сегодня намного мощнее, дешевле и быстрее, чем всего несколько лет назад, не осознан до конца практиками разработки программ. Поэтому большинство приложений не слишком усердны в обслуживании пользователей. Наоборот, приложения встают стеной на защиту центрального процессора из-за ошибочного тезиса, гласящего, что он перегружен работой. В результате программные продукты перегружают работой пользователей. Идеолог проектирования Билл Могридж (Вill Moggridge) так говорит об этом подходе: «Будь добр к микросхемам и жесток к пользователю».
За последнее десятилетие невероятный прогресс в области компьютерной техники сделал обычным явлением мощнейшие настольные компьютеры по доступным ценам. Любой студент и любая домохозяйка могут обладать мощью, которой в 1974 году позавидовал бы центр обработки данных компании General Motors. И при всем том для создания программ сегодня в большинстве случаев применяются инструменты, технологии, методы и умонастроения, основанные на дефицитном мышлении. Разработчики привыкли задаваться вопросом: «Уложимся ли? Будет ли реакция достаточно быстрой? Какую некритичную функциональность мы можем исключить, чтобы сделать программу более эффективной?» Из рассмотрения исключаются вопросы, имеющие большее отношение к делу: «Поймет ли пользователь? Можем ли мы представить информацию в осмысленном виде? Подходит ли этот набор инструкций для целей пользователя? Какая информация является для пользователя первоочередной?»
