Александр Новичков, Галина Карабанова, Александр Шамрай: IT и психология. Человеческий фактор в парном программировании: почему многие не получают желаемого от его внедрения?

Александр Новичков, Галина Карабанова, Александр Шамрай

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

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

А вы друзья как не садитесь, все в музыканты не годитесь…
Сами знаете, чья это басня

Сфера IT полна парадоксов и противоречий! Ожидая от компьютерных программ математической точности, мы забываем о том, что их делают люди… А программы наследуют все те же «черты характера», которые присущи их разработчикам: педантичность, аккуратность, взбалмошность, непостоянство, системность, надежность и т.д. Хорошая команда работает единым слаженным организмом, и продукт у нее получается цельный, стройный, гармоничный и не глючный. Если же над программным продуктом работает группа плохо ладящих друг с другом людей, то единого целого не будет, системы не будет, будет просто сборище различных частей, не всегда даже сочетающихся друг с другом, и у каждой части будет свой характер, и не известно будет, чего ожидать от продукта в целом.

К сожалению, у нас в IT, в Российском IT, уделяется очень мало внимания работе с людьми. Причем это происходит на всех уровнях: от тимлидов до генеральных директоров.

На своих тренингах мы очень часто спрашиваем участников – руководителей и тимлидов:

1. Сколько книжек по проектному управлению вы прочитали за год?
2. Сколько книжек по психологии вы прочитали за год?

И если по первому вопросу найдется на 15 человек 3-4, которые прочитали всего одну книгу, то о психологии и говорить не приходится: 0 из 15 человек – такова статистика… Сам собой напрашивается не очень приятный вывод: ТЕХНАРИ не читают ГУМАНИТАРНЫХ книг… А зря

Как вы думаете, сколько чистых технарей в природе? Не так давно нам попалась статья, в которой приводились результаты опроса 11634 человек, разного возраста и полов. Цель была одна — выяснить соотношение гуманитариев и технарей. Причем исследование проводилось в двух плоскостях: в одной людей опрашивали «кем вы себя считаете?», а во второй пропускали через тесты и выявляли соответствующие способности. Получилась интересная статистика по результатам тестов на способности:

• Не гуманитарий и не технарь — 8%
• Гуманитарий, но не технарь — 28%
• Технарь, но не гуманитарий — 8%
• И технарь, и гуманитарий — 31%
• омневающийся — 5%

Самооценка и тестирование способностей. Заметьте разницу в оценке своих возможностей теми, кто считает себя чистыми технарями!

Как видим, чистых технарей, по тесту всего 8%. Кстати, а вот во время интервью 17% респондентов дали утвердительную самооценку «Технарь, но не гуманитарий». Гуманитарии в свою очередь не ошиблись — их самооценка совпала со способностями. Получается, что даже если вы считаете себя «чистым» технарем, вполне возможно, вы ошибаетесь

Широко распространенное заблуждение: если взять задачу и найти крутых специалистов, то все решится – если не само собой, то очень быстро и эффективно. О таких «мелочах», как совместимость людей, психологическое состояние, тип мышления – просто не заботятся. Причем, это не злой умысел, а просто об этом никто не задумывается. А между тем важно понимать, что человеческий фактор в широком смысле этого слова может позволить как «вытянуть» проект, так и тем более он способен его похоронить.

Возможно, это и интересная для дискуссии тема, но мы не будем рассуждать о том, как у нас в IT становятся руководителями… В лучшем случае в кресле руководителя вы встретите человека с хорошим знанием предмета, но ничего не знающего в управлении, и, как правило, совсем профана в психологии, не редко не умеющего связать двух слов и членораздельно объяснить подчиненным, чего же он хочет на самом деле. (Если вы из числа тех руководителей, к которым это не относится, и вы немного слышали о психологии и разбираетесь в менеджменте, то мы вас поздравляем – вы попали в те 5% счастливчиков, которые скорее являются исключением из правила!) И, в общем-то, это даже не вина руководителей. Просто нас так учат: начиная с вуза, если мы выбрали техническую специальность, нам твердят, что все остальное знать не обязательно… Вот и получается: сначала не обязательно, а потом – некогда.

