Последнее изменение: 11 июня 2008г.

Экстремальное программирование – практика, психология и ошибки

Вы не любите кошек? Да вы просто не умеете их готовить!

Эту статью я писал, фактически, четыре раза. Начинал, доходил до середины, оставлял. Начинал заново. Писал о разных вещах, но каждый раз приходил к выводу, что всё это общее и к XP имеет ровно то же отношение, что и к другим методикам. Другими словами – не в этом суть.

Для того, чтобы понять, в чем действительно лежит ключ к успешной практике XP, мне потребовалось практически два с половиной года. За это время я сменил три методологии разработки, успел побыть лидером и даже руководителем довольно высокого уровня. Весь этот опыт оказался решающим и поистине бесценным. Сейчас я понимаю, что без него статья бы не получилась. Собственно, она и не получалась.

Содержание статьи вы найдете ниже. Хочу обратить внимание на то, что оно предназначено скорее для ориентации при повторном чтении. В первый раз статью крайне желательно читать последовательно, от начала и до конца.

Итак, содержание:

• Вступление
• Команда
• Лидер
  • Профессиональный лидер
  • Харизматический лидер
  • Формальный лидер
  • Неформальный лидер
• Создание эффективной команды
  • Формирование команды
  • Роль лидера в эффективной команде
  • Мотивация
  • Ошибки мотивации
• Организация эффективной работы
  • Иерархия команд
• Командная работа – коротко
• Командная работа и практика eXtreme Programming
  • Планирование
  • Тестирование
  • Парное программирование
  • Рефакторинги
  • Коллективное владение кодом
  • Стандарты кодирования
• Подводим итоги

Что ж, приступим.

Вступление

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

Ответ на заданные вопросы заключается в одном единственном слове. И слово это – команда.

Команда

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

Все три пункта необычайно важны. Пройдемся по каждому из них.

