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

ОглавлениеДобавить в закладки К обложке

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

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

Как руководить индивидуалистами

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

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

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

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

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

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

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


-= 29 =-
Регистрация.
Забыли пароль?
Логин
Пароль
Запомнить меня