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

Десятилетия исследований и практический опыт показали нам, что по продуктивности лучшие программисты зачастую на порядок отличаются от худших и в два раза от средних программистов (DeMarco и Lister, 1987 [33]).

[3] Некоторые группы значительно повысили качество своей работы и продуктивность путем простого сокращения штата программистов, оставив только самых лучших. Один подход к повышению качества заключается в том, чтобы взять только самых лучших игроков, предоставить в их распоряжение все ресурсы, создать мотивацию для достижения наилуч-ших результатов в работе и позволить им ее сделать. Такой подход может быть особенно привлекательным в эпоху «сокращения расходов».

Применяйте только самые лучшие ингредиенты

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

Пусть все друг друга учат

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

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

Степени свободы

Как это ни странно, во многих организациях, искренне стремящихся улучшать качество, существуют правила и условия, которые препятствуют его улучшению. Даже такие простые вещи, как способы определения сроков исполнения и составления бюджетов, значительно влияют на качество проектов. Обычно все факторы — бюджет, распределение ресурсов, подбор персонала, методология и сроки исполнения — уже определены на тот момент, когда проект передается разработчикам. На какой стадии можно достичь улучшения качества? Нам нужна по крайней мере одна степень свободы. Если все переменные ограничены, система становится сверхопределенной, а путей к победе у нас нет. Чем при возникновении проблем жертвуют в первую очередь? Качеством! При жестких сроках исполнения, например, устанавливаемых в соответствии с каким-то выдуманным «рыночным окном», дело зачастую доходит до таких высказываний: «У нас нет времени на то, чтобы сделать все как надо». Это указывает на одно из простейших изменений, способных улучшить качество программного обеспечения:

Обсуждайте сроки исполнения

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

Заключение

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

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

По материалам журнала American Programmer, февраль 1992 г.

VI

Юзабилити программного обеспечения

34

Согласованность и условности

Мы окружены пользовательскими интерфейсами. Возможно, этот термин получил широкое распространение благодаря компьютерному программному обеспечению, однако каждая система и каждый компонент оборудования, имеющие пользователя, по определению имеют и пользовательский интерфейс. Как показал психолог и бывший исследователь компании Apple Дональд Норман (Donald Norman, 1988 [53]), мы можем многое узнать о том, как разрабатывать и строить хорошие пользовательские интерфейсы для программного обеспечения, если посмотрим вокруг. Нужно просто подумать о том, как средства управления приборами, устройствами и инструментами делают их применение проще или сложнее.

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