К чему мы ведем?

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

Давайте разберемся! А чтобы разобраться, обратимся к психологии. То есть к той области знаний, которая как раз и изучает нас, людей: наше поведение, наши поступки, наши мысли, чувства, настроения, состояния и так далее. Прежде всего, важно понимать, что два человека – это не набор документированных процедур, вызывая которые можно получить желаемое. Люди гораздо сложнее. Говоря об этом, Алистэр Коуберн называет людей «нелинейными и наиболее важными компонентами в разработке программного обеспечения» [1]. Наибольшая сложность заключается в том, что «человек — существо изменчивое, он меняется в зависимости и от времени, и от пространства» [1], и от многих других факторов…

Кстати, ребята, которые придумали и XP и Scrum, очень хорошо разбирались в психологии. Подтверждается это и тем, с какой любовью данные методологии внедряются в компаниях. Айтишники просто сами не осознают, что, на самом деле, для них взяли лучшие практики из психологии, направленные, в том числе, на возникновение драйва, положительных эмоций и командного духа, облачили это все в понятную для ТЕХНАРЕЙ оболочку и дали – берите, работайте… И заработало!

Начало. Пары

Не нужно объяснять, что парное программирование начинается с формирования пар… Как это происходит? С кем мы оказываемся в паре? Кто выбирает нам партнера? Или кого выбираем мы?

А.Н. В юности наша компания частенько собиралась у кого-нибудь дома, кто имел хорошую аудио-систему, и мы с упоением слушали забугорные группы: Led Zeppelin, Deep Purple, Pink Floyd и прочие. Пластинки и кассеты в магазинах не продавались, и послушать можно было только у тех, чьи родители выезжали за границу. Но дело не в этом. У нас была игра – мы хотели собрать группу мечты: вокалист оттуда, басист оттуда, гитарист – вон тот самый классный… и так далее. И самое интересное, что в истории рок-музыки были такие супергруппы, которые формировались уже не юношами, но профессионалами. И история каждый раз показывала, что такие группы долго не живут. Я увлекался уже тогда (нет, не самбо и не горными лыжами) психологией и каждый раз говорил, что такая группа не факт, что сработается,… на что мои друзья возражали, что профессионалы на то и профессионалы, а не подростки – они-то умом (!) понимают, у них все будет хорошо…

История показала, что нет. И у них не хорошо. И то, что они профессионалы – это не значит, что они психологически совместимы – т.е. не факт, что не передерутся.

Кстати, мы все ходили в школу, институт. Вспомните школу! С кем вам было приятно сидеть за одной партой? С тем, кого вы выбрали, или с тем, кого выбрал учитель? У меня бывало по-разному: иногда учитель правильно рассаживал детей, руководствуясь некоторыми психологическими приемами, а иногда мне было комфортнее сидеть с приятелем.

Еще А.С. Макаренко [2], работая с детьми-беспризорниками в исправительной колонии им. Горького, формировал группы по принципу «выбери того, кто тебе нравится».

Так кого же мы берем в пару при парном программировании? Того, кто нравится? Или того, кто больше знает? Или, может, все равно кого?

От точки зрения зависит очень многое.

Парное программирование

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

В своей книге Алистер Коуберн [3] говорит, что «при парном программировании разработчики решают все задачи совместными усилиями, работая бок о бок за одним компьютером. За последние несколько десятков лет такая практика уже неоднократно получала самые лестные отзывы, так как с ее помощью удавалось значительно улучшить процесс разработки ПО».

«Однако, – утверждает Коуберн, существует мнение, сводящее на нет любые доводы в пользу парного программирования – многие полагают, что посадить двух программистов за один компьютер, значит поручить двум разработчикам работу одного». Это есть чистая правда – многие так и считают. В России распространено и еще одно мнение: «у нас другой менталитет». Оно, конечно, имеет под собой основу – наша система образования не учит тому, как работать в группах. Но это вроде не страшно – как-то мы выбираем друзей, создаем семьи, входим в какие-то группы… – это не страшно: и у нас могут быть и спаянные группы, и надежные пары.

