В современной экономике принято считать, что конкуренция оказывает исключительно благотворное влияние на рынок. Она не даёт создаться монополии, не даёт ценам на товар или услугу превысить некие разумные пределы, заставляет производителя постоянно совершенствовать продукт, не останавливаться на достигнутом, чтобы не отстать от конкурентов.
Но всегда и везде ли хороша конкуренция? Что будет, если на модели конкуренции построить управление не только продуктами, но и людьми? К сожалению, очень многие «эффективные менеджеры» не осознают, что рыночные практики не всегда применимы, когда речь идёт о взаимодействии членов одной команды или команд внутри одной компании.
Примеры из жизни
Пример номер раз. Один очень известный западный бренд устроил настоящую конкуренцию среди отделов российского представительства, продающего детскую одежду и одежду для подростков. Реально и целенаправленно отделы сталкиваются лбами, среди них пестуется жестокое соперничество (например, выполнение плана считается по лучшему отделу, а худший получает штрафы). Руководство компании считает, что при таком давлении сотрудники работают быстрее и продуктивнее, стремясь обогнать «конкурентов».
Понятно, что сотрудники этих отделов ненавидят друг друга лютой ненавистью (умело подогреваемой руководством) и воспринимают друг друга врагами.
С другой стороны, рано или поздно ребёнок вырастает из одежды для детей, и ему требуется одежда для подростков. Вполне логичной стратегией было бы плавно «передавать» клиентов из одного подразделения в другое, устраивать совместные акции и т.д. Как вы думаете, заинтересованы ли две команды в таком сотрудничестве? Проводятся ли такие акции на самом деле? А в результате, компания упускает кучу возможностей по расширению клиентской базы и развитию отношений с покупателями.
Другой пример, уже из IT. Один топ-менеджер одной очень большой компании однажды придумал мерять сотрудников по рангам. Работаешь лучше других – получаешь премию. Работаешь хуже остальных – нагоняй от начальства и прочую немилость.
На первый взгляд, вроде бы логично. Лучшие получают больше всех, худшие уходят и заменяются на тех, кто будет работать более эффективно. Люди не расслабляются и работают на пределах своих сил, чтобы превзойти остальных и выдать результат, лучший, чем у коллег. Звучит радужно!
На самом деле, здесь есть одна ключевая проблема: люди не заинтересованы работать вместе. Вместо того, чтобы добиваться общих результатов совместными усилиями, они концентрируются на том, чтобы быть лучше остальных, не дать другим опередить себя по рангу.
Кстати, некоторые считают именно этот подход одной из главных причин неуспеха описываемой компании.
Насаждение такой конкуренции внутри команды вынуждает сотрудников работать в стиле win-lose – модели, при которой выигрыш одной стороны обязательно влечёт проигрыш второй (и наоборот). Если я выиграл, то ты проиграл. Если ты выиграл, то проиграл я. Чем же он так плох?
Win-Lose
В ходе любого проекта неизбежно возникают вопросы, которые нужно решать совместно, непонятные моменты, которые нужно прояснять, задачи, в решении которых требуется помощь других участников.
Если представить, что все члены команды работают «каждый за себя», то помогать коллеге не только не выгодно, но и вредно: в результате он окажется эффективнее и получит плюшки вместо вас. К тому же, чем больше проблем у коллеги, тем больше шансов, что вы окажетесь выше него при очередной аттестации.
Такой подход ещё более явно проявляется при общении с людьми из других команд, от которых зависит успех вашего проекта.
Думаю, каждый из нас хоть раз да слышал что-то вроде этого:
- Вася, если у тебя не собирается модуль – это твои проблемы, я свою часть работы уже сделал и тратить время на твои косяки не собираюсь.
- Я не могу дать тебе человека, так как они нужны на моём проекте. Приходи, когда проект закончится. Мне не важно, что твой проект в критическом состоянии. Это же твой проект, а не мой.
- Проекты вашего отдела всегда имеют пониженный приоритет перед проектами нашего отдела. Наши программисты не собираются тратить на них время.
- Меня не волнует, что там наобещали заказчику эти продавцы. Если мы не успеем — им же хуже, меня как разработчика это не касается.
Всё это – отсутствие командной культуры, подход ковбоя-одиночки из спагетти-вестерна. Такие подходы способствуют куче проблем на проекте, о которых мы сейчас и поговорим.
Задачи решаются очень долго или не решаются вообще
Представьте себе, что у вас возникла проблема, которую вы не можете решить самостоятельно. Например, для того, чтобы добавить новую функцию в клиентскую часть приложения, нужно передавать дополнительный параметр с сервера.
Разработкой серверной части занимается программист Вася, который участвует в том же внутреннем ранжировании, что и вы. Вы приходите к Васе и просите добавить новый параметр. Очевидно, что при этом у Васи есть и свои задачи, которые он в данный момент выполняет. Даже если этот параметр блокирует всю вашу работу, а текущая задача Васи абсолютно не важна, он вряд ли вам поможет. Он знает, что тем самым он задержит (пусть даже незначительно) свою работу, а вы при этом выполните свою часть быстро и качественно. Соответственно, он рискует оказаться позади вас в гонке за рангами.
Скорее всего, задачи такого типа будут согласовываться между вами, Васей, руководителем проектов и т.д. достаточно долгое время. При этом Вася изо всех сил будет сопротивляться попыткам поставить эту задачу ему. И не исключено, что у него получится.
В результате и вы, и Вася, и ваш общий менеджер потратят кучу сил, времени и нервов на согласования и споры вместо того, чтобы быстро решить мелкую задачу и двигаться дальше.
Проблемы появляются на пустом месте
Цель большинства участников команды, в которой принята конкурентная система «мотивации» – быть лучше других. Их не интересует, насколько удобно и комфортно работать соседям по команде. Им не до этого.
При этом, часто возникают проблемы, которых можно без труда избежать, если сотрудники думают о коллегах. Например, программист может, не посоветовавшись, внести изменения в код большого числа файлов зная, что над ними в данный момент работают несколько человек. Вполне реально, при этом, услышать от автора коммита что-то вроде: «им надо – пусть они и мержат (жарг. – сравнивают версии и исправляют конфликты). Я свою работу делаю».
Ещё пример: «Хоть Вася и умеет делать такие задачи – я к нему не пойду, а буду разбираться сам. А то ещё руководство решит, что я хуже Васи». Это тоже яркое проявление соперничества между членами команды, которое создаёт проблему на пустом месте.
Ну и, наверное, самым ярким примером может служить изобретение (и последующая поддержка) пяти разных решений одной и той же задачи пятью программистами. Просто никто не захотел делиться своими наработками со всей командой, а спрашивать у коллег не было желания (ведь, помогая товарищу, каждый делает себе хуже).
Скрытый саботаж
Скрытый саботаж является, вероятно, самым деструктивным проявлением внутренней конкуренции. Он представляет собой намеренное усложнение работы другим членам команды. Ярким примером такого саботажа можно считать, известную строку C++ кода: «#define TRUE FALSE //счастливой отладки, с*ки…»
Понятно, что открыто делать так будут лишь асоциальные уникумы, но скрытые провокации коллег с целью показать своё превосходство, к сожалению, могут очень сильно снизить производительность команды.
Кстати, есть и гораздо более изощрённые способы саботажа. Например, указать на критическую уязвимость в системе на презентации её генеральному директору вместо того, чтобы сообщить о ней заранее и дать команде время её исправить до важной встречи.
Ещё одним вариантом саботажа может служить «итальянская забастовка», т.е. работа в точном соответствии с инструкцией. Например, вместо того, чтобы выяснить непонятный момент в ТЗ, программист намеренно делает так, чтобы система не работала, но при этом на 100% соответствовала требованиям.
Безразличие и отсутствие общих целей
«Чего ты от меня хочешь? Я просто пишу код, всё остальное меня не касается». Такое заявление вполне можно понять. Зарплата, карьера и признание сотрудника зависит не от того, насколько успешен будет проект, не от результата его работы – чего-то важного и нужного людям, а только от того, с какой скоростью он пишет свой кусок кода.
У двух людей в команде две отдельные цели. Они оба хотят быть лучше своих коллег. Ни у одного нет потребности сделать хороший продукт и скорее вывести его на рынок. Безусловно, общее качество продукта, как и эффективность работы команды в целом, страдает.
Если с другими проблемами, описанными выше ещё можно как-то бороться (например, административными методами), то проблема отсутствия общих целей в системе, где проповедуется конкуренция внутри команды, практически не лечится. У людей не может быть общих целей, если успех одного члена команды означает неудачу другого. Рано или поздно команде придёт конец.
Как же мотивировать людей делать общее дело?
Win-win
Как показывает опыт, эффективное сотрудничество и взаимопомощь в команде позволяет добиться потрясающих результатов. Команда, которая чувствует себя как одно целое, в которой царит дух взаимопомощи и ответственности за общее дело, может творить чудеса.
Каждый её член вместо того, чтобы тянуть одеяло на себя, не только отвечает на просьбы о помощи, но и сам постоянно думает о том, как можно сделать работу окружающих более комфортной, эффективной и быстрее достичь общей цели.
Для этого достаточно, чтобы от успеха каждого члена команды выигрывали все остальные. Работать в модели Win-Win. Эта модель очень хорошо описана в великолепной книге Стивена Кови (если вы, вдруг, её не читали – бегом в магазин!).
Например, если один член команды добился каких-то результатов, то плюшки получает вся команда. Очень хорошая практика — отмечать окончание любого более-менее крупного проекта совместными мероприятиями (например, походом в кафе).
Кроме того, имеет смысл активно поощрять помощь коллегам, а также общие активности – мозговой штурм, обсуждение архитектуры, обмен опытом и т.д.
И, самое главное — необходимо ясно и чётко донести до всех мысль: «у нас всех одна цель, мы все делаем одно общее дело» и не нарушать этот подход ни своими словами, ни делами.
Люди должны понимать: они могут сделать что-то значимое только вместе, только объединив усилия. Каждый член команды – это не помеха в карьерном росте, а друг, который подаст вам руку (или подтолкнёт вверх), когда вы будете взбираться на очередную ступеньку на этой лестнице.
Только в этом случае у команды будет шанс сделать что-то важное и значимое, а не просто протирать клавиатуру компьютеров, выпуская раз за разом клоны никому не нужной поделки.
Удачи в ваших разработках, и пусть в вашей команде царит сотрудничество (такое, как у нас :)!
Кстати, есть несколько ситуаций, в которых конкуренция между командами полезна. Но это совсем другая история…
Автор: Tomcat
