Что такое полярные взгляды в команде
Что такое полярные взгляды в команде
З апись моего Вебинара “Почему мы растим Новых детей?» расположена после статьи.
…Жизнь вокруг нас стремительно меняется. То, что было экзотикой 5-7 лет назад, становится просто вариантом, доступным для выбора каждому: отказ от престижной профессии в пользу любимого хобби, которое становится делом жизни; переезд на постоянное место жительства из крупного города в красивое безлюдное место, семейное образование для детей и обучение на авторских тренингах для взрослых; «здоровое питание» в супермаркетах и отделения нетрадиционной медицины в крупных медицинских центрах… Такое ощущение, что сквозь декорации старой жизни, основанной на тяжкой борьбе за успех, здоровье и благополучие, прорастает другой мир – ищущий удовлетворения, простоты, согласия и удивительных творческих возможностей.
Если присмотреться внимательнее, то мы заметим, что эти 2 мира основаны на противоположных мировоззрениях:
Полярном и Целостном
Полярное мировоззрение говорит само за себя: это когда любое явление или поступок получает штамп с отметкой «хорошо» или «плохо». За одно – хвалят, за другое – ругают, одно ценят, с другим – воюют. Характерной чертой полярного мышления является опора на авторитеты – каждый из нас не может знать наверняка что именно – «хорошо», а что – «плохо». Поэтому в человеческом Обществе с незапамятных времен существует борьба за идеологическое право указывать: что в данный момент есть «хорошо», и что есть «плохо». В процессе эволюции эти нормы меняются, но всегда есть преобладающее представление о крайних полярностях. Получается, что категорическая норма одного времени становится курьезом, или абсурдом для другого (очень показательна эпоха разрушения социализма в СССР в этом смысле).
Целостный подход к Жизни основан на понимании бесконечности ее процесса: все относительно!
То, что в одной ситуации – хорошо, в другой – оказывается плохим; то что для одного человека пища – для другого – яд; то, что сейчас надо «позарез» завтра аукнется так, что лучше бы этого не делать… Целостный подход предполагает, что все в этом мире взаимосвязано, поэтому любое событие нашей жизни – это не случайность, а резонанс, обратная волна, неких наших прошлых действий. А самое замечательное в Целостном подходе – так это возможность менять последствия ошибочных выборов «задним числом». Но это – отдельная тема и мы еще поговорим о ней.
Вся наша человеческая история убедительно демонстрирует неуважение к Целостному подходу:
-герой войны для побежденной стороны оказывается мародером и насильником;
-осушение болот и проведение каналов заканчиваются засухами и наводнениями;
-удобрения и пестициды увеличивают урожаи и одновременно отравляют нас;
-активные усилия по развития и образованию детей приводят к отсутствию потребности в новом поколении даже просто ЧИТАТЬ, не то, что «стремиться к знаниям».
Почему так происходит? Разве раньше в мире действовали другие Законы Природы?
Почему именно сейчас мы коллективно (впервые!) так очевидно заметили эти «ножницы» между нашими целями и результатами?
Причем как в масштабе человечества: в политике, экологии, судебной, медицинской, образовательных системах… Так и в нашей частной жизни: в отношениях с людьми, с самим собой, своем отношении к здоровью, успеху и счастью… Стремимся к одному, а получаем – другое.
Ответ прост: время ускорилось! События, которые являются причиной происходящего, еще у нас на памяти, и трудно не заметить, что последствия – закономерный результат нашего же выбора.
В связи с новыми технологиями время, в котором мы живем, стало гораздо стремительнее. Раньше между ошибочным выбором одного поколения и расплатой другого, проходило лет 50. Те, кто радовался расцвету садов в засушливой Средней Азии – одни люди, а те, кому пришлось бежать с занесенного солью побережья высохшего моря – совсем другие.
Например, кто-то, из уважения к своим родителям, или просто под давлением обстоятельств, выбирал нелюбимую профессию и добровольно заставлял себя изо дня в день «тянуть лямку», пока это не приводило его к язве желудка или другим подобным неприятностям. А современные дети сразу бьются «на смерть» за свою свободу – у них не будет 10-15ти лет медленного «тления», сейчас молодые люди разрушаются самым разным способом – от депрессии до онкологии – только потому, что им невыносимо жить чужими целями…
Сейчас все иначе.
Задыхаясь этим летом от дыма в Москве, многие задумались о том, что мы сами нарушили экологический баланс, и теперь пожинаем плоды своих неразумных деяний. Это коллективное осознание причин и следствий в последнее время касается самых разных вопросов.
Вероятно, настало время, когда события современной жизни побуждают многих людей задаться вопросами:
И согласны ли мы с таким водительством.
Для многих стало понятно, что невозможно строить свою жизнь дальше, не понимая Целой картины. А Целая картина, на первый взгляд, выглядит плачевно, поскольку прежний мир очевидно разрушается.
Это пугает. Хочется «не думать» и дать себя убедить в обратном: все вернется каким-нибудь способом «в прежнюю норму», и будет ясно указано: «Это хорошо, а это – плохо, это – правильно, а это – нет. Следуй общепринятой норме, и ты будешь благополучен!»
Кроме страха есть еще и привычка доверять общепринятым «штампам». Достаточно принять для себя некое авторитетное мнение – и Вам не о чем беспокоиться:
Вы лечите, например, ребенка традиционными препаратами, назначенными доктором, а то, что у малыша при таком общепринятом лечении все короче «здоровые» промежутки между «простудами», Вас не беспокоит – Вы же не врач.
Или, например, Вы допоздна сидите за уроками со своим второклассником, ежедневно выполняя массу странных заданий, мало связанных, по сути, с обучением грамоте и счету, но только спустя пару лет искренне недоумеваете – почему у Вас растет такой безразличный и не любознательный ребенок.
Или еще типичный пример: Вы тщательно заботитесь от том, что бы Ваше чадо получало во время еды, «как положено» 1-2-3е, но в результате тот тоненький стебелек, на котором держится головка Вашего сына или вашей дочери, все ниже и все бессильнее склоняется за столом, на котором приветливо (для вас) дымиться наваристый суп… Вы раздражаетесь на сопротивление ребенка, но не замечаете парадокса, потому что следуете правильным рекомендациям специалистов.
Что же, как говориться – Бог Вам в помощь.
Но если Вы начинаете чувствовать какой-то театр абсурда во всем происходящем, хотя это происходящее считается «нормальным» пока еще для многих – я Вас поздравляю.
Это значит, что Вы просыпаетесь от коллективного сна.
Как только Вас начинает занимать вопрос «зачем. » – жизнь Ваша неизбежно начнет меняться:
Зачем я заставляю себя делать то, что мне противно и учу этому своего ребенка.
Зачем я трачу свое время на общение с людьми, которые мне неприятны.
Зачем покупаю продукты, от которых, знаю, здоровья мне не прибавится.
Зачем я вообще-то курю.
Зачем смотрю этот «дурацкий ящик» каждый вечер.
И почему это все считается НОРМОЙ.
Вероятно из-за углубившейся «специализации» во всех областях нашей жизни «Общая сумма» авторитетных рекомендаций становится сплошным противоречием.
И отнюдь не потому, что «специалисты» не правы, просто Жизнь – больше, чем сумма специальных рекомендаций. И на главные вопросы каждому приходится отвечать самостоятельно.
Примерно так же все человечество просыпается в преддверии 2012 года – естественной астрологической даты смены циклов развития разумной жизни на планете, о которой отлично были осведомлены «посвященные» многих древних Цивилизаций.
В глобальном смысле впервые не единицы, а тысячи и даже миллионы жителей планеты задумались о том, например: зачем они нарушают экологический баланс планеты?
Зачем убивают друг друга?
Зачем проживают свои жизни как жертвы?
Зачем отдают свою силу всевозможным лидерам, ввергающим их народы в войны, кризисы религиозные противостояния, забывая о своем личном выборе.
Возможно, мы, наконец, созрели для того, что бы коллективно измениться.
Даже плоды на дереве никогда не созревают в один момент, что уж говорить о пробуждении человеческой Души. Поэтому в наши дни совершенно нормально одновременное сосуществование людей «полярного» склада и тех, кто стремиться ощутить Общий Смысл Жизни. Для последних – очевидно: борьба не может увеличить мир и процветание. Что бы что-то улучшить, надо это понять. А то, что ты понял, позволяет тебе простить, принять и преобразовать в лучшую сторону. И начинается все с содержания собственных мыслей и чувств.
Сейчас общеизвестной стала истина о том, что мысль – материальна. Все наши страхи, тревоги, ненависти и обиды неизбежно создадут в нашей же реальности события, подтверждающие наши ожидания. Тот, кто боится воров – будет ограблен, кто страшится предательства – окажется брошен, сомневается в своей уникальности и ценности – встретит неуважение и эксплуатацию. И наоборот: если внутри у Вас царит спокойствие, вы пройдете сквозь беснующуюся толпу, даже незамеченные людьми, в нее включенными (многократно зафиксированный феномен) Если вы сумеете во встречном человеке увидеть внутренний Свет – лично к Вам он повернется именно этой, лучшей стороной (у каждого в жизни найдется такой пример). Если Вы верите в свою мечту, идете на встречу ей – она обязательно сбывается.
Почему же мы продолжаем боятся, обижаться и ненавидеть, даже понимая, что это вредит нам?
Потому что при ближайшем рассмотрении оказалось, что стать хозяином своих мыслей очень непросто. Особенно если десятилетиями в Вас «закладывали» программу «жертвы обстоятельств». И сейчас эта программа в масштабах человечества привела нас к закономерному результату: чего боимся, то и получаем. Коллективно. НО не все так безнадежно! Набирает силу противоположная тенденция: готовность и способность людей научиться Творению своей жизни по собственному выбору.
А теперь посмотрите повнимательнее на своих детей, дорогие коллеги – родители: наши дети отказываются усваивать роли зависимых исполнителей чужой воли. Они не хотят признавать себя «плохими», если пишут с ошибками, или не спешат заправить за собой постель. Они требуют от нас понимания и любви, хотя взамен не готовы «слушаться старших». Более того – они открыто указывают нам на несоответствие наших слов и действий, на противоречие между поучительными наставлениями, как бы «ведущими к счастью» и нашими собственными достижениями в этой области. Они хотят радоваться каждому дню своей жизни сейчас, а не когда-то «потом» – совершенно справедливо ощущая, что это «потом» никогда не наступит.
И они правы: самочувствие сегодняшнего дня творит Ваше завтра. Поэтому если в текущий момент у Вас все в «раздрызге», а вы сумеете улыбнуться этому –завтра дела наладятся. И наоборот – фактические успехи на фоне душевной безотрадности очень быстро сделают Вас банкротом.
Или Вам пока не заметны эти причинно-следственные связи?
Ну, так дети Вам покажут это на фактах Вашей жизни.
Именно индиго, своей несовместимостью с насильственными системами прежней эпохи, изменяют сознание родителей, а значит – взрослых жителей Земли.
К счастью, первому поколению их уже заметно за 20, и именно они воплощают собой новый тип мышления, основанный на доверии своему сердцу. А вместе с мышлением меняется и образ жизни. Что же это за новый образ жизни, который позволит человечеству шагнуть в новую эпоху, сохранившись как вид, не смотря на перемены климата, электромагнитных полей и прочих параметров Земли?
Об этом – на моем открытом вебинаре “Почему мы растим Новых детей?”
Умеете ли вы работать в команде: что это значит на самом деле?
Есть два психологических портрета человека. Кого из них вы бы взяли к себе в команду?
Первый портрет: покладистый, улыбчиво-приветливый, нескандальный, готовый уступать, неконфликтный, ставит общие интересы выше своих, готов ради общего дела пойти против личных амбиций, «не высовывается», всегда открыт к общению.
Второй портрет: принципиальный и амбициозный, имеет и отстаивает по любому вопросу свое мнение, непослушный и своенравный, всегда готов к конфликту, экспертный и знает об этом, яркий и эгоцентричный, не готов идти на ущерб личных интересов, не умеет уступать.
Кого выберете вы? Какой ответ правильный?
Прежде чем его озвучить, позвольте задать вспомогательные вопросы.
И коллектив, и группа, и отдел, и бригада, и команда решают какие-то бизнес-цели. Они могут быть краткосрочными или долгосрочными. Но отличие команды в том, что у нее всегда есть свои внутренние цели, связанные с развитием команды в целом и каждого ее участника лично.
Зачем это надо команде? А дело в том, что настоящая команда и ее лидер ставят такие цели, которые невозможно достичь без развития всех ее членов. Поэтому команды бывают либо развивающимися, либо мертвыми.
Отсюда ответ на вопрос: «кто нужен команде»? Тот, кто будет способствовать ее развитию. За счет чего развиваются команда и бизнес? За счет качественных, продуманных, взвешенных и своевременных решений.
Способен ли один человек принимать постоянно по всем вопросам лучшие решения? Нет. Потому что каким бы он разносторонним ни был, его взгляд все равно ограничен его компетенциями и его представлениями о мире.
Для качественного решения нужны разные, порой полярные мнения, нужны хорошие сомнения и несогласия, нужен горячий обмен суждениями. И для этого нужны люди со своей позицией, готовые отстаивать и не соглашаться.
Если вы в команде думаете одинаково, согласны друг с другом, быстро находите консенсус, ловите на лету, находитесь «на одной волне» — значит, все, кроме одного, в ней лишние. Они — бесполезные клоны.
Но ведь это чревато постоянными конфликтами. Не будет ли это разрушать команду?
Конфликт — это столкновение противоречивых мнений. Может ли столкновение мнений само по себе что-то разрушить? Могут ли фразы, слова, буквы сами по себе обладать деструктивным действием? Нет! Их таковыми делают люди. Деструктивный конфликт происходит не от того, что люди о чем-то спорят, а от того, как они спорят.
И умение работать в команде по большому счету состоит из умения конфликтовать, не разрушая себя и других. Сами посудите, что может быть сильнее команды, в которой очень разные и очень сильные люди умеют вместе искать сильные решения, становясь каждый раз сильнее?
В таком случае возникает логичный вопрос: а что значит «уметь конфликтовать»?
Умение конфликтовать — это умение спорить, доказывать, не соглашаться, оставаясь конструктивным, не вызывая у других желания защищаться и нападать, не обижая чувств другого человека, помня о целях этой дискуссии, не теряя своего достоинства и не умаляя достоинства других. Все это называется одним словом: «Уважение».
Командный игрок — это человек, способный проявлять уважение к другим и вызывать уважение к себе. Уважение — двустороннее явление.
Как протестировать способность человека к уважению?
Это проявляется в том, как человек с вами не соглашается, как реагирует на несогласие с ним, как отзывается о других и соблюдает правила.
Понятно, что заставить уважать кого-либо силой невозможно. Также невозможно измерить степень уважения друг к другу. И то, что для одного кажется верхом уважения, другому может показаться оскорблением.
Но также возможно создать в команде общую культуру взаимоуважения, основанную на принятых правилах. Эти правила формируются сообща из ответов на вопрос: «Что нам мешает чувствовать взаимное уважение»?
Ответов будет много: мы опаздываем на совещания, перебиваем друг друга, не слушаем, отвлекаемся на посторонние вопросы, не пытаемся понять точку зрения другого, а стараемся продавить свою, перехватываем инициативу, не даем слова тихоням. Из этих ответов и формируются правила.
И каков же правильный ответ на вопрос о том, кого бы взяли в команду?
Есть люди удобные, а есть люди полезные. Редко это совмещается. Если вы хотите работать в комфорте и без конфликтов, то вам не нужна взаимодополняющая развивающаяся команда.
Если же от ваших целей и амбиций у вас захватывает дух, то вам нужны хорошие решения и отличные помощники. Лучшие помощники — это люди, несогласные с вами и готовые с уважением отстаивать свою точку зрения, не обижая вас. Они будут находить изъяны в ваших решениях, открывать для вас другие ракурсы, позволять смотреть на ситуацию с разных сторон, видеть подводные камни и заранее обращать внимание на детали.
Говоря об умении работать в команде, я вспоминаю притчу о том, как человек по дороге в рай попросил показать ему ад. И он был очень удивлен, потому что увидел красивое изобильное место, полные столы с нетронутыми яствами и злых голодных людей. На вопрос, почему они голодные, ему ответили, что здесь можно кушать только трехметровыми палочками. Человек посочувствовал и оказался в раю. Там он увидел точно такую же картину, только люди были сытые и довольные. Он первым делом спросил, чем они тут кушают, и ему ответили, что трехметровыми палочками. Он удивился еще сильнее, пока ему не объяснили, что здесь, в раю, люди научились кормить друг друга.
Управление конфликтами в команде – эквилибристика или жизненная необходимость?
Эпиграф:
Встретились как-то в лесу Ёжик и Медвежонок.
— Здравствуй, Ёжик!
— Здравствуй, Медвежонок!
Так, слово за слово, шутка за шуткой, и получил Ёжик от Медвежонка по морде …
Под катом рассуждения нашего тимлида, а также директора по развитию продукта RAS — Игоря Марната о специфике рабочих конфликтов и возможных методах управления ими.
Большинство конфликтов, с которыми мы сталкиваемся на работе, развиваются по сценарию, похожему на описанный выше в эпиграфе. Есть несколько участников, изначально настроенных друг к другу вполне благожелательно, они пытаются решить какой-то вопрос, но в итоге проблема так и остаётся нерешённой, да и отношения между участниками обсуждения почему-то оказываются испорчены.
Жизнь — многообразна, в описанном выше сценарии случаются вариации. Иногда отношения между участниками бывают не очень хорошими изначально, иногда нет даже вопроса, требующего непосредственного решения (как, например, в эпиграфе), иногда после обсуждения отношения остаются такими же, что и до его начала, но вопрос в итоге так и не решён.
Что же есть общего во всех ситуациях, которые можно определить как ситуация рабочего конфликта?
Во-первых, это наличие двух или более сторон. Эти стороны могут занимать различное место в организации, находиться в отношениях равенства (коллеги в команде), или на разных уровнях иерархии (начальник — подчинённый), быть индивидуальными (сотрудник) или групповыми (в случаях конфликта между сотрудником и командой или двумя командами), и так далее. На вероятность конфликта и простоту его разрешения очень влияет уровень доверия между участниками. Чем лучше стороны знают друг друга, чем выше уровень доверия, тем выше шанс, что они договорятся. К примеру, сотрудники распределённой команды, которые никогда не общались лично, с большей вероятностью войдут в ситуацию конфликта при решении простого рабочего вопроса, чем люди, которые хотя бы несколько раз общались лично. Поэтому, работая в распределённых командах, очень важно обеспечить периодические личные встречи всех членов команды друг с другом.
Во-вторых, в ситуации конфликта на работе стороны находятся в ситуации решения какого-то вопроса, важного для какой-то из сторон, для них обеих или для организации в целом. При этом, в силу специфики ситуации, стороны обычно имеют достаточно времени и разнообразных способов его решения (формальных, неформальных, встречи, письма, решения руководства, наличия целей и планов команды, факт наличия иерархии, и т.д.). В этом отличие от ситуации решения рабочего (или не рабочего) вопроса в организации от, к примеру, решения важного вопроса: “Э, пацан, ты из какого района?!” на улице, или конфликта из эпиграфа. В случае решения рабочего вопроса имеют значение качество рабочего процесса и культура решения вопросов в команде.
В третьих, определяющим фактором конфликта (с точки зрения нашего обсуждения) является тот факт, что стороны процесса не могут самостоятельно прийти к решению вопроса, устраивающему все стороны. Ситуация требует вмешательства третьей стороны, внешнего арбитра. Этот пункт может показаться спорным, но, в сущности, если конфликтная ситуация успешно разрешилась без вмешательства внешнего арбитра, вопрос решён успешно и отношения сторон не ухудшились, это та ситуация, к которой нужно стремиться. Мы о таком конфликте даже, скорее всего, и не узнаем, или узнаем случайно после его разрешения. Чем больше вопросов команда может решить самостоятельно, тем более эффективно она будет работать.
Ещё одна характерная черта конфликта, которой стоит коснуться — степень эмоционального накала при решении. Конфликт не обязательно связан с высоким эмоциональным градусом. Участникам не обязательно кричать и махать руками, чтобы ситуация была, в сущности, конфликтной. Вопрос не решается, определённое эмоциональное напряжение при этом присутствует (возможно, оно не выражено вовне явно), значит, перед нами ситуация конфликта.
Нужно ли вообще вмешиваться в конфликтные ситуации, или лучше пустить их решение на самотёк и ждать, когда проблема рассосётся сама? Нужно. Не всегда в вашей власти или компетенции решить конфликт полностью, но в любой ситуации, в конфликте любого масштаба, вы можете занять взрослую позицию, тем самым выведя на неё ещё несколько человек вокруг себя, смягчить негативные последствия конфликта и поспособствовать его решению.
Перед тем как рассмотреть несколько примеров конфликтных ситуаций, остановимся на нескольких важных моментах, общих для всех конфликтов.
При решении конфликта важно быть над схваткой, а не внутри её (это ещё называют “занять метапозицию”), то есть, не оказаться в процессе решения в составе одной из сторон. В противном случае из внешнего арбитра, помогающего решению, вы лишь усилите позицию одной из сторон в ущерб другой стороне. При принятии решения важно, чтобы оно было морально принято всеми сторонами, как говорится, «куплено». Чтобы, даже если стороны и не были в восторге от принятого решения, они хотя бы были искренне согласны его исполнять. Что называется, быть в состоянии disagree and commit. Иначе конфликт просто изменит вид, тлеющий огонь останется под торфяником и в какой-то момент неизбежно разгорится снова.
Второй момент, отчасти связанный с первым — если вы уж взялись участвовать в решении конфликта, отнеситесь к этому максимально серьёзно с точки зрения коммуникаций и изучения контекста. Поговорите лично с каждой из сторон. Отдельно с каждой, для начала. Не довольствуйтесь почтой. В случае распределённой команды — поговорите хотя бы по видеосвязи. Не довольствуйтесь слухами и пересказами свидетелей. Поймите историю, чего хочет каждая из сторон, почему она этого хочет, чего ожидает, пробовали ли решить этот вопрос раньше, что будет, если он не будет решён, какие варианты решения они видят, как представляют позицию другой стороны, что, на их взгляд, правильно или неправильно, и т.д. Загрузите в свою голову весь возможной контекст, непредвзято, предполагая, что все правы. Вы не внутри конфликта, вы снаружи него, в метапозиции. Если контекст доступен только в почтовом треде — хотя бы прочитайте целиком его и относящиеся к нему обсуждению треды и документы. После того как прочитали — все равно поговорите голосом. Почти гарантированно вы услышите что-нибудь важное, чего нет в почте.
Третий важный момент — общий подход к общению. Это обычные вещи, ничего космического, но они имеют очень большое значение. Не пытаемся сэкономить время, разговариваем со всеми участниками, критикуем не человека, а рассматриваем последствия его действий (не “ты груб”, а “пожалуй, ребята могут на эту штуку обидеться”), даём возможность сохранить лицо, обсуждения проводим лично, а не перед строем.
Конфликты обычно бывают вызваны одной из двух причин. Первая связана с тем, находится ли человек в момент конфликта в позиции взрослого или в позиции ребёнка (об этом ниже). Это связано с его эмоциональной зрелостью, способностью управлять своими эмоциями (что, кстати, совсем не всегда связано с его возрастом). Вторая распространённая причина — несовершенство рабочего процесса, которое создаёт ситуации серых зон, в которой ответственность размазана между участниками, ожидания сторон не прозрачны друг для друга, роли в процессе размыты.
Соответственно, в решении конфликта (как и любого другого вопроса) менеджер должен иметь в виду три перспективы: краткосрочную — решить вопрос/конфликт здесь и сейчас, среднесрочную — минимизировать вероятность возникновения другого конфликта по такой же причине, и долгосрочную — воспитание в команде культуры взрослого человека.
В каждом из нас есть внутренний ребёнок, примерно трёх-четырёх лет. Большую часть времени на работе он спит, но иногда просыпается и берёт управление на себя. У ребёнка свои приоритеты. Ему важно настоять на том, что это его песочница, мама любит его больше, его машинка лучше всех (дизайн лучше всех, он программирует лучше всех, …). В ситуации конфликта ребёнок может прижимать игрушки, топать ногами и треснуть лопаткой, но он не может решать взрослые вопросы (архитектура решения, подходы к автоматическому тестированию, сроки релиза, и т.д), он не мыслит в терминах пользы для команды. Ребёнка в конфликте можно ободрить, утешить и отправить спать, попросив его позвать своего взрослого. Перед началом обсуждения в условиях конфликта убедитесь, что вы сейчас разговариваете со взрослым, а не с ребёнком, и сами стоите на позиции взрослого. Если ваша честная цель в данный момент — решить серьёзный вопрос, вы на позиции взрослого человека. Если ваша цель — топать ногами и треснуть лопаткой — это детская позиция. Отправьте своего внутреннего ребёнка спать и позовите взрослого, или перенесите обсуждение. Человек принимает эмоциональное решение, а затем подыскивает ему рациональное обоснование. Решение, принятое ребёнком, исходя из детских приоритетов, не будет оптимальным.
Кроме поведения в момент конфликта, детская или взрослая позиция характеризуется так же уровнем ответственности, которую человек готов взять на себя. В крайних проявлениях, детская позиция программиста, которую я встречал неоднократно, выглядит так: я код написал, отправил его на ревью — моя работа закончена. Ревьюеры должны его просмотреть и смёржить, QA должны его проверить, если будут проблемы — они мне сообщат. Как ни странно, даже довольно взрослые и опытные люди иногда ведут себя подобным образом. Другой край шкалы — человек считает себя ответственным за то, чтобы его код работал, был покрыт тестами, был проверен лично им, успешно прошёл ревью (если нужно, нет проблем попинговать ревьюеров, обсудить вопросы голосом, и т.д.) и был смёржен, QA при необходимости будет оказана помощь, описаны сценарии тестирования, и т.д. В нормальных случаях программист либо изначально находится ближе ко взрослому краю шкалы, либо смещается туда по мере накопления опыта (при условии, что в команде культивируется правильная культура). В экстремальных же случаях он продолжает работать, занимая обычно детскую позицию, тогда у него и команды периодически возникают проблемы и конфликты.
Воспитание в команде правильной, взрослой культуры — важная задача любого менеджера. Она требует длительного времени и ежедневных усилий, но результат того стоит. Есть два способа повлиять на культуру команды — личный пример (которому обязательно будут следовать, команда всегда смотрит на лидера) и обсуждение и поощрение правильного поведения. Здесь тоже нет ничего заумного или сильно формального, просто при обсуждении проблем замечайте, что здесь можно было бы сделать так-то, подчеркивайте, что заметили, когда решено правильно, похвалите, отмечайте на разборе релиза, и т.д.
Рассмотрим несколько типичных конфликтных ситуаций, от простого к сложному:
Конфликты, не связанные с рабочими вопросами
Довольно часто на работе случаются конфликты, не связанные с рабочими вопросами. Их возникновение и лёгкость разрешения обычно напрямую связаны с уровнем эмоционального интеллекта участников, уровнем их взрослости, и не связаны с совершенством или несовершенством рабочего процесса.
Типичные примеры — кто-то недостаточно часто пользуется стиральной машиной или душем, что не нравится окружающим, кому-то душно, а другому дует, если открывать окно, кто-то слишком шумный, а окружающим нужна тишина для работы, ну и так далее. С решением конфликтов такого рода лучше не затягивать и не пускать на самотёк. Сами собой они не рассосутся и будут ежедневно отвлекать от работы и отравлять атмосферу в команде. По счастью, решить их обычно больших проблем не составляет — достаточно спокойно поговорить (разумеется, один на один) с коллегой, пренебрегающим гигиеной, обеспечить комфортную рассадку людей, которые предпочитают тишину/прохладу, купить звукопоглощающие наушники или поставить перегородки, и т.д.
Другой пример, который встречался мне за время работы несколько раз — психологическая несовместимость членов команды. По каким-то причинам люди просто не могут работать вместе, каждое общение заканчивается скандалом. Иногда это связано с тем, что люди придерживаются полярных взглядов по какому-то животрепещущему вопросу (обычно политическому) и не умеют оставлять их за пределами работы. Убеждать их потерпеть друг друга или изменить своё поведение — занятие достаточно бесперспективное. Единственное исключение, которое я встречал — молодые коллеги с открытым восприятием, их поведение еще можно постепенно изменить периодическими разговорами. Обычно вопрос успешно решается разведением их по разным командам, или, по крайней мере, обеспечением возможности крайне редко пересекаться по работе.
Во всех приведённых ситуациях со всеми участниками стоит поговорить персонально, обсудить ситуацию, поинтересоваться, видят ли они вообще проблему в данном случае, спросить, какие, по их мнению, есть пути решения, обеспечить их участие в принятии этого решения.
С точки зрения оптимизации рабочего процесса (среднесрочная перспектива, о которой я упоминал), сделать здесь можно не очень много, единственный момент для оптимизации — учитывать фактор совместимости при формировании команды и заранее не ставить вместе людей, которые будут конфликтовать.
С точки зрения культуры команды, такие ситуации возникают намного реже в командах с взрослой культурой, где люди уважают команду и коллег и умеют решать вопросы самостоятельно. Кроме того, такие конфликты решаются намного проще (часто автоматически) в командах, где высок уровень доверия, люди давно работают вместе и/или часто общаются вне работы.
Конфликты, связанные с рабочими вопросами:
Такие конфликты вызваны обычно обеими причинами сразу, и эмоциональной (тем, что кто-то из участников не находится на позиции взрослого), и несовершенством самого рабочего процесса. Самый, пожалуй, частый вид конфликтов, который я встречал — конфликты в процессе ревью кода или обсуждения архитектуры между разработчиками.
Я бы выделил здесь два типичных случая:
1) В первом случае разработчик не может добиться ревью кода от коллеги. Патч отправлен на ревью, и ничего не происходит. На первый взгляд, явного конфликта между двумя сторонами нет, но, если вдуматься, это вполне себе конфликт. Рабочий вопрос не решается, одна из сторон (ожидающая ревью) испытывает явный дискомфорт. Экстремальный подвид такого случая — разработка в коммьюнити или в разных командах, при этом ревьюер может быть не заинтересован в этом конкретном коде, в силу загрузки или других обстоятельств может вообще не обращать внимания на запрос на ревью, и внешнего арбитра (общего для обеих сторон менеджера) может вообще не быть.
Подход к решению, который помогает в такой ситуации, относится как раз к долгосрочной перспективе, культуре взрослого человека. Во-первых, работает разумная активность. Не стоит ожидать, что висящий на ревью код обратит на себя внимание ревьюера сам. Нужно помочь ревьюерам его заметить. Пингани пару человек, задай вопрос на синкапе, участвуй в обсуждениях. Очевидно, что назойливость скорее повредит, чем поможет, нужно включать здравый смысл. Во-вторых, хорошо работает предварительная подготовка. Если команда понимает, что и почему происходит, зачем этот код вообще нужен, дизайн был обсуждён и согласован заранее со всеми, люди скорее обратят внимание на такой код и примут его в работу. В третьих, работает авторитет. Если ты хочешь, чтобы тебя ревьюили — делай много ревью сам. Делай качественные ревью, с реальными проверками, реальными тестами, полезными комментариями. Если твой ник известен в команде с хорошей стороны, больше шансов, что на твой код обратят внимание.
С точки зрения рабочего процесса, возможные улучшения здесь — правильная расстановка приоритетов, направленная на то, чтобы помочь разработчику достигать своих целей и целей команды (делать ревью других, писать письма в коммьюнити, сопровождать код описанием архитектуры, документацией, тестами, участвовать в обсуждениях с коммьюнити, и т.д.), не допускать слишком долгого зависания патчей в очереди, и так далее.
2) Второй распространённый случай конфликтов при ревью кода или дизайна — разные взгляды на технические вопросы, стиль кодирования, выбор инструментария. Огромное значение при этом имеет уровень доверия между участниками, принадлежность к одной команде, опыт совместной работы. Тупик наступает тогда, когда кто-то из участников занимает детскую позицию, не пытается услышать, что ему хочет донести собеседник. Часто при этом и подход, предложенный другой стороной, и подход, предложенный изначально, вполне могут успешно работать и не имеет принципиального значения, какой именно выбрать.
Как-то раз программист из моей команды (назовём его Паша) подготовил патч с изменениями в систему развёртывания пакетов, которую разработали и поддерживали коллеги из соседнего департамента. У одного из них (Игоря) было своё сильное мнение относительно того, как именно нужно настраивать сервисы Линукса при развёртывании пакетов. Это мнение отличалось от подхода, предложенного в патче, и договориться у них не получалось. Как обычно, сроки поджимали, и было нужно прийти к какому-то решению, нужно было, чтобы кто-то из них занял взрослую позицию. Паша признавал, что оба подхода имеют право на жизнь, но ему хотелось, чтобы его вариант прошёл, т.к. явных технических преимуществ не было ни у одного, ни у второго варианта.
Наше обсуждение выглядело примерно так (весьма схематично, конечно, разговор был на полчаса):
— Паша, у нас через несколько дней feature freeze. Важно, чтобы мы всё собрали и начали тестирование как можно скорее. Как бы нам пройти через Игоря?
— Он хочет настраивать сервисы по другому, комментариев там налепил мне …
— И что там, большие переделки, много возни?
— Да нет, там работы на пару часов, но в итоге разницы ведь нет, и так, и так будет работать, зачем это нужно? Я сделал работающую вещь, давай её и примем.
— Слушай, а сколько уже вы это всё обсуждаете?
— Да уже недели полторы топчемся.
— Эм … мы можем за пару часов решить вопрос, который уже занял полторы недели, и не делаем этого?
— Ну, да, но мне не хочется, чтобы Игорь подумал, что я прогнулся …
— Слушай, а тебе самому что важнее, релиз выпустить, вместе с твоим решением внутри, или Игоря забороть? Можем забороть, тогда, правда, есть хороший шанс пролететь с релизом.
— Ну … было бы прикольно, конечно, нос Игорьку утереть, но ладно, релиз важнее, согласен.
— Тебе реально так важно, что думает Игорь? Честно говоря, ему вообще более-менее по барабану, он просто хочет единого подхода в разных местах той штуки, за которую он отвечает.
— Ну, ок, давай я сделаю так, как он просит в комментариях, и начнём тестирование.
— Спасибо, Паша! Я был уверен, что из вас двоих ты окажешься взрослее, хотя Игорёк и старше тебя:)
Вопрос решился, релиз выпустили в срок, Паша особого недовольства не испытывал, т.к. он сам предложил решение и реализовал его. Игорь вообще был доволен, т.к. его мнение учли и сделали так, как он предлагал.
Другой вид такого же, в сущности, конфликта — выбор между техническими решениями/библиотеками/подходами в проекте, особенно в распределённой команде. В одном из проектов, который позиционировался, как использующий C/C++, в итоге оказалось, что технический менеджмент проекта категорически против использования STL (Standard Template Library). Это стандартная библиотека языка, которая упрощает разработку, наша команда к ней очень привыкла. Оказалось, что проект намного ближе к C, чем к C++, что не очень вдохновляло команду, т.к. менеджмент постарался и набрал реально крутых плюсовиков. При этом, американская часть команды, и инженеры, и менеджеры, работали в компании давно, привыкли к существующему положению вещей, их всё устраивало. Российскую же часть команды собрали вместе совсем недавно, за несколько недель (в том числе и меня). Российская часть команды категорически не желала отказываться от привычного подхода к разработке.
Начались бесконечные письменные обсуждения между двумя континентами, письма по три-четыре экрана летали туда-сюда, в групповой рассылке и личные, от программистов — программистам и менеджерам. Как это обычно бывает, письма такого размера никто, кроме авторов и их горячих сторонников, не читал. Чаты поскрипывали от напряжения, передавая в разные стороны многоэкранные соображения относительно технических преимуществ STL, насколько хорошо она протестирована, безопасна, и вообще, как прекрасна жизнь с ней, и как ужасна без неё.
Длилось это всё довольно долго, до тех пор, пока я наконец не понял, что мы обсуждаем технические стороны вопроса, а проблема-то в реальности не техническая. Проблема не в достоинствах или недостатках STL или сложности работы без неё. Проблема скорее организационная. Нам нужно было просто понять, как устроена компания, в которой мы работали. Раньше ни у кого из нас опыта работы в такой компании не было. Дело было в том, что после разработки кода и выпуска его в production, поддержкой занимались совершенно другие люди из других команд, из других стран. Эта огромная инженерная команда из нескольких десятков тысяч инженеров (в совокупности) могла себе позволить только совершенно базовый минимум технических средств, так сказать, minimum minimorum. Всё, что выходило за рамки инженерного стандарта, сложившегося в компании, физически не могло быть поддержано в дальнейшем. Уровень команды определяется уровнем слабейших её членов. После того как мы поняли реальную мотивацию действий американской части команды, этот вопрос был снят с повестки дня, и мы все вместе успешно разработали и выпустили продукт, используя стандарты, принятые в компании. Письма и чаты в этом случае работали плохо, чтобы прийти к общему знаменателю, понадобилось несколько поездок и много личного общения.
С точки зрения рабочего процесса, в этом конкретном случае, помогло бы наличие описания используемых средств, требования к ним, ограничения на добавление новых, обоснование таких ограничений. Такие документы примерно соответствуют описанным в пунктах Reuse Strategy и Development Environment руководства “Manager’s Handbook for Software Development”, разработанного в NASA. Несмотря на свой возраст, он прекрасно описывает все основные активности и этапы планирования разработки ПО подобного рода. Наличие подобных документов очень упрощает процесс обсуждения того, какие компоненты и подходы могут быть использованы в продукте, и почему.
С точки зрения культуры же, очевидно, при более взрослой позиции, при которой стороны пытаются услышать и понять реальную мотивацию действий коллег и действуют исходя из приоритетов проекта и команды, а не личного эго, конфликт бы решился проще и быстрее.
В другом конфликте из-за выбора технического решения мне тоже понадобилось заметное время, чтобы понять мотивацию одной из сторон (очень уж необычный был случай), но, после того как мотивация была ясна, решение было очевидно.
Ситуация такая: в команде из примерно 20 человек появляется новый разработчик, назовём его Стас. Нашим стандартным инструментом для общения в команде был на тот момент скайп. Как потом выяснилось, Стас был большим фанатом открытых стандартов и опенсорсного ПО, и пользовался только инструментами и операционными системами, исходники которых доступны публично, и которые используют описанные публично протоколы. Скайп к таким инструментам не относится. Мы потратили уйму времени на обсуждения достоинств и недостатков этого подхода, попыток запуска аналогов скайпа на разных операционных системах, попытках Стаса убедить команду перейти на другие стандарты, писать ему персонально по почте, звонить ему персонально по телефону, купить ему второй компьютер специально для скайпа, и т.д. Наконец я понял, что это проблема, в сущности, не техническая и не организационная, она скорее мировоззренческая, даже, можно сказать, религиозная (для Стаса). Даже если бы мы в итоге соединили Стаса и скайп (на что уже ушло несколько месяцев), на любом следующем инструменте проблема возникла бы снова. У меня в распоряжении не было реальных средств изменить мировоззрение Стаса, и не было оснований пытаться изменить мировоззрение команды, которая прекрасно работала в этом окружении. Человек и компания просто были ортогональны по мировоззрению. В подобных ситуациях хороший вариант решения — организационный. Мы перевели Стаса в другую команду, где он был более органичен.
Причина этого конфликта, на мой взгляд, в несоответствии личной культуры конкретного человека (у которого есть сильное мнение, не позволяющее ему идти на компромиссы), культуре компании. В данном случае это, конечно, ошибка менеджера. Было изначально неправильно брать его на проект подобного рода. Стас в итоге перешёл на проект по разработке открытого ПО и прекрасно там преуспел.
Хороший пример конфликта, вызванный одновременно детской позицией разработчика и недостатками рабочего процесса — ситуация, в которой в отсутствие definition of done у разработчика и QA команды есть разные ожидания относительно готовности фичи, переданной в QA. Разработчик считал, что достаточно написать код и перекинуть фичу через забор в QA — там разберутся. Довольно взрослый и опытный, кстати, программист, но такой уж у него был внутренний порог качества. QA с этим были несогласны и требовали показать и описать им, что он проверил сам, и требовали сценарий тестирования для них. Они уже имели в прошлом проблемы с функционалом от этого разработчика и не хотели тратить своё время зря ещё раз. Кстати, они были правы — фича действительно не работала, код перед передачей в QA он не проверил.
Для решения ситуации я попросил его показать мне, что всё действительно работает (оно не работало, и ему пришлось чинить), мы проговорили с командой и с QA definition of done (делать его письменным не стали, т.к. не хотели слишком бюрократизировать процесс), ну а с этим специалистом мы вскоре расстались (к общему облегчению).
С точки зрения рабочего процесса возможные улучшения в данном случае — наличие definition of done, требования к сопровождению каждой фичи юнит и интеграционными тестами, описание тестирования, проведённого разработчиком. В одном из проектов мы замеряли уровень покрытия кода тестами во время CI и в случае, если уровень покрытия после добавления патча, падал, тесты помечались как непройденные, т.е. любой новый код мог быть добавлен только при наличии новых тестов для него.
Ещё один типичный пример конфликта, тесно связанного с организацией рабочего процесса. У нас есть продукт, команда разработки этого продукта, команда поддержки и заказчик. У заказчика возникают проблемы с продуктом, он обращается к поддержке. Поддержка анализирует проблему и понимает, что проблема в продукте, передаёт проблему продуктовой команде. У продуктовой команды горячая пора, релиз на подходе, поэтому тикет с проблемой от заказчика, затерявшийся среди остальных тикетов у разработчика, которому он назначен, висит несколько недель без внимания. Поддержка думает, что разработчик работает над проблемой заказчика. Заказчик ждёт и надеется, что над его проблемой работают. В реальности ничего пока не происходит. Через несколько недель заказчик, наконец, решает поинтересоваться прогрессом и спрашивает у поддержки, как дела. Поддержка спрашивает разработку. Разработчик вздрагивает, просматривает список тикетов и обнаруживает там тикет от заказчика. Читая тикет от заказчика он понимает, что информации для решения проблемы недостаточно, и ему нужны ещё логи и дампы. Поддержка запрашивает дополнительную информацию от заказчика. И тут заказчик понимает, что над его проблемой всё это время никто не работал. И грянет гром …
В этой ситуации решение самого конфликта довольно очевидно и линейно (починить продукт, обновить документацию и тесты, умиротворить заказчика, выпустить хотфикс, и т.д). Важно проанализировать рабочий процесс и понять, кто несёт ответственность за организацию взаимодействия между двумя командами, почему такая ситуация вообще стала возможной. Понятно, что нужно починить в процессе — кто-то должен мониторить общую картину без напоминаний от заказчиков, проактивно. Тикеты от заказчика должны выделяться среди остальных тикетов у разработчиков. Поддержка должна видеть, работает ли разработка над её тикетами в настоящий момент, если нет — когда сможет начать работать, когда можно ожидать результата. Поддержка и разработка должны периодически общаться и обсуждать статус тикетов, сбор нужной для отладки информации должен быть максимально автоматизирован, и т.д.
Как на войне противник старается ударить в стык между двумя подразделениями, так и в работе самым тонким и уязвимым местом обычно оказывается взаимодействие между командами. Если менеджеры поддержки и разработки достаточно взрослые, они смогут починить процесс самостоятельно, если нет — процесс будет продолжать генерировать конфликты и проблемы, пока не вмешается менеджер, который сможет починить ситуацию.
Другой характерный пример, который я встречал неоднократно в разных компаниях — ситуация, в которой продукт пишется одной командой, автоматические интеграционные тесты для него — второй командой, инфраструктура, на которой это всё эксплуатируется, сопровождается третьей командой. Проблемы при прогонах тестов возникают постоянно, и причиной проблем в них может быть как продукт, так и тесты и инфраструктура. Проблематичным обычно бывает договориться, кто должен производить первичный анализ проблем, файлить баги, парсить логи продукта, тестов и инфраструктуры, и т.д. Конфликты здесь весьма часты, и, в то же время, единообразны. В случае высокого эмоционального накала участники часто сваливаются в детскую позицию и начинаются обсуждения из серии: “почему я должен с этим ковыряться”, “у них чаще ломается”, и т.д.
С точки зрения рабочего процесса конкретные шаги для решения вопроса зависят от состава команд, вида тестов и продукта, и т.д. В одном из проектов мы ввели периодические дежурства, при которых команды следили за тестами по очереди, по неделе. В другом первичный анализ всегда проводили разработчики тестов, но при этом анализ был весьма базовый и продукт достаточно стабилен, так что это неплохо работало. Главное — обеспечить прозрачность процесса, ясность ожиданий для всех сторон и ощущение справедливости ситуации для всех.
Является ли вообще конфликт в организации проблемой, плохой ли это признак, что в вашей команде часто (или просто периодически) случаются конфликты? В целом, нет, ведь если происходит рост, развитие, есть какая-то динамика, то возникают вопросы, которые никогда не решались раньше, при их решении могут возникать конфликты. Это индикатор того, что на какие-то области нужно обратить внимание, что есть области для улучшений. Плохо, если конфликты возникают очень часто, решаются трудно или долго. Это, скорее всего, признак недостаточно отлаженных рабочих процессов и недостаточной взрослости команды.