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

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

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

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

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

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

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

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

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

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

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

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

1_graf.jpg

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

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

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

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

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

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

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

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

Начало. Пары

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

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

2_kvartet.gif

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

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

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

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

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

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

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

3_bikes.jpg

В своей книге Алистер Коуберн [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 человека, т.е. пара (другие нижней границей считают тройку). Поведение группы и поведение отдельного человека в группе изучает социальная психология.

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

4_psy.jpg

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

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

5_psy2.jpg

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

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

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

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

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

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

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

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

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

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

6_psy3.jpg

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

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

Рассмотрим еще один эксперимент [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] и многих других, которые вывели формулу «Выученной беспомощности». То есть если человеку постоянно давать задачи, которые он не может выполнить, если на него повесить ярлык «он ничего не может», то рано или поздно человек в это поверит!!! В экспериментах был выявлен главный фактор, вызывающий выученную беспомощность: предшествующий опыт влияния на испытуемого неприятного воздействия, неподконтрольного испытуемому.

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

7_psy4.jpg

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

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

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

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

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

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

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

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

milgr.gif

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

Однако когда участниками эксперимента Милгрэма были 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. Гуманитарий или технарь: как найти себя и чем может быть полезно тестирование

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

Расскажите коллегам:
Эта публикация была размещена на предыдущей версии сайта и перенесена на нынешнюю версию. После переноса некоторые элементы публикации могут отражаться некорректно. Если вы заметили погрешности верстки, сообщите, пожалуйста, по адресу correct@e-xecutive.ru
Комментарии
Нач. отдела, зам. руководителя, Санкт-Петербург
Валерий Овсий пишет: К сожалению опять вынужден быть мелочным в формулировках. У меня сотрудники получают зарплату, бонусы и премии за хорошую работу. А доход (равно и прибыль) получает КОМПАНИЯ за счет а) правильной организации труда, б) передовых технологий, с) высокопроизводительной техники и д) человеческого ресурса высокой квалификации. И моей любви к своему делу ;-))
Ну можно и еще точнее, если уж идти до конца: 1) Зарплата, бонусы и премии - это расходы; 2) Сотрудники любой квалификации (не исключаю, что в Вашей компании нужны исключительно те, которые высокой) - это ресурсы, стоимость которых для компании будет выражена в зарплате, бонусах, премиях, стоимости курсов повышения квалификации, социальных налогах и т.д. Техника, технологии - тоже ресурсы; 3) А вот правильная организация труда - это уже не ресурсы, это уже действия, направленные на использование ресурсов. Итого получаем: прибыль компании = доходы компании - расходы компании (ну это если совсем просто...) При условии, что сотрудники получают зарплату, а доходов у компании нет или они недостаточные, прибыли у нее может и не получиться. Вы, кстати, тоже ресурс - за Вашу ''любовь к делу'' Вы тоже получаете зарплату. Так что я могу и перефразировать, если Вам угодно: думаю, Вы хотите, чтобы расходы (в т.ч. на содержание ресурсов Вашей компании) не превышали доходов Вашей компании. Иначе: чтобы ресурсы компании использовались таким образом, чтобы прибыль была больше нуля. P.S. Не ставила своей целью изложить в этом сообщении курс экономики и управления на предприятии, поэтому здесь перечислены не все виды ресурсов, не все виды расходов и уж совсем не перечислены источники доходов компании. :)
Нач. отдела, зам. руководителя, Санкт-Петербург
Валерий Овсий пишет: Наша же специализация заключается в том, чтобы решить проблемы заказчика ЛЮБЫМИ способами. И вовремя убежать :-))
Ой, совсем на ночь гляды глаз замылился! Это ж надо было такое просмотреть :) Вот Вы все за математическую точность формулировок ратуете, а при этом выводы делаете на пустом месте и с такой молниеносной скоростью, что поди догони! Вот скажите на милость, зачем же бегать от довольного заказчика, у которого ни голова, ни сердце больше не болит? ;)
Старший консультант, Германия
Галина Карабанова пишет: Ну, не похоже, чтобы кто-то, кроме нас (авторов), потерял интерес к этой дискуссии. Целая страница комментариев - однозначно out of scope. Интересненькая ситуация получается (как бы не забыть хронологию событий): 1) Сначала, оказалось, что статья плоха, потому что написана про парное программирование, которого нет.
Галина, Вы не-точно ставите ''фокус внимания''. Проблемой является не то, что статья плохая или хорошая. И не то, что в ней про парное программирование/кодирование. Проблемой является то, что Вы (вместе с другими) под ней -- ПОДПИСЬ СТАВИТЕ. Вот есть там и Ваша фамилия... А прочитать ее, найти ошибки, исправить, подобрать примеры -- УЗНАВАЕМЫЕ и т.д. -- НЕ ХОТИТЕ. Точная цитата из статьи: [COLOR=red=red]Как вы думаете, сколько чистых технарей в природе? Не так давно нам попалась статья, в которой приводились результаты опроса 11634 человек, разного возраста и полов. Цель была одна — выяснить соотношение гуманитариев и технарей. Причем исследование проводилось в двух плоскостях: в одной людей опрашивали «кем вы себя считаете?», а во второй пропускали через тесты и выявляли соответствующие способности. Получилась интересная статистика по результатам тестов на способности: Не гуманитарий и не технарь — 8% Гуманитарий, но не технарь — 28% Технарь, но не гуманитарий — 8% И технарь, и гуманитарий — 31% омневающийся — 5% [/COLOR] Так ПРОСТО НЕ БЫВАЕТ. и когда пишется вот такой ответ
Александр Новичков пишет: На самом деле есть еще, что было в исследовании под словом ''другое''. Для статьи это оказалось не столь важным :)
это просто... человек так ничего и не понял... Вы под статьей свою подпись ставите...
Старший консультант, Германия
Галина Карабанова пишет: Вот скажите на милость, зачем же бегать от довольного заказчика, у которого ни голова, ни сердце больше не болит? ;)
Про то на сайте недавно была отдельная статья ;) , в которой один консультант спрашивал у другого в стиле: ''а как Вы думаете, как долго будет доволен Ваш Заказчик????'' :))))) P.S. Тяжело вам (со-авторам) здесь будет... )))) ... не повезло с поколением читателей вашей статьи... в нашем детстве ''сопипаста'' еще не было... даже калькуляторов... приходилось и читать и считать, не полагаясь на ''плоды прогресса''... трудно будет вам ожидать доброжелательности, когда на то, что два в квадрате не может быть равно пяти... со-автор пишет в стиле ''да, ошибочка, два в квадрате -- это шесть, но для статьи это не важно''...
Консультант, Москва
Александр Володарский пишет: Галина, Вы не-точно ставите ''фокус внимания''. Проблемой является не то, что статья плохая или хорошая. И не то, что в ней про парное программирование/кодирование. Проблемой является то, что Вы (вместе с другими) под ней -- ПОДПИСЬ СТАВИТЕ. Вот есть там и Ваша фамилия... А прочитать ее, найти ошибки, исправить, подобрать примеры -- УЗНАВАЕМЫЕ и т.д. -- НЕ ХОТИТЕ.
Уважаемый, авторы тоже читают этот блог. Давайте перейдем к конструктиву. Что вас не устроило?
Александр Володарский пишет: Так ПРОСТО НЕ БЫВАЕТ. и когда пишется вот такой ответ
Как именно не бывает? А то заглавных букв у вас много, а смысла мало. Если нашли опечатку или вам показалось, что вы наши опечатку - скажите конструктивно. Иначе форум превращается во флудилку. А еще лучше - ответьте своей статьей на нашу неправильную и неточную.
Нач. отдела, зам. руководителя, Санкт-Петербург
Александр Володарский пишет: Галина, Вы не-точно ставите ''фокус внимания''. Проблемой является не то, что статья плохая или хорошая. И не то, что в ней про парное программирование/кодирование. Проблемой является то, что Вы (вместе с другими) под ней -- ПОДПИСЬ СТАВИТЕ. Вот есть там и Ваша фамилия... А прочитать ее, найти ошибки, исправить, подобрать примеры -- УЗНАВАЕМЫЕ и т.д. -- НЕ ХОТИТЕ.
Александр, ни Вы, ни кто-либо еще из участников дискуссии ни меня, ни других авторов не спросили даже о том, чего мы хотим дальше делать с этой статьей, а уже сделали вывод, что мы ничего не хотим. Не хорошо это. Я знаю, что математиков учат решать задачки в уме: чем меньше выкладок на бумаге, тем круче - сама когда в физ.-мат. лицее училась (это к тому, что не такой уж я чистый ''гуманитарий'', в которые меня столь же поспешно уже успел записать один из участников обсуждения), так что знаю не понаслышке. Да вот только к жизни такой подход не очень применим, а особенно к людям, тем более к тем, которых вы даже не знаете.
Александр Володарский пишет: и когда пишется вот такой ответ Цитата Александр Новичков пишет: На самом деле есть еще, что было в исследовании под словом ''другое''. Для статьи это оказалось не столь важным :) это просто... человек так ничего и не понял... Вы под статьей свою подпись ставите...
Да, я ставлю свою подпись под этой статьей, и поверьте, мне нечего стыдиться. Вас я не знаю (как и многих других на форуме: ни кто вы, ни чем вы дышите, ни зачем пришли сюда и т.д.), а своих коллег и со-авторов я знаю, и у меня немало оснований уважать их и доверять им. В конце-концов, это люди, выполнившие более 20 успешных проектов внедрения технологий и инструментов, поддерживающих процессы разработки ПО, что подтверждено отзывами заказчиков и наличием хороших отношений с этими заказчиками, повысили квалификацию более 1000 специалистов и т.д. И если вдруг так случается, что кто-то из этих людей упускает что-то одно важное из виду из-за того, что сосредоточен на другом важном, для меня это не будет поводом осуществлять нападки и заниматься высмеиванием и тем более краснеть и стыдиться. И я сейчас могу объяснить, что произошло. Просто вы общались, находясь каждый в своей ''экспедиции'': один - на Северном полюсе, другой - в экваториальной Африке. И оба обсуждали погоду за окном. И удивлялись: как же так - вроде говорим об одном и том же (погоде), а описания получаются разные?! Это обычный с точки зрения человеческой психологии эффект: когда внимание человека сфокусировано на чем-то одном, он совершенно спокойно может пройти мимо и не обратить внимания на что-то другое. И дело будет даже не в том, что он этого не знает, а просто в том, что он сейчас об этом не думает! Если Вам когда-либо доводилось проводить предпроектное обследование в организации, возможно, Вы замечали, что приезжаешь к человеку в первый раз и слышишь от него, что в первую очередь нужно решить проблему №1. Потом приежаешь спустя 2 недели, и уже наиболее приоритетной становится проблема №2 и т.д. Конечно, иногда бывает и так, что он просто подумал в течение прошедших двух недель и понял, что в первый раз ошибся и дал неверную оценку. Но неоднократно оказывалось и другое: очень часто наиболее приоритетной со слов заказчика оказывалась та проблема, которую он решал непосредственно накануне встречи - просто она была в фокусе его внимания в последнее время и всё. ''Ошибка - от Бога'', ''не ошибается лишь тот, кто ничего не делает'' :) Мы были сосредоточены на поиске зависимостей между групповыми эффектами, другими интересными психологическими особенностями и тем, что происходит в процессе парного программирования. Так же нам показалось интересным, что, согласно результатам исследования, ''технари'' обычно чаще ошибались, считая себя ''чистыми технарями'', чем ''гуманитарии''. В итоге потерялись 20 % ''другого'' - а согласно методике исследования, это действительно было ''другое'': ''сомневающиеся гуманитарии и не технари'' и ''сомневающиеся технари и не гуманитарии''. Да, 20 % - немало, на погрешность не спишешь. НО: все-таки интуитивно-то понятно, что в эти 20 %, значит, попадает что-то другое, что ''забыли'' указать. Т.е. дело тут даже не в математической ошибке, у нас же не получилось 110 % в сумме или 140 %... - вот так-то уж точно не бывает! Могу и еще чуть-чуть побольше приоткрыть завесу над тем, как готовился этот материал: было 2 или 3 редакции, прежде чем появился окончательный вариант. Их вычитывали, вылизывали, выверяли, выравнивали стилистику и т.д. (Так что если даже и остались в публикации на e-xacutive какие-то орфографические и пунктуационные ошибки - не исключено, что это они не остались, а появились при копировании текста из MS Word сюда.) А результаты исследования на ''гуманитариев'' и ''технарей'' нашлись, когда уже статья была готова, уже в конце... Так что, боюсь, что просто после того объема работы, который был проделан, эта строчка с 20% просто ''потерялась''... :( А дальше материал наконец публикуется, и начинаются какие-то непонятные нападки в комментариях... Сразу и не сообразишь, откуда ноги растут. И где гарантия, что это ценные замечания, просто высказанные в неконструктивной форме, а не очередная попытка наглого самопиара за чужой счет - ведь критиковать-то всегда легче, чем делать самому? Нет такой гарантии. И разбираться в общем-то не особо охота, да и времени, как всегда, не хватает... Вот и получилось, что каждый уехал в свою экспедицию.
Knowledge manager, Украина
Галина Карабанова пишет:...ни Вы, ни кто-либо еще из участников дискуссии ни меня, ни других авторов не спросили даже о том, чего мы хотим дальше делать с этой статьей, а уже сделали вывод, что мы ничего не хотим....
Прошу прощения за отсталость ... А ЧТО вообще можно делать со статьей, кроме как опубликовать? ''...Статья, находящаяся перед вами, открывает цикл статей о человеческом факторе, Agile-практиках и других полезных приемах, используемых при управлении командами в IT. Объединяет рассматриваемые практики и приемы одно – они позволяют проявиться положительным эффектам, связанным с человеческим фактором. И мы объясняем, почему с точки зрения психологии, это происходит. Так сказать, подводим теоретическую и экспериментальную базу под то, что себя уже давно зарекомендовало и работает. Или под то, что работает не у всех, и потому является предметом оживленных споров и дискуссий. И начинаем мы наши исследования с рассмотрения эффекта парного программирования через призму экспериментов социальной психологии....'' На мой взгляд, именно такое начало статьи ВОПИЕТ как о целях, ради достижения которых пишется статья, так и о квалификации ее авторов. По своей сути, ''парное программирование'' ничем не отличается от ''парной кладки кирпича''. Действительно, с энтузиазмом или с ощущением усталости, но на 25 ряду кладки один каменщик продолжит кладку ряда, а другой кладет перемычку над оконным проемом. Это не имеет никакого отношения к психологии. Это ПРЕДПИСАНО чертежами. Попытка же авторов объяснить ''...почему с точки зрения психологии, это происходит...'' говорит о том, что авторы не видят разницы между коллективным написанием романа и коллективным производством чего-либо. В этом случае вам (мн.ч.) - на другую площадку (литературную, например). Вам уже было замечено, что малоинтересно обсуждать описание эффектов, происходящих с вымышленными сущностями (по крайней мере, на Е-хе). Ну нет уже давно программистов. Как нет уже давно строителей. Есть бетонщики, каменщики, отделочники, сантехники (если ограничится той областью, которая рассматривается в статье). Огромную роль в сотворении здания играют еще руководители проектов, архитекторы (не буду перечислять всех, это долго). Существуют еще дизайнеры, чья работа делает итоговый результат еще более привлекательным. Это в просторечии можно запросто оперировать термином ''строитель''. На профессиональном ресурсе это выглядит как дилетантство. Поделюсь с Вами еще одним ощущением, которое возникло в процессе проработки статьи и утвердилось в процессе обсуждения. Дело в том, что отдельно взятая социальная психология есть некая вещь в себе, интересная в познавательном плане, но к получению дохода не имеющая отношения. Необходимость и действенность ее проявляется на этапе социальной инженерии (я предпочитаю этот термин, как более конкретный, чем малопонятный тимбилдинг). Возможно, Ваше нежелание использовать именно этот термин и говорит о том, что Вы и нас пытаетесь ''строить''. Тогда реакция сообщества достаточно четко дает Вам ответ. Вам он не нравится, а у нас другого нет. И кажется мне, что задуманному циклу предстоит нелегкая судьба.
Генеральный директор, Бийск
Галина Карабанова пишет: Не ставила своей целью изложить в этом сообщении курс экономики и управления на предприятии
В общем, и не стоило.
Researcher, Москва
Галина Карабанова пишет: Валерий, если у Вас есть психологическое образование и Вы являетесть грамотным с точки зрения менеджмента руководителем - это отлично! Но в IT таких немного, и вот это, действительно, проблема.
Если Вы пытаетесь решить обозначенную проблему, то начали со столь малозначительного элемента как «парное программирование» или пусть, в расширительной трактовке, «формирование пар» для чего то. Начну с аллегории. Вожак волчьей стаи не становится вожаком одномоментно. Он проходит сложную последовательность испытаний, побед и поражений. В результате он либо становится ВОЖАКОМ, либо погибает (в прямом или переносном смысле). Точно так и происходит становление РУКОВОДИТЕЛЯ IT-компании. Подчеркиваю, РУКОВОДИТЕЛЯ, а не собственника. И как промежуточный вывод: таких как я МНОГО. Такие почти все у компаний с 5-10 летней историй на рынке. Если ВЫЖИЛИ, значит правильно ведут себя на рынке. Теперь вернемся к статье. Если она (статья) написана для таких как я – то это дилетантство и профанация. Если она написана для «подрастающего поколения» то она ВРЕДНА по своей постановке. Проблемы молодой IT-компании с «взрослеющим» Руководителем совсем не в «формировании пар». И даже не в «формировании Групп». Проблема в выстраивании отношений между Руководителем и исполнителями и между руководителем и Заказчиком. Я это преобразовал в формулу: (( «IT-шник» VS-1 «Руководитель» ) VS-2 «Заказчик» ) VS-3 «Рынок» Три «взаимоотношения» VS-1, VS-2, VS-3 – Это чистая психология «социальных групп». Приоритеты для руководителя имеют следующие отношения: VS-3 >> VS-2 >> VS-1 Недостаток Вашей статьи в том, что Вы начали с очень! частного случая отношений VS-1.
1 6 8
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Россияне стали меньше тревожиться из-за работы

Год назад уровень тревожности россиян по поводу различных возможных проблем на работе был выше.

Уровень счастья напрямую влияет на продуктивность большинства россиян

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

70% россиян отмечают сильное влияние работы на уровень стресса

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