Первое. Общие цели. Необходимость достижения общих целей, фактически, является причиной создания команды. Как я уже говорил в статье "О профессионализме и не только" (http://www.skipy.ru/philosophy/professionalism.html), команду создают тогда, когда знаний и/или умений одного человека недостаточно для решения задачи.

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

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

Третье. Совместные действия.. "Совместные" означает скоординированные. Представьте, что вы в составе некоторой группы товарищей выталкиваете машину из ямы. Цель понятна, приоритеты расставлены – сначала выталкиваем, потом все остальное. Однако, если выталкивать будете вразнобой – ничего хорошего не выйдет. Если будете действовать согласованно – вытолкаете с первой попытки.

Для иллюстрации прямо-таки просится пример из совсем недавно произошедших.

Теперь пройдемся по историям, приведенным в самом начале.

История первая – Франция против Бразилии. Что представляли из себя бразильцы? Набор звезд. У каждого – выдающееся мастерство. Но именно это их и сгубило – они не были командой. Они выигрывали за счет индивидуального мастерства.

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

История вторая – сборная России на Олимпиаде. На чем погорели наши? А ровно на том же, на чем и бразильцы четыре месяца спустя. Индивидуальное мастерство – да, оно было. Но времени на то, чтобы стать командой – увы. Некоторые, если мне не изменяет память, прилетали в Турин в течение Олимпиады, по мере того, как их клубы выбывали из Кубка Стенли. То есть у них вообще не было времени на то, чтобы сыграться с партнерами. В результате – непонимание на площадке, передачи в никуда, несогласованность в защите. В групповом турнире сработало индивидуальное мастерство, во встрече с канадцами в четвертьфинале – то, что канадцы играют ровно так же. За счет индивидуального мастерства. А вот в полуфинале и в матче за третье место наши попали на слаженные команды. Результат известен.

Т.е. – почему ничего не получилось? Да потому, что действий сообща не было. Командная цель была. Приоритеты были. Команды не было.

Наконец, история третья – подъем тяжестей. Сначала о согласованности. Согласованные действия могут дать гораздо больший результат, чем простая сумма усилий. Я сам в армии не был, но говорят, что есть там такая команда – "сбить шаг". Что означает следующее – вместо шага "в ногу" надо идти кому как придется, вразброд. Необычно для армии, правда? Есть, однако, в этом приказе суровая правда жизни. Он подается, например, когда колонна входит на мост. И делается это для того, чтобы под действием синхронных шагов мост не вошел в резонанс и не рухнул. Судя по всему, прецеденты были.

Да что армия? Я хорошо помню, как десять мальчишек в возрасте от восьми до четырнадцати лет раскачали автобус так, что у него задние колеса стали отрываться от земли. Он подпрыгивал. А сделали всего ничего – синхронно приседали и выпрямлялись. Десять человек. Сам участвовал.

Вернемся к истории. Очень интересно наблюдать этот процесс – подъем человека – со стороны. Цель поставили, разъяснили. Приоритеты расставили. Добились того, чтобы действия были согласованы. Ан нет, не идет. Даже оторвать от стула не могут. Почему?

НЕ ВЕ-РЯТ.

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

Так что же в действительности должна представлять собой команда, если говорить простым языком? На чем она держится? На мой взгляд – вот на чем:

В основе существования команды лежат четыре принципа – доверие, равенство, уважение и поддержка.

При отсутствии хотя бы одного из них совместная работа будет проблематичной. Начнутся конфликты, проверки, соревнования, в результате чего на первый план станут выходить личные цели – самоутвердиться, получить признание и т.п. О командных целях можно забыть. Классический пример – потеряный Хемильтоном и McLaren-ом титул.

Основное, что делает команду – командой, и о чем многие забывают – команда это единое целое. Разве можно сказать, что матч выиграл игрок, забивший единственный мяч? Или матч проиграл вратарь, это мяч пропустивший? Нет, нет и еще раз нет! Матч выиграла или проиграла команда. Как единое целое. Если же у нас как у Райкина – "А я вообще пуговицами занимался! К пуговицам претензии есть?" – то это означает, что команды нет. Это – каждый сам за себя. Личные цели – выше командных.

Быть же единым целым невозможно без тех четырех принципов, которые я только что назвал: доверие, равенство, уважение и поддержка. Повторяю их еще раз, ибо это ключевые ценности при построении команды. Необходимые для ее формирования, но не достаточные для ее эффективной деятельности. Что нужно еще? Узнаете.

* * *

Представьте себе команду. Их трое. Они мотивированы. У них есть четкая цель. Они умеют действовать совместно. Синхронно. Они взялись за поставленную им задачу и... решили ее?

Представляю вам описаную выше команду. Она классическая, известная уже более 100 лет. Лебедь, Рак и Щука. Результат работы этой команды давно стал поговоркой: "А воз и ныне там".

Вопрос. Чего им не хватило?

Жалко, конечно, что я не могу задать вопрос, а потом послушать ваши ответы. Приходится отвечать самому. Не хватило Лебедю, Раку и Щуке кого-то, кто будет их энергию направлять. Кто построит их работу таким образом, чтобы они не нейтрализовывали действия друг друга, а наоборот – усиливали. И называется этот кто-то – лидер.

Лидер

Для начала, как и в случае с командой, нужно определиться, кто такой лидер. Это понятие тоже используют все, кто ни попадя, и его смысл порой искажается чуть ли не до противоположного.

Глагол "lead" в английском имеет множество значений. От "вести", "возглавлять", "идти первым" до "командовать". Чувствуете разницу? В русском это семантически совершенно разные понятия.

Итак, определение.

Что следует из этого определения.

Первое – полноправный член команды. Что означает, что лидер находится с остальными в тех же отношениях, что и они сами между собой. Иначе говоря... доверие, равенство, уважение и поддержка. К лидеру всё это применимо. Лидер доверяет членам команды. Лидер находится с ними на равных. Лидер уважает членов команды. Лидер поддерживает членов команды.

Всё это идет вразрез с исторически сложившимся у нас административно-командным стилем управления. Когда не приходится говорить об уважении и поддержке, и тем более не идет речи о доверии и общении на равных. И потому в административно-командном стиле управления не лидеры, а начальники. Опять-таки – чувствуете семантическую разницу между "лидер" и "начальник"? Думаю, что очень хорошо. Мы будем говорить именно о лидере.

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

И третья составляющая определения – принимающий решения. Вопрос. Какие именно решения?

Ответ такой. Лидер принимает те решения, которые, по его мнению, способны привести команду к выполнению поставленной перед ней задачи. Это не значит, что он принимает ВСЕ решения. Нет, только ключевые. И то не все, впрочем, об этом мы поговорим позже.

Второй вопрос – почему решения принимает именно он?

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

Вспоминая рекламу – "не все йогурты одинаково полезны" – хочется задать вопрос. Все ли лидеры одинаковы? Ни в коем случае. Каждый человек по определению уникален. Тем не менее, лидеров можно условно разделить на две группы. Я бы назвал их так – профессиональные лидеры и харизматические лидеры. Мы рассмотрим каждую группу отдельно.

Профессиональный лидер

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

Нужно сказать, что профессиональные лидеры встречаются очень часто. Поскольку команды с равномерным опытом всех членов – явление уникальное, профессиональным лидером обычно становится кто-то из самых опытных, чьё право принимать решения не вызывает сомнений.

Второй тип лидеров –

Харизматический лидер

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

Дело всё в том, что задача лидера – обеспечивать организацию команды так, чтобы она работала максимально эффективно. А для этого совсем необязательно все решения принимать самостоятельно. Можно делегировать принятие решений профессионалу. Вместе с ответственностью за них.

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

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

Почему я называю этих лидеров харизматическими? С профессиональными всё ясно – за ними идут потому, что признают их как профессионалов. А тут... Мне кажется, что в этом случае внутри человека есть какая-то точка, из которой он способен повести людей за собой. Просто так, потому что он этого хочет. Потому что он уверен, что это правильно. И этой уверенностью он заражает команду. Всё это близко к моему пониманию харизмы человека.

* * *

Итак, с типами лидеров мы вроде как определились. Но это далеко не всё. До сей поры мы говорили исключительно о сферической команде в вакууме, построенной по учебнику. В реальных командах всё далеко не так просто. Есть различие, связанное со статусом лидера в команде. А именно – он может быть явным – формальным, – и неявным – неформальным. Знакомо слово "неформал"? Во времена СССР это было клеймо, их боялись, ими пугали. Почему? Сейчас разберемся. Начнем вот с этого –

Формальный лидер

Формальный лидер – это тот, кто является признаным лидером по мнению руководства уровнем выше. Тот, кого руководство считает лидером. Это лидер, что называется, "де юре". Что это означает? А вот что. Именно этому человеку ставится задача, именно он несет ответственность за ее выполнение.

Специально выделяю – ответственность за решение задачи лежит на формальном лидере. Это ключевой момент для понимания ситуации.

Неформальный лидер

Кто же такой неформальный лидер? Это лидер "де факто". Что совсем не означает, что он же – лидер "де юре". Это тот человек, кто реально может вести команду. Куда?

КУ-ДА ЗА-ХО-ЧЕТ.

Теперь понимаете всю пикантность момента? Задачу ставят формальному лидеру. Ответственность несет он же. А ведет команду кто-то другой – неформальный лидер. И приведет ли он ее к решению задачи – совсем не факт. При этом он сам за результат не отвечает.

Теперь становится понятным горячая "любовь" к неформальным лидерам. Особенно во времена СССР, с принятым тогда командно-административным принципом управления, когда формальный руководитель практически никогда не обладал лидерскими качествами. Да и сейчас-то ситуация не сильно лучше.

Наличие в команде двух лидеров – формального и неформального – это очень частое явление. Что делать формальному лидеру в такой ситуации – мы рассмотрим дальше.

* * *

Необходимо сказать еще пару важных слов о лидере. Несмотря на то, что все члены команды равны, лидер... как бы это сказать... "равнее" остальных. Он выделен. И именно благодаря своей роли он ведет за собой команду.

Однако у этой роли есть еще одна черта. Лидер является носителем ценностей команды. Транслятором ценностей команде. Проще говоря, команда идет за лидером во всем – в том числе и в плане ценностей. Лидер является образцом для подражания.

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

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

* * *

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

Создание эффективной команды

Тот, кто пробовал и считает, что это просто – пусть бросит в меня камень.

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

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

Формирование команды

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

Итак, доверие. Открою секрет: что бы ни говорили люди – изначально они друг другу не доверяют. Всем доверяют только дети, и то недолго. А дальше – начинают обжигаться и, соответственно, закрываться от окружающих.

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

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

Зачем это нужно. В игровой обстановке члены команды невольно будут действовать сообща. У них будет общая цель и скорее всего личных целей в игре не проявится. Конечно, бывает всякое, но игра в футбол – гораздо менее критично, нежели карьера (я не имею в виду футболиста :)). Меньше амбиций, меньше потребность проявить свою уникальность, неповторимость и т.д. А в случае победы останется ощущение, что добился ты этого вместе с командой. Останется чувство единения. И очень повысится доверие. Ощущение, что ты победил вместе с этими людьми, что они тебя не подвели – оно подсознательное и не зависит от того, чем вы занимаетесь – играете ли в футбол или разрабатываете софт.

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