Там также [3] подробно рассматриваются экономические и прочие выгоды от использования парного программирования:

1. Программисты в сработавшейся паре тратят всего на 15% больше времени. (Запомним термин «в сработавшейся» — он нам пригодится позже).

2. В результате парного программирования код содержит на 15% меньше ошибок, чем код одиночек.

3. Изначальное 15% увеличение стоимости разработки окупается за счет уменьшения количества ошибок. (Заметим, что в статье [3] говорится о 15%-ом увеличении количества часов, затрачиваемых двумя разработчиками на решение одной задачи, по сравнению со временем, которое тратит один разработчик. Если считать в человеко-часах, то получатся совсем другие цифры. Поэтому вывод о всего лишь 15% увеличении стоимости разработки нам кажется сомнительным. Возможно, это опечатка или неточность перевода. А вот окупаемость увеличения стоимости разработки за счет уменьшения количества ошибок вполне реальна.)

4. Повышается общая квалификация программистов: молодые начинают быстро расти, то есть проявляется элемент наставничества – молодого программиста «ведут» более опытные товарищи.

5. Каждый из членов команды при ротации пар охватывает весь проект в целом, а не только свой сегмент – коллективное владение кодом.

6. А также повышение «боевого духа», быстрое обучение всему, а не только программированию и так далее.

Список можно продолжать, но и первых пяти пунктов хватит, чтобы воскликнуть: я тоже хочу, чтоб в моем проекте так было!!!

Но все это не будет работать если:

1. Не получится построить сработавшиеся пары. А не получиться может по многим причинам, большинство которых носят чисто психологический характер: один много болтает, другой молчит… и так далее – важен психологический аспект, такой как банальная совместимость двух людей.

2. Программисты не будут получать удовольствия от парной работы. Тоже психология – программист, как и любой инженер, стремится быть уникальным, много знать и так далее. Он эгоистичен. Как и тот булочник у Адама Смита [4], который вставал в 4 часа утра, чтобы испечь вкусные и румяные булочки. И заботился о том, чтобы они были не очень дорогими. И делал все это отнюдь не из любви к своим покупателям, а потому что хотел заработать. И знал, что есть и другие булочники, которые тоже хотят заработать. Так, думая о собственной выгоде, булочник делал общественное благо.

То же и с парным программированием: если от него есть толк лично для каждого программиста, то парному программированию неминуемо быть.

Адам Смит делает важный вывод: людям не нужно приказывать, чтобы они что-то делали, нужно просто создать такую систему, при которой человек, будучи эгоистичным, думал бы о своих интересах, и, думая о своих интересах, одновременно заботился об интересах потребителя, а, следовательно, и общества в целом. Так он разрешал конфликт между двумя ведущими мотивами человеческой деятельности: альтруизмом и эгоизмом [5].

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

3. Программировать в одиночку гораздо проще и привычнее. Это самый тяжелый фактор – фактор привычки. Всем известно, что «изучить новые способы легко; значительно труднее изменить привычку людей работать так, а не иначе» [6].

4. И прочее, связанное с психологией индивида и психологией группы.

Парное программирование никогда не заработает, если при переходе на него руководитель не будет понимать ВАЖНОСТИ данного перехода, а также того, что люди – не сосуды с описанным набором функций, а эмоционально нестабильные, подверженные различным веянием, меняющие точку зрения в зависимости от настроения… в общем, люди. Мы все индивидуальны, и в случае нас, людей, 1+1 не факт, что будет два.

Итак, важные «за» и возможные «против» мы рассмотрели.

1. Фактор пси.. Немного о психологии

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

Википедия дает следующее определение [7]: это область научного знания, исследующая особенности и закономерности возникновения, формирования и развития (изменения)

