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

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

Механизм расходования средств требует обоснования, однако анализировать нужно не только затраты, представляющие только одну часть уравнения, но и прибыль от инвестиций. Например, австралийский консультант Роб Томсет (Rob Thomsett) показал, что одинаковую отдачу можно получить как от инвестирования в CASE-технологии, так и от вложений в формирование команды, однако конечная прибыль от инвестирования в командную работу будет на порядок больше. Тем не менее CASE — это яркая технология, которую можно показать, тогда как эффективная командная работа невидима, поэтому многие компании предпочитают тратить деньги на аппаратные и программные средства, а не на человеческий фактор (peopleware).

Думайте о прибыли от инвестирования, а не о сдерживании расходов

Поощрение и признание

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

Проблема не в том, что люди не заботятся о качестве, как жалуются некоторые руководители. Исследование (1991 г.), проведенное компанией Brooks International и охватившее 11000 человек из 6 отраслей, показало, что более 90 % работников чувствовали личную ответственность за качественное выполнение работы. Однако семь человек из десяти заявили, что качество не было важным фактором в оценке их деятельности. И только 25 % опрошенных утверждали, что руководство действительно оценивало повышение качества. Так что же мы поощряем? На самом деле признание и поощрения любого рода намного более редки, чем думают большинство руководителей. Почти 80 % руководителей искренне утверждают, что их подчиненные получают достаточное поощрение, но только один из семи подчиненных соглашается с этим (Lickert, 1989 [48]).

Для улучшения качества необходимо воспользоваться принципом Фербе-ра (Ferber Principle). Психиатра Эндрю Фербера (Andrew Ferber) однажды спросили, что является самым важным для начинающих терапевтов, стремящихся помочь семьям, с которыми они работают. Он ответил:

Когда вы видите то, что вам нравится, начинайте хлопать в ладоши как сумасшедший

Измерение и контроль

Почти каждый слышал изречение, утверждающее, что нельзя контролировать то, что нельзя измерить (DeMarco, 1982 [32]). Часто такие слова оказываются прелюдией к активной кампании по запуску проекта, связанного с измерением параметров программного обеспечения или обеспечением статистического контроля качества. У формальных измерений есть множество преимуществ. Однако если на мгновение задуматься, то можно понять, что в жизни есть много важных вещей, которые родители, учителя, руководители контролируют, но не измеряют. Многое вообще нельзя измерить. Когда речь заходит о людях, то важным становится внимание, а не измерение. Значение имеет то, что вы контролируете. Любой хороший родитель знает: чем больше обращать внимание на капризы, тем больше будет капризов, У систем вообще и у человеческих систем в частности есть особенность, согласно которой само наблюдение изменяет предмет наблюдения. На этом основан хорошо известный эффект Хо-ворна (Hawthorne effect): если сделать группу объектом наблюдения и просто уделять больше внимания ее работе, это приведет к повышению производительности.

Уделяйте внимание

Безусловно, объект ваших наблюдений имеет значение, потому что именно на него и будет оказываться воздействие. Если оценивать программистов по краткости написанного кода, они будут производить меньшие по размеру системы. Если критерием является дружественность системы по отношению к пользователю, то вы получаете более удобные программы (Weinberg и Schulman, 1974 [66]).

Перейти на страницу:

Похожие книги

Основы программирования в Linux
Основы программирования в Linux

В четвертом издании популярного руководства даны основы программирования в операционной системе Linux. Рассмотрены: использование библиотек C/C++ и стан­дартных средств разработки, организация системных вызовов, файловый ввод/вывод, взаимодействие процессов, программирование средствами командной оболочки, создание графических пользовательских интерфейсов с помощью инструментальных средств GTK+ или Qt, применение сокетов и др. Описана компиляция программ, их компоновка c библиотеками и работа с терминальным вводом/выводом. Даны приемы написания приложений в средах GNOME® и KDE®, хранения данных с использованием СУБД MySQL® и отладки программ. Книга хорошо структурирована, что делает обучение легким и быстрым. Для начинающих Linux-программистов

Нейл Мэтью , Ричард Стоунс , Татьяна Коротяева

ОС и Сети / Программирование / Книги по IT
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

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

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT
Программист-прагматик. Путь от подмастерья к мастеру
Программист-прагматик. Путь от подмастерья к мастеру

Находясь на переднем крае программирования, книга "Программист-прагматик. Путь от подмастерья к мастеру" абстрагируется от всевозрастающей специализации и технических тонкостей разработки программ на современном уровне, чтобы исследовать суть процесса – требования к работоспособной и поддерживаемой программе, приводящей пользователей в восторг. Книга охватывает различные темы – от личной ответственности и карьерного роста до архитектурных методик, придающих программам гибкость и простоту в адаптации и повторном использовании.Прочитав эту книгу, вы научитесь:Бороться с недостатками программного обеспечения;Избегать ловушек, связанных с дублированием знания;Создавать гибкие, динамичные и адаптируемые программы;Избегать программирования в расчете на совпадение;Защищать вашу программу при помощи контрактов, утверждений и исключений;Собирать реальные требования;Осуществлять безжалостное и эффективное тестирование;Приводить в восторг ваших пользователей;Формировать команды из программистов-прагматиков и с помощью автоматизации делать ваши разработки более точными.

А. Алексашин , Дэвид Томас , Эндрю Хант

Программирование / Книги по IT