Пойдем дальше. Равенство. При формировании команды с нуля с этим попроще – тут все равны по определению. Главное – не проводить никаких явных сравнений. И уж тем более не говорить, что кто-то хуже остальных.

Стоит ли кого-то выделять – вопрос очень тонкий. С одной стороны, это будет оценкой работы человека и будет его мотивировать. С другой – это порождает неравенство. Кого-то одного поставили выше остальных. На мой взгляд, гораздо эффективнее кого-то отметить так, чтобы не поднимать его над остальными. Например, сказать, что он очень хорошо справился с такой-то задачей, добился того-то и того-то. Не говорить, что он лучше или самый лучший. Все члены команды равны и все – лучшие. И каждого можно за что-то отметить. Это будет стимулировать всех, не порождая неравенства. Если же получается так, что кого-то отметить не за что, то первый вопрос, который нужно задать – что я как лидер сделал для того, чтобы этот человек чувствовал себя – и был! – успешным?

Бывают ситуации, когда с неравенством все-таки приходится иметь дело. Например, когда приходится работать с уже устоявшейся группой, в которой сложились определенные отношения. Здесь важно не уравнивать – это никогда не работало, – а вытягивать всех на максимальный уровень.

Ситуаций тут – великое множество. Первая – когда человек считает, что он ниже других. Если это обоснованно – например, в связи с его профессиональными качествами, – то ему нужна элементарная поддержка в том, чтобы повысить свой уровень. Вариант, когда человек пребывает в состоянии жертвы и получает удовольствие от того, как ему плохо, я не рассматриваю. Это не ко мне, это к профессиональным психологам. Если человек считает себя ниже других необоснованно – ему надо просто показать реальную ситуацию. Возможно, хорошо в этом поможет обратная связь от других членов команды (на всякий случай ее стоит выяснить заранее, чтобы не было неприятных моментов).

Человек может считать себя выше других. Опять-таки, объективно или нет. Если объективно – он действительно по профессиональным качествам превосходит остальных, – то тут напрашивается вопрос: а что ты можешь (хочешь?) сделать для того, чтобы помочь остальным повысить свой уровень? Если ничего – смотрите на личные цели. Как правило, это желание не иметь конкурентов. Почему? Чаще всего – страх, что его обойдут, что он станет никому не нужным. Что его не ценят. Если человека ценят – конкуренты ему не страшны. Дать понять – почувствовать! – что его ценят – это в наших силах.

Если человек считает себя выше, не имея на то никаких оснований – это другой разговор. Необходимо выяснять, на чем он основывается. Показывать, что другие члены команды ничуть не ниже него. Это сложная работа психолога, она выходит за рамки этой статьи.

Еще несколько вариантов – уже команда может считать, что кто-то стоит выше остальных или ниже. Опять-таки, обоснованно или нет. Если выше – вспоминаем о неформальном лидере, если ниже – разбираемся с причинами, подтягиваем и т.д.

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

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

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