• психических процессов (ощущение, восприятие, память, мышление, воображение),
• психических состояний (напряженность, мотивация, фрустрация, эмоции, чувства)
• и психических свойств (направленность, способности, задатки, характер, темперамент) человека, то есть психики как особой формы жизнедеятельности, а также психику животных.

Когда мы говорим о командной разработке программного обеспечения, и о парном программировании, в частности, мы затрагиваем вопросы, связанные с поведением человека в группах. Группы бывают большими и малыми. Различные психологи колеблются в определении того, что считать малой группой, но многие из них сходятся во мнении, что нижняя граница малой группы – это 2 человека, т.е. пара (другие нижней границей считают тройку). Поведение группы и поведение отдельного человека в группе изучает социальная психология.

Социальная психология изучает психологические явления (процессы, состояния и свойства), характеризующие индивида и группу как субъектов социального взаимодействия, а также психологические процессы, состояния и свойства различных социальных групп как целостных образований, отличающихся друг от друга и не сводимых к какому бы то ни было индивиду.

Объекты исследования в социальной психологии

У группы как объекта (не поверите!) есть тоже свой жизненный цикл: они зарождаются, живут и умирают. Можно смеяться, но у групп есть и свои атрибуты (цели и задачи группы, сплоченность, сработанность, конфликтность) и методы, например, такие как групповая динамика. В группе происходят те или иные процессы: лидерство, коллективное принятие решений и др. И группы можно характеризовать через описание групповых состояний: социально-психологического климата группы и конфликтных отношений.

Продуктивность малой группы в зависимости от ее фазы: 1-формирование группы, 2-притирка, 3-нормирование+деятельность, 4-дезинтеграция

Мало того, группы классифицируются по принципу их возникновения и так далее. Все это хорошо описано в учебнике Андреевой Г.М. [8].

Итак, важно понимать, что мы всю жизнь проводим в группах: семья, детсад, школа, работа… и так далее. И прочитать хотя бы одну книжку о социальной психологии необходимо каждому! Хотя бы один раз. Естественно, вы не станете после этого психологом, но у вас возникнет понимание происходящего в коллективе.

Надеемся, мы не слишком утомили вас? Больше ничего сложного не будет.

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

Особенно много экспериментов проведено над индивидами и над малыми группами. Из всего многообразия экспериментов [8,9] нас интересуют те, которые объясняют, почему и что может работать, а что нет, применительно к парному программированию.

Объясняем техники и смысл парного программирования через социальную психологию

2. Суть парного программирования

Казалось бы, простой вопрос – простой ответ, но под ним скрывается целый пласт исследований. Давно было замечено, что люди на публике ведут себя иначе, чем вели бы себя в одиночестве.

Началом лабораторного экспериментирования принято считать эксперименты Н. Трипплетта [10], выполненные в 1897 году. Суть эксперимента состояла в том, чтобы измерить влияние ситуации соревнования на изменение скорости велосипедиста по сравнению с результатами, полученными в одиночной гонке. Испытуемыми были дети. 20 из 40 испытуемых показали в соревновании более высокие результаты, 10 — немного улучшили их, а у 10 наблюдалось даже ухудшение в связи с перевозбуждением (запомним этот факт). Трипплетту принадлежит и термин, которым он определил открытое зафиксированное явление – «социальная фацилитация» (social facilitation), – впоследствии ставшее одним из популярнейших объектов исследования, особенно при написании диссертаций. Здесь, так же, как позднее и во многих других лабораторных экспериментах, устанавливалось то, что было известно людям давным-давно. Главное же достижение состояло в том, что общеизвестные истины могли быть «сосчитаны, измерены и взвешены». Это было огромным шагом вперед.

Почти как у Трипплетта

Феномен получил и второе название «Наблюдатели нас возбуждают» – под этим наименованием в обычных статьях вы и найдете его описание. Погуглите

Рассмотрим еще один эксперимент [11]:

