Ларри Константин - Человеческий фактор в программировании

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

На случай каких-либо сомнений важно отметить, что я и сам являюсь одиночкой (по крайней мере, мне так говорили). На самом деле я был официально отнесен к типу одиночек Полом Вордом (Paul Ward) — методистом, ставшим историком, — в его истории структурного анализа (Ward, 1992 [64]). Он лично заверил меня, что это нужно воспринимать как комплимент. Конечно, большую часть моей профессиональной жизни я не был конформистом. Современная разработка программного обеспечения может охватывать многие основные принципы структурного проектирования. В качестве ортодоксальной технической иконографии могут применяться инструменты CASE, среды комплексной разработки, схемы потоков данных и блок-схемы, однако так было не всегда. В это трудно поверить, но все эти схемы когда-то считались отступлением от традиций и даже радикальным бредом индивидуалистов.

Я верю в индивидуалистов; многие из моих друзей — одиночки. И я верю в индивидуалистское воображение, в индивидуальное творчество как источник почти всех подлинных новшеств. Я также считаю, что индивидуализм — это истинная причина большинства глупых ошибок. На каждого

Эйнштейна находится целая толпа Великовских.[16] Иногда нововведения и идиотизм даже исходят из одного и того же источника, как от Теслы (Tesla) или Вильгельма Рейха (Wilhelm Reich)2. Так или иначе, индивидуалис-ты-одиночки обогатили нашу жизнь — если не всегда чем-то полезным, то хотя бы развлечениями.

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

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

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

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

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

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

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

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

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