И последний столп – поддержка. Кажется, что поддержать человека – это просто. Практика психологических тренингов, о которых я упоминал, показывает, что это далеко не так. Для многих поддержать в чем-то лидера – или товарища по команде – оказывается очень сложным делом. Вот тут махровым цветом расцветают личные цели. Лидер сразу делает все не так, – "не так свистишь, не так летаешь" :) – "у меня это получится лучше" и т.д. и т.п. Вплоть до "иди нафиг отсюда, какой ты лидер?!" Какие тут собственные цели? Да самые разные: проявить себя, самому лидировать, продемонстрировать своё умение и получить признание, ... Масса всего.

Поддержать человека, искренне, на 100%, поставив свои цели ниже его – этому тоже надо учиться. Сделать это можно только самому, никто не поможет. Основное – если не хочется кого-то поддерживать – или хочется, но по факту не получается – стоит задуматься: почему? В чем мне будет плохо, если я его поддержу? Что я при этом потеряю? При должной практике ответ найти можно достаточно быстро. Ну а дальше – действовать по обстоятельствам, в зависимости от найденных ответов. Полезно еще задаться вопросом – чего я смогу достичь с командой, если я сейчас поддержу лидера? И не перевесят ли эти достижения мои потери?

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

* * *

Хочется еще особо отметить следующий момент: существуют люди, неспособные работать в команде. Это те, кто не принимают для себя упомянутые четыре основных принципа как ценности. Не могу быть с другими на равных, никому не доверяют, не уважают других, не умеют и не хотят поддерживать. Проще говоря, какие-то из основных принципов входят в противоречие с личными целями. Которые стоят на первом месте. В команде от такого человека не будет толку, каким бы он специалистом ни был. А вот развалить команду для него пара пустяков.

Можно, конечно, попробовать переориентировать поведение, но... Ценности подобного плана закладываются в глубоком детстве. И их изменение под силу исключительно профессиональным психологам. Я лично не возьмусь. Можно потратить много времени и не получить результата. А времени у лидера и так всегда не хватает.

* * *

Идем дальше. Я уже говорил немного о роли лидера в процессе формирования команды. Теперь поговорим о роли лидера вообще.

Роль лидера в эффективной команде

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

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

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

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

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

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

Третья роль лидера – поддерживать мотивацию членов команды. И этому стоит посвятить отдельный раздел.

Мотивация

Пожалуй, самое непростое из всего, что приходится делать лидеру. Мотивация – это вообще чуть не самый сложный аспект построения работы. Сугубо индивидуальный. По этому поводу написано колоссальное количество книг, создано множество теорий. И учить вас чему-то в этой области мне представляется в высшей степени бессмысленным. Во-первых, потому что я сам только учусь. Во-вторых, потому что есть люди (книги), которые научат этому значительно лучше меня. Потому я приведу лишь некоторые общие соображения.

Прежде всего – а что движет людьми? Что их мотивирует на работу? Что их демотивирует? Практика – да и теория – показывает, что это сильно зависит от человека. В том числе – и от уровня профессионализма. Ниже приведена таблица, отражающая приблизительную структуру мотивации в зависимости от уровня – начинающий разработчик, опытный разработчик и профессионал. Разумеется, это не истина в последней инстанции, но рациональное зерно в этом есть. Таблица эта – фактически, применение пирамиды Маслоу к разработке ПО.