Роберт Зайонц провел ряд экспериментов, в которых просил людей выполнять простые действия и сложные действия. Сначала поодиночке, потом в группах. В результате при многократном повторении было очевидно, что простые действия в присутствии других людей мы делаем лучше, чем когда делаем в одиночку, в то время как выполнению сложных действий дополнительные люди могут и помешать. Гипотеза Зайонца подтвердилась результатами почти 300 исследований, в которых приняли участие более чем 25 000 добровольцев.

И еще один:

Гари Эванс ставил опыт с группой из десяти студентов Университета Массачусетса, размещая их либо в комнате размером 6 на 9 метров, либо 2,4 на 3,7 метра. По сравнению с теми, кто находился в большой комнате, у тех, кто сидел компактно, кровяное давление и пульс были выше.

Делаем выводы:

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

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

Запоминаем: нашу психику изменяет сам факт присутствия других людей.

Применительно к парному программированию:

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

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

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

• «Начинающий» — Начинающий»
• «Начинающий» — «Мастер»
• «Мастер» — «Мастер»

3. Техники парного программирования и продолжение ответа на вопрос о том, как формировать пары

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

Таблица 1. Техники парного программирования

В паре «Начинающий» — «Мастер» первый будет всегда «подавлен», и его производительность упадет, а при ротации мастер будет выполнять свою работу хорошо, но ему будет совсем скучно. Хотя в статье Алистера Коуберна [3] приводится пример, когда «даже новичок может существенно улучшить качество кода», который пишет опытный специалист.

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

А вот пара «Начинающий» — «Старший Начинающий» будет весьма интересна. То есть в пару лучше посадить неопытного с чуть более опытным сотрудником, тогда тут есть место и перениманию опыта и всему остальному.

«Мастер» — «Мастер» — данная пара хороша с точки зрения производительности, но для роста потенциал не очень велик, хотя, определенно, присутствует.

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

Еще раз отметим для руководителей: не все равно, как вы формируете пару – простое склеивание хоть кого хоть с кем даст ерунду!

4. Техника парного программирования «ротация пар» и размер команды

Ротация пар – очень эффективный прием, позволяющий каждому знать проект в целом. Но и тут есть некоторые ограничения.

Проектная команда с точки зрения социальной психологии является малой группой. В социальной психологии есть понятие идеальной группы: 7+-2 человек. То есть максимальное количество участников в идеальной малой группе может быть 9 человек. Это, естественно, не закон, но похоже на правду. Хотя малой группой считается и 10, и 15 и даже 20 и больше человек.

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

При выборе размера команды под проект, в котором будет применяться парное программирование, можно руководствоваться эффектом Рингельмана [10], который показывает, что: «индивидуальная производительность каждого члена группы падает: чем больше группа, тем ниже производительность каждого». При увеличении группы от 1 до 12 человек средние усилия, прилагаемые каждым, уменьшаются примерно на 10%. То есть раздутая команда неизменно «провалится» в производительности, если ее не делить на мелкие подгруппы и т. д., то есть если не применять специальных действий. Руководителю важно в команде найти баланс по количеству, чтобы и общая производительность была на уровне, и ротацию можно было бы осуществлять, не опасаясь за то, что сотрудники «умрут» от объема поступающей информации.

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

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

Застой образуется, если сотрудников не поднимают ни в знаниях, ни в должности. Это плохо для компании, так как люди в итоге будут полностью демотивированы к работе. Этот факт подтверждается экспериментами Селигмана, Джонсона, Хирото [9] и многих других, которые вывели формулу «Выученной беспомощности». То есть если человеку постоянно давать задачи, которые он не может выполнить, если на него повесить ярлык «он ничего не может», то рано или поздно человек в это поверит!!! В экспериментах был выявлен главный фактор, вызывающий выученную беспомощность: предшествующий опыт влияния на испытуемого неприятного воздействия, неподконтрольного испытуемому.

