Среди волонтёров в чате сегодня обсуждали участие в проектах, и вот одна девушка сказала, что (оказывается) тут "команда". На мой запрос поставить "+", кто готов выделять 2 часа времени в неделю на волонтёрскую деятельность из 35-ти человек отозвались 5. Это про то, где "команда", а где "чатик".
Понятно, что у команды должна быть единая цель. Менее понятно, что все должны вкладываться одинаково. Ещё менее понятны три вывода, которые формируют или убивают команду, и с которыми я живу:
- плоская структура
- подстраховка
- доверие
Вот о них и поговорим.
Плоская структура
Когда-то я работал в компании-системном интеграторе, и возможность обратиться к любому была естественной. Я был молод, и страха как-то не было совсем. Однажды я шёл по лестнице, а сверху спускался руководитель нашего подразделения, намного старше меня. Не помню, что на меня нашло, может, я спутал его с кем-то, но я сказал: "Привет!" Он ничуть не смутился и тоже сказал "Привет!".
После этого мне приходилось видеть разные отношения между начальниками и подчинёнными, вплоть до "в глаза не смотреть, вопросы не задавать". Но от образования таких подразделений командами они не становятся, можно до хрипоты кричать про команду на корпоративах. В команде люди чувствуют друг друга локтем, поэтому, если ты не можешь обратиться к любому участнику команды напрямую, с твоей командой что-то не так. Если не сказать, твоя команда больше воображаемая, чем реальная.
Мне повезло работать в такой команде, в которой работал руководитель очень высокого уровня. И дело не только в том, что любой мог обратиться к этому руководителю напрямую. Когда были задачи за этим руководителем, то он перед командой отчитывался об их исполнении, и не чувствовал себя при этом ущемлённым. Это поведение объясняется общей целью и наиболее прямым способом её достичь – выполнить все задачи на пути к цели, а также разделять с командой информацию о прогрессе.
Подстраховка
Менее очевидный случай, когда команду путают с набором классных специалистов, это когда каждый разбирается в своей области, но у них нет пересечения компетенций. Синергия в команде возникает от того, что каждый человек в отдельности имеет слабые места, и команда знает твои слабые места и подстраховывает тебя именно в этих случаях.
Например, я могу сделать презентацию, за которую в целом не стыдно, но в начале которой будет опечатка. Это классика, и внутреннее ревью презентации командой позволяет такие вещи исключить. Тут ещё нужно сказать, что команда во-первых, укажет тебе на проблему тактично (поскольку её участники хотят продолжить с тобой работать и знают, в каком виде ты принимаешь критику), а ты способен уловить критику от них (поскольку ты знаешь, что они бывают правы насчёт тебя, и поскольку ты тоже хочешь продолжать с ними работать).
Один из самых сентиментальных моментов для меня был на проекте, когда я не просил дополнительных ресурсов в остром моменте внедрения системы, но команда, зная меня и то, что в стрессовой ситуации со мной происходит, усилили проект ещё одним менеджером именно на внедрение. Это очень сильно помогло, вместо "старта на нервах" мы получили практически образцовый старт и коммуникацию с заказчиком, до которой у меня иначе не дошли бы руки.
Доверие
Синергия по работе в команде чувствуется в момент образования коллективного разума. Особенно ярко это проявляется, когда все на совещание выходят со своими представлениями и решениями, но после изложения всех позиций (то есть рассмотрения проблемы со всех сторон) вырабатывается новое решение. Если каждый доверяет только себе, то это новое коллективное решение он не способен принять и исполнить. Нужно верить, что люди более тебя компетентны в своих областях. Как это связано с профессиональным критическим мышлением, лучше не спрашивайте.
Всё по тому же проекту один из самых острых моментов произошёл в критической точке внедрения. Мы уже загрузили все данные в боевую базу, и у нас не было старой системы, к которой мы могли бы вернуться. И вот стало понятно, что так не работает. Дело было в одной настройке, которую я лично собирал с заказчиком. Когда спрашиваешь у заказчика параметры, смоделировать при этом, как будет работать система с такими настройками, крайне сложно.
С нами работал Тимур, и Тимур лучше всех разбирался в этой системе. Даже не так, никого авторитетнее Тимура по тому, как работает логика системы, не могло быть в принципе, поскольку он тестировал весь функционал, особенно тщательно наиболее сложные куски, дорабатывал постановку, тестировал снова. И в результате оказался один в таких дебрях, в которые за ним просто никто не мог последовать.
И вот у нас родилась идея, что нужно изменить настройку и пересчитать данные на основе новой настройки, за ночь. Как Тимур потом признался, он не верил, что это поможет. Была масса причин, почему это могло не сработать технически, тем более за одну ночь, и ещё масса того, что мы могли не учесть. Но утром всё заработало. Отправной точкой было доверие Тимура к выработанному командой коллективному решению, что это нужно сделать.
В итоге был праздничный ужин, на котором можно было в принципе ничего и не говорить, но то, насколько именно команда вывезла проект с (в этом месте очень сложно было подобрать слово) далёкой от совершенства системой заказной разработки, очень, очень сильно удивило не только меня, поэтому за команду мы поднимали бокалы не раз и не два. Такое случается не на каждом проекте, и я хотел бы, чтобы и вы однажды разделили это ощущение.
Комментарии