Тем, кто не знаком с концепцией потребностей Маслоу, рекомендую почитать вот это отступление – Немного об иерархии потребностей Маслоу (http://www.skipy.ru/philosophy/maslow.html). Оно слишком объемно, чтобы включать его в эту статью, однако я считаю эту информацию достаточно важной для понимания многих аспектов мотивации.

Потребности	Профессионализм
	Начинающий	Опытный	Профессионал
Материальные	50%	20%
Безопасность1		20%
Принадлежность	40%	20%	10%
Самоутверждение	10%	30%	40%
Самоактуализация		10%	50%

Крестик в таблице означает, что в этой области мотивация будет работать крайне слабо, или не будет работать вообще.

Почему так. Мотивацией является возможность удовлетворения потребности. Даже не так – мотивацией служит чувство удовлетворения от реализации потребности. Соответственно, структура мотивации – это, фактически, структура потребностей человека. И в этом случае таблица становится гораздо более понятной:

• Для начинающего разработчика самое большое значение имеет материальная составляющая, далее идет возможность учиться, и только потом, с сильно меньшим приоритетом – самоутверждение (признание, самоуважение).
• У опытного разработчика акценты смещаются дальше – с упором на самоутверждение. И это тоже понятно – опытный разработчик уже вряд ли окажется в ситуации, когда главное для него – обеспечение материальных потребностей. Они у него, безусловно, есть и из основания пирамиды никуда не делись. Просто ему уже не нужно уделять этому столько внимания, он получает то, что ему надо, достаточно легко. Просто по своему статусу "опытного" разработчик имеет и хорошую компенсацию, и соцпакет и много чего еще.
• Ну а профессионал – его, можно сказать, деньги слабо интересуют. Их наличие для него – норма, и не являются главенствующим фактором. На первый же план выходит возможность самореализации.

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

* * *

Итак, мотивация. Что нужно сделать, чтобы человек был мотивирован на работу?

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

Идея проста. Но ее реализация... Как это было в "Анжелике"? "Все знают семь нот, но только господин Люли умеет писать оперы".

Искусство мотивации состоит в умении реализовать эту идею. Научиться этому можно только на практике, точно так же, как на словах не расскажешь, как ездить на велосипеде.

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

Возьмем такой мотиватор как обучение. Дать сотруднику возможность учиться. Это влияет на второй уровень – повышает профессиональную безопасность, третий уровень – повышается вероятность получения признания ввиду повышения уровня профессионалима, четвертый уровень – удовлетворяется потребность развиваться.

Казалось бы, все замечательно, такой хороший мотиватор? Ниже, в разделе "ошибки мотивации" приведен пример (третий) того, что произойдет, если этот мотиватор использовать неправильно.

Касательно использования уровней мотивации есть у меня такие соображения. Не могу гарантировать правильность данного вывода, но есть у меня ощущение, что интенсивная мотивация на уровне N блокирует мотивацию на уровнях N+1 и выше. Я бы вообще принцип пирамиды Маслоу сформулировал так – пока человек сконцентрирован на определенном уровне, он не пойдет выше. А интенсивная мотивация на определенном уровне заставляет концентрироваться именно на нем. Можно дать человеку ОЧЕНЬ много денег, и это даже сработает. Зато начисто убьет мотивацию более высоких уровней, действовать будет недолго, и даст совсем не тот результат, который ожидали. Пример – ниже (второй).

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

* * *

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

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

Как правило, от персональной ответственности отказываются редко – это все-таки потребность. Гораздо чаще проблемы с ответственностью возникают в командной работе, впрочем, об этом мы еще поговорим, когда будем обсуждать практики XP.

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

Для начала необходимо отказаться от "должен". Это слово можно заменить на "можешь". "Я уверен, ты это можешь сделать. Можешь?" Чаще всего ответ – да, могу. "Хорошо. Сделай, пожалуйста!" И практика показывает, что делают, причем с гораздо большей охотой, нежели при формулировке "должен".

Второй шаг. "Могу" заменяется на "хочу". Для этого необходимо найти мотиватор, который вызовет желание сделать то, что от человека нужно. Как обычно, это удовлетворение потребности, завязаное на выполнение задания.

И третий шаг – "хочу" заменяется на "люблю". Это происходит, когда уже есть положительный опыт удовлетворения потребности. А если человек что-то любит делать – он будет это делать.

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

Отступление закончено, к делу. Несмотря на то, что ответственность в четыре основных принципа не входит, это качество является очень важным для работы в команде. И ключевым – для работы по методологии XP. Об этом мы тоже поговорим ниже, в разделе "Командная работа и практика eXtreme Programming".

* * *

Вернемся, однако, к мотивации. Вопрос на засыпку. А кто отвечает за мотивацию? Собственно, я уже говорил об этом – лидер. И теперь понятно, почему. Только он знает командные цели и пути их достижения, ибо он сам их определяет. И только он может связать их с личными потребностями. Именно потому я упоминал, что лидер должен быть хорошим психологом – выяснение структуры потребностей членов команды находится в его ответственности.

Хочу сделать акцент еще на одном немаловажном моменте. Мотивация зависит от уровня разработчика, это я уже говорил. Однако в разных областях деятельности уровень может быть сильно разным! И это тоже надо учитывать.

Простой пример. Я в Java-разработке являюсь профессионалом. И мотивировать меня на уровне ниже четвертого просто бессмысленно. Однако что касается управления – а в этой области я и года не работаю – то тут принципиально иная картина. Можно во всю мощь задействовать третий уровень – потребность учиться у более опытных коллег, получение признания, – и даже второй – для меня сейчас играют очень важную роль возможность повысить квалификацию и востребованность моих знаний в области управления на рынке труда.

Так что при выяснении структуры потребностей вопрос надо ставить не просто "чего ты хочешь?", а "чего ты хочешь в таком-то качестве?"

* * *

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

Я уже упоминал о том, что мотивировать нужно грамотно. В следующей части будут отрицательные примеры с разбором полетов.

Ошибки мотивации

Приведу несколько примеров того, как действия, направленные на мотивацию, вызывают обратный эффект. Несколько из этих примеров взяты из моей практики, о других я слышал. Часть из них связана с внедрением XP.

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

Т.е. ошибка была в том, что уровень для мотивации был выбран неправильно.

Печальный итог. Материальная стимуляция – привязка премии к объему работ – обеспечила увеличение производительности, чего и добивались авторы сего новшества. Однако она же убила качество работы, ибо оно находится на 4-м уровне пирамиды. А материальное – на первом. Это классический пример того, как интенсивная мотивация на нижнем уровне убивает мотивацию на более высоких уровнях.

Что не так в этом случае? Это выяснилось потом. Как оказалось, не было проведено исследование – кому из сотрудников необходимо обучение, у кого оно есть в потребностях. И второе – основное – не было проведено исследование того, какие именно знания необходимы сотрудникам для работы в компании.

Что получилось в итоге. Знания получены, но применить их негде. Т.е. для сотрудников, прошедших обучение, после него ничего не изменилось. Зато появилась неудовлетворенность – признания они не получили, самостоятельности и ответственности больше не стало. Вместо удовлетворения потребностей четвертого уровня пирамиды обучение вызвало их обострение. Обратный эффект.

Что здесь не так? Прежде всего – ты должен. От любого давления хочется избавиться. А когда оно еще сопровождается карательными мерами – от этого зависит твоя премия – избавиться хочется вдвойне.

Далее. Центр обучения по факту не имеет представления о том, какие знания востребованы. Чему-то, связаному с бизнесом компании, они научить могут. Но и только. Если же есть возможность выбрать между обучением внутренним, в собственном центре, и обучением внешним, в другой компании, – практика показывает, что выбирают обучение внешнее. Что закономерно.

В принципе, мотивация тут сработала на все 100%. Правда, она была направлена не на то, чтобы что-то сделать, а наоборот – чтобы чего-то не делать. Написание тестов – очень трудоемкая и нелюбимая работа. Сложнее, чем написать функциональность. И потому нужно это стимулировать. А когда идет обратная мотивация – очевидно, что делать этого никто не будет.

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

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

* * *

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

Организация эффективной работы

Вот, наконец, мы добрались и до реальной работы.

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

Прежде всего – взять на себя ответственность за результат. Лидеру необходимо понимать, что решения принимает он и за результат отвечает тоже он. Если лидер не возьмет на себя ответственность – задача не будет решена практически наверняка.

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

Рассмотрим такой вариант. Приходит лидер и говорит команде – работаем! Получится так что-нибудь? Я лично сомневаюсь. Единственное, в чем я уверен, так это во встречном вопросе – а что делаем-то?

Действительно, лидер как-то забыл рассказать команде, что надо делать.

Хорошо, рассмотрим следующую ситуацию. Лидер приводит команду к стоящей в яме машине и говорит – толкаем! Получится из этого что-нибудь? Не уверен. Я, например, в такой ситуации решу, что машину надо вытолкать из ямы. И буду ждать, пока заведется двигатель. А если окажется, что машина заглохла и ее надо сначала вытолкать из ямы, а потом разогнать и завести "с хода" – ждать я могу бесконечно.

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

Таким образом, следующее, что должен сделать лидер – позаботиться о своей команде: объяснить, что команда должна сделать, для чего и как именно. Важны все три пункта. Если не объяснить – не сделают ничего. Если не объяснить, для чего это – скажут, что это вообще не надо делать. Если не объяснить, как именно делать – будут рыть яму ломами.

Ну хорошо, лидер объяснил, что как и зачем. Этого достаточно?

Нет. Не достаточно. Представьте, что команда не согласна с лидером. Что будет с работой? Ничего хорошего. Что делать?

Нужно заручиться поддержкой команды. Попросить о ней. Причем попросить явно – только так можно получить обратную связь.

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

Иногда бывают перекосы в другую сторону. Неуверенность, неумение просить – всё это прикрывается агрессией. Получается как на вот этом кадре – так, построились все, поддержали, пошли работать! Ну, на словах, конечно, поддержат, ибо страшно. А на деле – начнется саботаж, увиливания от работы и т.п.

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

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

И этому тоже можно научиться только на практике. Сложно. Но это, пожалуй, единственное, что работает.

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

О поддержке нужно попросить каждого члена команды. Причем лучше поименно. Почему так? Если команда действительно основывается на доверии – каждый может высказать, что он думает по этому поводу. Если не поддерживает – можно выяснить, почему. И придти к тому варианту, который устраивал бы всех.

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

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

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

Еще один немаловажный момент работы с командой. Лидер не должен проводить границу между собой и остальными членами команды. Никаких "я" и "вы" – только "мы". Мы это сделаем, мы это сможем. Это действует гораздо лучше, чем "я уверен, что вы это сможете". Для того, чтобы команде передалась уверенность и энергия лидера, он должен быть внутри команды. Собственно, это по любому должно быть именно так, я лишь хочу обратить внимание, что разделение на "я" и "вы", которое очень часто проявляется неосознанно, способно подпортить результат.

Итак, задачи разъяснены, цели поставлены. Поддержка команды получена, команда воодушевлена и готова действовать. Что дальше?

Работать. Принимать решения. Реализовывать их. Заниматься мотивацией, непрерывно. И как один из аспектов мотивации – давать обратную связь. Я очень часто встречаюсь с ситуациями, когда подход такой – если не поругали, то все в порядке. Это в корне неправильно. Получается, что людей только ругают. Это ОЧЕНЬ демотивирует.

Членов своей команды необходимо благодарить! Они этого заслуживают. Если нет – вопрос к лидеру: что он сделал для того, чтобы членов его команды было за что благодарить?

Сказать "спасибо" – много усилий не надо. Тем более когда есть за что. Зато члены команды будут чувствовать, что их работу ценят. И их самих ценят. Четвертый уровень пирамиды. Очень мотивирует.

* * *

Эффективность работы команды зависит еще от одного момента. Сейчас мы его обсудим.

Иерархия команд

Прежде всего, хочу сказать, что размер эффективной команды ограничен. В принципе это не новость. При росте количества членов команды общая производительность растет линейно², а число каналов коммуникации, как это следует из комбинаторики – квадратично. В конечном итоге наступает момент, когда добавление нового члена команды увеличивает накладные расходы на обмен информацией настолько, что общая производительность команды не растет, а падает. В XP, например, принят размер команды 6-8 человек.

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

Решение состоит в выстраивании иерархии управления. Т.е., скажем, руководитель группы находится в подчинении у руководителя отдела, тот, в свою очередь, у руководителя управления, тот – у директора по производству, директор по производству – у управляющего директора. Что это означает с точки зрения командной работы?

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

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

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

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

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

Говоря проще – есть довольно известное изречение, авторства, увы, не знаю: вассал моего вассала – не мой вассал. Именно так должно быть построено управление в иерархии. Мы ставим задачи членам своей команды и спрашиваем только с них. Нас не волнуют – и не должны волновать! – люди, которые реально будут эту задачу реализовывать. Это ответственность того, кому мы ставим задачу – лидера команды уровнем ниже – подобрать людей, определить пути движения и поставить цели. И точно так же его не должно волновать, как будет делаться работа на следующем уровне вниз. Ответственность всегда несет тот – и только тот! – кому задача была поставлена.

Несоблюдение этих правил чаще всего приводит к анархии. И уж точно не способствует продуктивной работе.

Пожалуй, это всё, что я хотел сказать об организации эффективной командной работы. Идем дальше.

Командная работа – коротко

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

Поехали!

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

Все эти потребности (кроме ответственности) находятся на третьем уровне пирамиды Маслоу (http://www.skipy.ru/philosophy/maslow.html), таким образом, в основе успешной команды лежат удовлетворенные потребности третьего уровня пирамиды Маслоу. Мотивация же должна быть направлена на четвертый уровень, на котором находится ответственность.

Ответственностью лидера является:

• Принятие решений – в том числе и по делегированию полномочий на принятие решений
• Построение отношений в команде, культивирование ценностей команды
• Мотивация команды
• Организация эффективной работы

И последнее:

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

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

* * *

Ну, вот мы и добрались до того, ради чего, собственно, и затевалась эта статья.

Командная работа и практика eXtreme Programming

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

Перед прочтением этой части я крайне рекомендую перечитать первую статью об экстремальном программировании, посвященную непосредственно методологии: Экстремальное программирование – реальность и мифы (http://www.skipy.ru/philosophy/xp.html). Это необходимо для того, чтобы освежить в памяти практики, которые мы сейчас будем рассматривать в разрезе обсуждаемой темы, а именно – командной работы.

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

Планирование

Казалось бы – где Рим, а где Крым. Какое отношение имеет команда к планированию?

Ну, команда, может, и никакого, а вот ее ценности – четыре принципа плюс ответственность – имеют. Вспомним, что во время планирования оценка задач производится самими разработчиками. Так вот, ответственность разработчиков – называть реальное время, не завышая его. А лидер при этом должен доверять этим оценкам.

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

Следующая практика –

Тестирование

Я уже говорил, что тестирование – процедура нелюбимая. А тем более написание тестов, да еще перед самим кодом. И это понятно – при тестировании желательно предусмотреть максимальное количество вариантов использования функциональности. Что непросто.

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

Таким образом, со стороны лидера необходима мотивация, а со стороны разработчиков – ответственность. Нет мотивации и ответственности – практика не работает.

Идем дальше.

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

Тут мне вспоминается пример внедрения XP в одной из компаний. Я в этом не участвовал, только слышал. В общем, парное программирование трансформировалось в то, что (цитата) "разработчики сидели парами и вместо работы травили анекдоты". Что означает такая ситуация? А означает она следующее.

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

Второе: отсутствует ответственность. Даже комментировать не надо.

Третье: личные цели стоят выше командных. Потрепаться и весело провести время на работе – это цель личная. И по результату стоит она на первом месте.

Четвертое: отсутствуют совместные действия, направленные на решения командных задач. Что очевидно, ибо командные задачи не являются приоритетными.

Думаю, этого уже хватит. Таким образом, имеем резюме: команда отсутствует как явление. А внедрение XP без команды провально. Так что меня лично результат не удивляет нисколько. Хуже то, что по результату этого "внедрения" руководители компании, – да и многие разработчики, – сделали выводы о самой методологии: XP – это зло.

Так что же необходимо для успешной реализации практики парного программирования? Всё вместе. Нужна команда и все ее ценности:

• Доверие – в принципе необходимо для того, чтобы работать в паре. Нет доверия – неизбежно будет ощущение, что напарник хочет на тебя скинуть побольше, а самому сделать поменьше.
• Равенство – туда же. Это уже в обратную сторону. Нет равенства – либо будешь скидывать побольше на других, либо брать на себя, в зависимости от вектора. Кроме того, суть парного программирования состоит в генерации идей одновременно двумя людьми. При неравенстве это теряет всякий смысл – понятно, какие идеи будут реализованы.
• Уважение – ключевой момент для работы в условиях, когда постоянно приходится обсуждать чужие идеи. Кроме того, если что-то пошло не так, взаимное уважение помогает исключить варианты "это ты виноват". Впрочем, если в команде все хорошо, то будет "это мы виноваты". Однако этого "все хорошо" еще надо достичь, для чего и нужно уважение.
• Поддержка – важный момент, когда что-то не получается. Поддержать напарника – очень ценно. Сильно улучшает доверие.
• Ответственность – важно всегда. В том числе и в парной работе. Очень подмывает, если что не так, свалить вину на напарника. А ответственность на самом-то деле несут оба.

Что там следующее?

Рефакторинги

Первое, что нужно для внедрения этой практики – доверие. Нет, даже не так: ДОВЕРИЕ! Как я уже рассказывал в статье о самой методологии, у меня в жизни был случай, когда после произнесения слова "рефакторинг" мне предложили уволиться. Руководство просто не поняло, что я собираюсь делать два месяца, при том, что никакой новой функциональности не будет создано.

На самом деле это больше про доверие заказчика к самой практике. Но и для успешной ее реализации доверие необходимо. Действительно, новой функциональности при рефакторинге не появляется. И то, что он сделан, можно определить только путем детального анализа "до" и "после", что может быть весьма накладно. Соответственно, в такой ситуации можно только доверять разработчикам в том, что рефакторинг действительно сделан. А от самих разработчиков тут ожидается ответственность.

Кроме того, сделать рефакторинг – это означает пустить несколько человек в работающий код и дать им его перелопатить. Где гарантия, что они ничего не напортят? Страшно. Тут тоже нужно доверие. И полное покрытие unit-тестами. :)

Опять-таки, необходимо уважение. К чужим идеям, например. Очень часто разработчик смотрит в чужой код и говорит – господи, ну и кошмар! Тут всё надо переписать! Причем говорит это до того, как начнет разберется. А разбираться на самом деле просто лениво.

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

Ну и, естественно, важна ответственность. Сделать, причем качественно, а не спустя рукава.

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

Коллективное владение кодом

О, тут есть о чем поговорить. Если практика рефакторингов вызывает больше всего возражений у заказчиков ПО, то коллективное владение кодом – у самих разработчиков. Приведу лишь несколько – самых невинных! – цитат:

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

Я никому не позволю лезть в МОЙ код, потому что я за него отвечаю. И ни за кем не собираюсь исправлять их ошибки.

Если кодом владеют все – им не владеет никто. И никто за него не отвечает.

Хватит, пожалуй.

Начнем с первого. Что мы видим? Четкое разделение на "я" и "все остальные". Я отвечаю только за себя. На мой взгляд это первенство личных целей надо командными в явном виде. Ровно как у Райкина – "А я вообще только пуговицами занимался. К пуговицам претензии есть?" Так и тут. "Никто из нас не пожелает нести ответственность за чужие действия". Пока действия делятся на свои и чужие – команды нет. В команде действия могут быть только "наши".

Второе высказывание из той же серии. Моя хата с краю, я не хочу отвечать за других. Почему не хочу? Да потому что не доверяю. Боюсь, что кто-то сделает ошибку, а отвечать мне придется. И о поддержке речи тоже не идет. Он сам сломал – пусть сам и чинит. А я ему не собираюсь помогать.

Третье высказывание может быть верно в ситуации, когда напрочь отсутствуют ответственность, доверие и поддержка. Еще не попали в ситуацию, а уже предполагаем, что все будут отпираться от ответственности, т.е. доверия нет ни капли. Напрашивается тривиальное решение – сам не можешь починить? А тут сразу можно посмотреть на абзац выше – проблемы с поддержкой.

В конечном итоге все эти возражения упираются в отсутствие (и даже неприятие!) командных ценностей – доверия, равенства, уважения, поддержки и ответственности. Все эти составляющие жизненно необходимы для успешной реализации практики коллективного владения кодом:

• Доверие – я доверяю членам моей команды в том, что они не повесят на меня ответственность за свои ошибки
• Равенство – я исправляю любой код, вне зависимости от авторства
• Уважение – я уважаю членов команды, поэтому исправляю свои ошибки сам
• Поддержка – я исправляю чужие ошибки: мне это несложно, а товарищу по команде – помощь
• Ответственность – я отвечаю за свои действия и ошибки

Уберите любой из пунктов – и о коллективном владении кодом можно забыть. Т.е. нет хотя бы одной из ценностей команды – практика не работает.

Дальше идут следущие практики: Постоянные (непрерывные) интеграции кода, Заказчик в команде, Частые выпуски версий и 40-часовая рабочая неделя. Они, так же как и Простой дизайн, не связаны с командной работой. Потому мы переходим к практике

Стандарты кодирования

Эта практика требует ответственности и уважения. Из уважения к другим членам команды – чтобы не доставлять им неудобств при чтении собственного кода – необходимо взять на себя ответственность соблюдать стандарты. Несоблюдение сильно влияет на эффективность.

Наконец, последняя практика – Метафора системы – к командной работе тоже отношения не имеет.

* * *

Итак, резюме.

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

А теперь проведем эксперимент. Будем убирать ценности команды и смотреть, какие практики прекращают работать.

Отсутствующая ценность	Неработающие практики
Доверие	Планирование, Парное программирование, Рефакторинги, Коллективное владение кодом
Равенство	Парное программирование, Коллективное владение кодом
Уважение	Парное программирование, Рефакторинги, Коллективное владение кодом, Стандарты кодирования
Поддержка	Парное программирование, Рефакторинги, Коллективное владение кодом
Ответственность	Планирование, Тестирование, Парное программирование, Рефакторинги, Коллективное владение кодом, Стандарты кодирования

Впечатляет, правда?

Подводим итоги

Что хочется сказать в конце.

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

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

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

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

Надеюсь, мой труд даром не пропадет и статья окажется полезной. На этом всё. Спасибо всем, дошедшим до конца!

---

^1. Почему у новичка стоит крестик в резделе "безопасность". Практика показывает, что о безопасности – востребованности технологий, стабильности компании, повышении квалификации – новички, как правило, не думают. Для них главное – утвердиться в этой нише (а потребности третьего уровня – вхождение в команду, возможность учиться и т.п. – сильно в этом помогают), вопросы же безопасности всплывают сильно позднее. Именно потому в статье о профессионализме я на вопросах безопасности заостряю внимание (http://www.skipy.ru/philosophy/professionalism.html#questions). Это второй уровень пирамиды, и заниматься им необходимо как можно раньше, чтобы не иметь проблем впоследствии.

^2. В этом случае речь идет о команде, состоящей из профессионалов приблизительно равного уровня. В случае, когда области ответственности команды не покрыты, добавление каждого "правильного" члена команды увеличивает производительность очень сильно. Подробнее об этом в статье О профессионализме и не только (http://www.skipy.ru/philosophy/professionalism.html). А дальше – будет тот же эффект.

^3. Речь может идти, например, о финансовых вопросах, которые находятся в компетенции лидера на уровне руководителя управления и не ниже.

В начало

Copyright © 2004-2013 Евгений Матюшкин aka Skipy (e-mail: skiрyskipy.ru)
Копирование и воспроизведение материалов этого сайта возможно только с согласия автора!