Детально эксперименты рассматривать нет смысла – для этого есть гугл и ссылки в конце статьи. Ниже представлен алгоритм по Хирото, показывающий, как можно заполучить выученную беспомощность.

Модель выученной беспомощности по Хирото

• Постоянные неудачи демотивируют, они настолько «въедаются» в мозг, что человек становится не в состоянии искать выходы. Он несет на себе «бремя безысходности»;
• Постоянная уничижительная критика также демотивирует, вызывая эффект выученной беспомощности. Постоянная негативная оценка снижает уровень самооценки и способна загнать человека в депрессию, вне зависимости от возраста;
• Разрушение образа справедливости приводит к тому, что человек разуверяется в возможности контролировать свои действия, добиваться результата, зависящего от него. Возникает апатия, поведение приобретает черты «жертвы», что является следствием разрушения веры;
• Беспомощность вызывают не сами по себе неприятные события, а опыт неконтролируемости этих событий. Живое существо становится беспомощным, если оно привыкает к тому, что от его активных действий ничего не зависит, что неприятности происходят сами по себе и на их возникновение влиять никак нельзя.

5. Удаленное парное программирование и руководство командой

Очень часто приходится слышать мнение, что «мы используем только удаленное программирование, так как…», и далее следует тирада. Или наоборот – мы его не используем.

Если говорить об эффекте удаленного парного программирования [17], то он, этот самый эффект, непременно есть (если все предыдущие рекомендации выполнены), но не такой, как очный. При удаленном контакте «возбудимость» существенно ниже. Соответственно, и эффект меньше. Проиллюстрировать это можно экспериментом «Подчинение авторитету» американского психолога Стенли Милгрэма.

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

Представьте себе следующую сцену, поставленную Милгрэмом, разносторонне одаренным человеком, обладавшим, в том числе, и талантами писателя и режиссера. Двое мужчин приходят в психологическую лабораторию Йельского университета, где им предстоит принять участие в изучении процессов обучения и памяти. Строгий экспериментатор, одетый в серый рабочий халат, говорит им, что в лаборатории проводится новаторское исследование — изучается влияние наказания на обучение, и требует, чтобы один из них («учитель») заставил другого («ученика») запомнить перечень парных понятий, наказывая за ошибки ударами электрического тока возрастающей силы. Распределение ролей — по жребию: испытуемые тянут из шляпы бумажки. Один из них, 47-летний бухгалтер с мягкими манерами, «подсадная утка», делает вид, что на его бумажке написано «ученик», и его препровождают в соседнюю комнату. «Учитель» (он пришел в лабораторию по газетному объявлению) получает несильный «ознакомительный» удар током, после чего наблюдает за тем, как «ученика» усаживают в кресло, привязывают к нему и закрепляют электроды у него на запястье.

Как далеко зашли бы вы сами? Милгрэм описывал этот эксперимент 110 психиатрам, студентам колледжей и взрослым представителям среднего класса. Все сказали, что, наверное, отказались бы выполнять распоряжения экспериментатора примерно при 135 вольтах и ни за что не «продвинулись» бы дальше 300 вольт. Понимая, что эти ответы могут отражать присущую самооценкам необъективность, Милгрэм спрашивал этих людей, как далеко, по их мнению, способны зайти другие. Практически никто не сказал, что кто-нибудь может дойти до удара, обозначенного на приборной панели символом «XXX». (Психиатры предполагали, что такую возможность допустит один из 1000.)

«Адская» экспериментальная машина Милгрэма (нажмите на изображение, чтобы рассмотреть схему в деталях)

Однако когда участниками эксперимента Милгрэма были 40 мужчин — представители разных профессий в возрасте от 20 до 50 лет, — 26 из них (65%) дошли до 450 вольт. Впрочем, правильнее сказать, что все они подчинялись команде экспериментатора «Продолжать!» до тех пор, пока после двух ударов он сам не останавливал их.

