Форма входа
0/0
Человеческий фактор в программировании - Ларри Константин
- Дата:19.08.2024
- Категория: Бизнес / Управление, подбор персонала
- Название: Человеческий фактор в программировании
- Автор: Ларри Константин
- Просмотров:0
- Комментариев:0
Уважаемые читатели!
Тут можно читать бесплатно Человеческий фактор в программировании - Ларри Константин. Жанр: Управление, подбор персонала. Так же Вы можете читать полную версию (весь текст) онлайн книги без регистрации и SMS на сайте Knigi-online.info (книги онлайн) или прочесть краткое содержание, описание, предисловие (аннотацию) от автора и ознакомиться с отзывами (комментариями) о произведении.
Описание онлайн-книги Человеческий фактор в программировании - Ларри Константин:
Хорошее программное обеспечение создается людьми. Так же как и плохое. Именно поэтому основная тема этой книги — не аппаратное и не программное обеспечение, а человеческий фактор в программировании (peopleware). Первое издание «Constantine on Peopleware» признано классическим трудом в области информационных технологий. Новая книга Ларри Константина включает все 52 легендарные статьи из предыдущей книги и 25 новых эссе.Peopleware охватывает все аспекты, связанные с ролью людей в разработке программного обеспечения. Это качество и продуктивность, модели и методы, динамика поведения коллектива, руководство проектами, разработка интерфейсов и взаимодействие между человеком и компьютером, психология и процессы мышления. В данное издание включены два новых раздела, посвященных организационной культуре и юзабилити программных продуктов.Название оригинала на английском языке: The Peopleware Papers by Larry L. Constantine
Читем онлайн Человеческий фактор в программировании - Ларри Константин
Шрифт:
-
+
Интервал:
-
+
Закладка:
Сделать
Кроме того, согласие более достижимо, если каждый из нас верит, что подготовка более совершенного программного продукта важнее, чем принятие наших собственных идей в заранее предопределенной форме. Такое отношение к качеству конечного продукта дает возможность увидеть достоинства всех идей, рождающихся в групповом обсуждении.
Всегда полезно, когда работа в команде ценится больше, чем индивидуальное самовыражение. Компании, где индивидуальная эффективность поощряется больше, чем успех всей группы, а программистам-одиночкам отдается большее предпочтение, чем командным игрокам, обычно превращаются в сборище бескомпромиссных одиночек, которые, вероятно, не будут (да и не смогут) играть в командные игры. В таких компаниях приходят к справедливому выводу, что их лучшее программное обеспечение создается гениями, стремящимися к обособленности. Однако, руководители таких компаний не понимают, что сами же и создали эту ситуацию. Хотя, конечно, все может сложиться и по-другому.
Важнейшее правило достижения технического компромисса таково: никаких махинаций! Торговля голосами, поддержкой или влиянием — это одна из классических тактик для достижения политического успеха, но она может снизить эффективность технических решений. Например, при разработке интерфейса можно заключить сделку. Я соглашусь с вашей глупой идеей поместить панель с кнопками внизу экрана, если вы согласитесь с моим отличным предложением сделать пиктограммы без надписей. В результате мы получаем интерфейс, качество которого оставляет желать лучшего уже по двум признакам. Махинации — это тот же компромисс, только в другом, еще худшем виде, поскольку в этом случае одни решения портят другие. Для достижения настоящего согласия каждый технический вопрос должен рассматриваться отдельно, по существу, а не как часть некоторой системы подсчета очков, в которой уступки в одной области можно выторговать упрямством в другой.
Только фактыПринято считать, что технические решения принимаются в ходе обсуждения технических материй — фактов, количественных оценок, практического опыта. Правда же состоит в том, что чувства, мнения, интуиция и обыкновенные человеческие пристрастия играют роль во всех процессах принятия решений и преодоления трудностей. Это вполне объяснимо, поскольку люди остаются людьми. И хотя некоторые люди пытаются отрицать, сдерживать или подавлять такие иррациональные проявления, это никогда не удается в полной мере.
Важнейшим умением для любой команды, надеющейся достичь технического консенсуса, является умение отделять факты от мнений. Если группе необходимо найти наилучшие варианты и подойти к решению задач творчески, то для этого сотрудники группы должны получить доступ к самым надежным данным и понимать, какого рода информация у них есть. Сами по себе мнения не являются плохими, и члены команды должны иметь возможность свободно их выражать. Мнения могут быть даже полезными, особенно когда они подкреплены ценным опытом, но их нельзя смешивать с фактами, данными или анализом. К слову сказать, факты тоже имеют свои ограничения. В области эстетики или рыночной привлекательности фактов может недоставать. К сожалению, некоторые сотрудники рабочей группы, однажды придя к какому-то решению, перестают обращать внимание на факты.
Ничто не может стать фактом просто потому, что вы это так назвали. Поэтому группам следует учиться пресекать пустословие и договориться не злоупотреблять средствами языка. В первые годы нашей совместной жизни моя первая жена научилась с подозрением относиться к любым утверждениям, которые я начинал с фразы наподобие: «Факты ясно свидетельствуют, что…». Это было сигналом, что далее, вероятно, последует глубоко личное мнение, не подкрепленное ни данными, ни доказательствами. После того как этот гамбит перестал действовать, за мной стали иногда замечать приверженность к другой тактике, которую мы назвали ходом «95 % всех ученых». Некоторые из вас, наверное, поняли, о чем идет речь. «Вы знаете, этот метод предпочитает большинство, уж точно более 95 % профессиональных программистов-разработчиков». Естественно, для того чтобы продолжать пользоваться этой уловкой, вам нужно варьировать проценты. «Почти 78 % пользователей WordPerfect знают, что лучшим способом является…» или «Если провести опрос, то более двух третей программистов, пишущих на С, согласятся, что…». Иногда кажется, что стоит только присмотреться, как увидишь легионы ученых, программистов-разработчиков или конечных пользователей, выстроившихся в ряд позади говорящего, чтобы лично поддержать его (или ее) точку зрения.
Но это только мое мнение.
Из журнала Computer Language Magazine, том 9, № 4, апрель 1992 г.
Достижение консенсусаКонсенсуса нельзя достичь до тех пор, пока вы сами не признаете его наличие. Это значит, что в группах по разработке программного обеспечения, стремящихся к коллективным решениям, разумно заранее договориться о критериях, относительно которых будут решаться технические вопросы. Что является важным? Что имеет значение? Что «хорошо», а что «плохо» в рамках данного проекта?
Часто, когда какая-нибудь группа застревает, проводя анализ или принимая проектное решение, а участники группы говорят: «Мы не знаем, как поступить», я спрашиваю их: «Как вы определяете, какой подход лучше?». Инжиниринг связан с поиском компромиссов — согласия на уступки в одном в обмен на уступки в другом. В любом проекте компромисс требует понимания ценности того, что приобретается или теряется при взаимных уступках.
Почти во всех областях инжиниринга проектные решения принимаются по конкурирующим критериям. Отвечать всем этим критериям в равной мере и по каждому пункту невозможно. В большинстве проектов ставятся технические и экономические цели. Обычно требуется завершение проектов в срок, эффективность продукта, простота и удобство в использовании, пригодность для продажи, масштабируемость, удобство сопровождения и множество других достоинств, приближающих продукт к идеальному. Как же все это оценивать?
Непосредственные приоритетыВсегда полезно, когда приоритеты — непосредственные. Знатоки метрик, возможно, станут убеждать вас свести критерии, по которым принимаются решения, к математическим формулам, учитывающим каждый фактор с помощью весовых коэффициентов и степеней. Однако в общем случае это не является ни необходимым, ни особенно полезным. Достаточно простого выстраивания критериев в определенном порядке. Во время анализа и проектирования, когда должно быть найдено большинство компромиссных решений, у нас редко (если вообще когда-либо) есть все данные для того, чтобы дать нашим представлениям о степени важности тех или иных критериев хотя бы приблизительную количественную оценку. Неверный рецепт, составленный из интуитивных «оценок-догадок», может создать опасное своей обманчивостью впечатление объективности. Это может даже стать спасательным кругом, с помощью которого команда разработчиков может уйти от ответственности. «Ну вот, мы все сделали по рецепту, и не мы виноваты, что на обновление экрана уходит 17 секунд».
На этой странице вы можете бесплатно читать книгу Человеческий фактор в программировании - Ларри Константин бесплатно.
Похожие на Человеческий фактор в программировании - Ларри Константин книги
- Интерфейс: новые направления в проектировании компьютерных систем - Джефф Раскин - Техническая литература
- Мэйсон - John Hall - Боевая фантастика / Боевик / Научная Фантастика
- Право социального обеспечения - Владимир Галаганов - Детская образовательная литература
- Компьютерра PDA N143 (29.10.2011-04.11.2011) - Компьютерра - Прочая околокомпьтерная литература
- Быть полезным: Семь инструментов для жизни - Арнольд Шварценеггер - Прочая старинная литература