Подчинение экспериментатору зависит также и от его физического присутствия. Когда Милгрэм командовал «учителями» по телефону, количество случаев полного подчинения снизилось до 21% (хотя многие лгали и говорили, что подчиняются). Результаты других исследований позволяют говорить о том, что если отдающий приказ находится рядом, число подчиняющихся ему возрастает. Однако власть должна восприниматься как легитимная, то есть недостаточно просто оставить вместо себя кого-то.

Выводы:

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

То же можно сказать и про руководство командой – чем руководитель ближе, тем выше эффективность.

Заключение

Разумеется, в статье рассмотрены не все аспекты и техники парного программирования, как и не все явления и эксперименты социальной психологии. На самом деле экспериментов, объясняющих психологическую подоплеку многих практик в Agile, значительно больше. Есть объяснение и ежедневным митингам, и почему на митинги можно приглашать гостей, которые не должны вмешиваться в процесс, и так далее. Ответы находятся в социальной психологии. Мы своей статьей ставили цель показать на примере маленькой технической практики, что понимание психологической составляющей и применение техник, позволяющих проявиться положительным эффектам, связанных с человеческим фактором, может привести к ощутимым результатам. Объяснив эффекты парного программирования с точки зрения социальной психологии, мы хотели напомнить о том, что все хорошее потому и работает, что оно естественно с точки зрения нашей психологии, то есть того, как мы устроены. И, конечно, мы надеялись возбудить в нашем читателе желание пойти в магазин и купить самую тонкую книгу по социальной психологии. В этом смысле мы стремились дать направляющие для дальнейшего развития.

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

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

Да будет много хороших команд! И много хороших программных продуктов!

P.S. В следующих частях нашей работы мы подведем теоретическую базу под многие Agile- практики, например, дадим ответы на вопросы: почему спринт должен быть непродолжительным и проходить в одно и то же время, почему они должны проходить утром, зачем каждый участник должен отвечать на вопросы «что есть», «что было» и «что будет» и многие другие. Важно понимать, что разработчики Agile-практик очень эффективно использовали все достижения психологии, направленные на создание и развитие эффективной команды. Даже если вам не нравится Agile, потому что вы любите Microsoft Solutions Framework или ГОСТ или Rational Unified Process, вы вполне можете взять эффективные практики командообразования в свой процесс.

Железки – ничто, люди – все!

Используемые источники:

1. http://www.maxkir.com/sd/people_as_nonlinearRUS.htm
2. http://ru.wikipedia.org/wiki/Макаренко,_Антон_Семенович
3. http://www.e-reading.org.ua/bookreader.php/32275/Koubern_-_Parnoe_programmirovanie__preimushchestva_i_nedostatki.html
4. http://ru.wikipedia.org/wiki/Адам_Смит
5. http://www.tvkultura.ru/theme.html?id=31202&cid=11846
6. Вигерс К.И. Разработка требований к программному обеспечению.: Пер. с англ. – М.: Русская редакция, 2004.
7. http://ru.wikipedia.org/wiki/%D0%9F%D1%81%D0%B8%D1%85%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F
8. Андреева Г.М. Социальная психология
9. Новичков А.Н. Коммуникации и психология: о чем могут рассказать эксперименты психологов?. Презентация с аудиоподкастом
10. Шихирев П.Н. Современная социальная психология
11. А.В.Либин Дифференциальная психология на пересечении европейских, российских и американских традиций
12. http://en.wikipedia.org/wiki/Pair_programming
13. http://www.citforum.idknet.com/SE/project/terehov/3.shtml
14. http://lib.rus.ec/b/96727/read#t2
15. http://habrahabr.ru/blogs/crazydev/132354/
16. http://poltava-ua.com/parnoe_programmirovanie
17. http://freehabr.ru/blog/programming/617.html
18. http://www.nestor.minsk.by/kg/2005/34/kg53402.html
19. http://smileart.in.ua/pair_programming
20. http://rf-biz.ru/85.php
21. http://agilerussia.ru
22. Гуманитарий или технарь: как найти себя и чем может быть полезно тестирование

Статья впервые опубликована в блоге Александра Новичкова.