кто за что отвечает в команде
Роли в команде и стили лидер ства. Принцип работы в команде
Итак, роли в команде и их взаимодействие (Принцип работы в команде).
Роль «Мотиватор» может занимать только лидер , и лидер ская позиция может передаваться только лидер ом. Там же находится точка принятия решения.
Роль «Координатор» также закрепляется за лидер ом. В случае необходимости эта роль передается любому члену управленческой команды.
Роль «Исполнитель» выделяется только в проектной команде и то не всегда. При исполнении надо показать результат, отличающийся от других, чтобы иметь право кого-то куда-нибудь вести.
Роль «Финишер». Это тот, кто работает на завершение задачи. Чтобы контроль качества был проведен, так, что все было бы приведено в соответствие. Как правило, «Финишер» отличается от Лидера своей настойчивостью. Вообще — это вторая волевая роль в команде, но другой конфигурации. Поэтому центр принятия решения может быть распределен и представлен этими двумя ролями.
Выделение дополнительных ролей: «Контролер качества» и «Контролер времени» может оказаться достаточным, чтобы команда отработала эффективно. «Контролер качества» проверяет, соответствует или не соответствует результат установленным критериям и сообщает «Лидеру». «Лидер» вдыхает энергию на завершение проекта. Если «Контролер качества» ориентирован не только на процесс, но и на задачу, то для него важнее доделать, чем начать что-то новое. Это качество добавляет «Контролеру качества» драйв на завершение. Вцепился и, пока задача не решена, никто никуда не спешит. «Контролер качества»:
В рамках выполнения основной задачи «Лидер» чаще всего переходит либо на анализ ситуации, либо на генерацию идей.
Роль «Генератор идей» — это человек, который способен быстрее других находить варианты решений, отличающихся от других свой конструктивностью, неожиданностью, новизной.
Роль «Оценщик критик». Он видит слабые места, но важно: его задача сказать, что и каким образом можно улучшить и указать на «слабые места» в решении.
Роль «Душа команды». Без нее проектная команда может обойтись. В функциональных командах это человек, который больше ориентирован на отношения, чем на задачу. Важно, чтобы он был. Это человек, который встречает пришедших с «полей». Он обычно поддерживает разговор о:
В управленческих командах такая роль зачастую отсутствует, так как управленческая команда похожа на «банку с тараканами». Для снижения напряженности, в таких командах вводят секретаря, который занимается обеспечением и «расселением». Но, если душевных руководителей собирается больше одного, то команда превращается в дом отдыха.
Роль «Эксперт». Специалист, носитель знаний, человек, который накапливает информацию. Ему это нравится. Он может быть наставником и передавать информацию другим людям. «Эксперт» с трудом переживает варианты новых задач, где его компетенция снижена.
В функциональных командах можно выделить роль «Дипломат», который отвечает за поиск ресурсов. Чаще эта роль закрепляется за «Лидером». В управленческой команде дипломатами должны быть все. Поиск ресурсов каждый осуществляет в своей области.
HighAdvance Consulting Group оказывает услуги по работе с командами (онлайн и офлайн). За дополнительной информацией обращайтесь к ведущему эксперту Максиму Александровичу Логинову +7 921 334 67 62 | [email protected]
Роли и задачи в команде
Чтобы распределить роли в команде по участию в конкурсе муткортов, можно оттолкнуться от функций, которые нужно выполнять. Во-первых, вам понадобится организатор или координатор. Этот человек будет координировать действия всех участников, планировать и вести большую часть встреч команды, при необходимости распределять задачи, следить за их выполнением. Если менеджер может занять равную позицию по отношению к другим членам группы, то организатор выступает её лидер ом. Скорее всего, он будет тем, от кого станут ожидать решений по спорным вопросам, у него должно быть право контролировать действия других членов команды. Однако он должен уметь делегировать полномочия, не «перетягивать одеяло на себя», выполняя большую часть работы. Это не эффективно, а ещё приводит к обидам и ссорам. Организатор должен хорошо ладить с членами команды, уметь хотя бы немного управлять людьми.
Вторая особенная роль в команде – это исследователь. Вам потребуется изучить большое количество материалов, поэтому кто-то должен быть готов зарыться в законодательство и судебную практику и проанализировать большое количество профессиональной литературы. Этот человек также должен будет подобрать нужные данные для игрового дела, сформулировать позицию или несколько вариантов, набросать аргументацию на основе изученной информации. Результаты своей работы он должен будет донести до команды и обсудить с ними стратегию поведения в игре. Быть может, этот человек не обладает красивым слогом и ораторским мастерством. Однако на нём будет лежать ответственность за юридически грамотное и обоснованное изложение позиции команды в меморандуме и на очном выступлении.
Третья важная роль – это спикер. Этот человек может ярко представить позицию в устном выступлении или добавить жизни в письменный меморандум, подготовленный исследователем. Одновременно он должен быть находчивым и достаточно хорошо ориентироваться в праве, чтобы отвечать на вопросы суда без консультации с исследователем. Если в вашей команде нет ребят, которые однозначно выделяются ораторскими навыками, не переживайте раньше времени – в нашем курсе есть видеоурок, посвящённый подготовке к публичным выступлениям. Начните понемногу тренироваться как можно раньше, и вы сами с удовольствием возьмёте на себя эту самую заметную роль во всей команде. Этот опыт гарантированно пригодится вам в самом ближайшем будущем. Вы будете чувствовать себя увереннее во куче разных ситуаций: начиная с ответов на школьных уроках, заканчивая беседой с человеком, который вам давно нравится, но с которым всегда боялись заговорить.
Что ещё придётся делать в команде? Однозначно – вдохновлять участников на продолжение работы. У каждого иногда опускаются руки или появляются интересы, как будто бы более важные, чем дело команды. Кто-то должен помогать участникам держать фокус внимания на общей цели и не расслабляться, когда этого нельзя делать. Если у команды есть тренер, то он поможет в этом. Но также важно чувствовать поддержку своего товарища, который проходит через то же самое. Если кто-то выпал из общего ритма, стоит поговорить об этом и узнать причины. Вы можете подбадривать друг друга тёплыми словами или заботой – даже когда кто-то просто встанет из-за книг, чтобы налить всем чай, это поддержит командный дух. Если кто-то из участников так погрузился в работу, что забывает о своём здоровье, стоит напомнить ему о необходимости сна и качественного питания. Команда может придумать для себя небольшие общие ритуалы, которые помогут почувствовать единение.
В команде нужно принимать решения. Не всегда исследователь знает единственно верный ответ на вопрос, не всегда все согласны друг с другом, не всегда кто-то готов явно взять на себя ответственность в сложных ситуациях. Как мы говорили, эту роль может взять на себя координатор, неформальный лидер . А можно придумать правило команды, по которому принимаются сложные решения – например, с помощью голосования. Однозначно, каждый коллектив самостоятельно выбирает самый органичный для себя способ выходить из трудных и спорных ситуаций. Но здесь я хочу лишь предупредить о том, что они будут встречаться, чтобы неожиданность не стала причиной ненужного конфликта или разочарований.
Ещё одна сложная и ответственная задача – контроль сроков и качества выполняемой работы участников команды. Эта роль не всегда популярна. В идеале она предоставляется лидер у команды и тренеру. Члены команды должны быть готовы к тому, что их сверстник будет спрашивать с них результат, как руководитель. Общее дело подразумевает, что работа каждого влияет на всех, поэтому ошибки и нарушения должны быть замечены и исправлены. Иногда для этого требуется разговор с участником о его мотивации или компетентности.
Шейпер, аналитик или душа: роли людей в команде
Анна Веселко
Знаете ли вы, какую роль играет тот или иной человек в вашей команде и чему вы можете у него научиться? Помимо официальной должностной роли (функционал и обязанности, описанные в должностной инструкции), люди в группе также могут взять на себя вторую, командную роль. Разбираемся, что это такое и как использовать роли для улучшения работы команды.
Часто командные роли развиваются со временем, причем неформально, и потому могут остаться незамеченными. Однако командная роль суммирует то, как люди склонны себя вести, какой они вносят вклад и как будут взаимодействовать с командой в течение определенного периода времени. Например, один член команды может постоянно придумывать новые идеи, другой хорошо развивает контакты за пределами команды, а третий отлично воплощает идеи в практические действия. Со временем в любой команде развиваются паттерны, когда один и тот же человек постоянно берет на себя определенную роль, исполнения которой от него впоследствии начинают ожидать другие.
Другими словами, роли в команде — это попытка классифицировать типы личности, чтобы можно было идентифицировать и распознать сильные и слабые стороны членов группы
Командные роли по Белбину
Роли, ориентированные на действия
Шейпер
Их потенциальные слабости могут заключаться в том, что шейперы склонны к спорам, нетерпеливы и могут оскорблять чувства людей.
Реализатор
Минус в том, что они могут застрять на своем пути и не всегда открыты для новых идей и способов решения задач: при любом раскладе они предпочли бы придерживаться старых, испытанных и проверенных методов, чем принимать изменения и инновации.
Педант
Тем не менее часто это чрезмерно тревожные люди, которые испытывают трудности с делегированием задач. При прочих равных они лучше сделают что-то сами и будут знать, что дело наверняка будет выполнено правильно, чем поручат его кому-то другому.
Роли, ориентированные на людей
Координатор
Потенциальная слабость координаторов в том, что они могут делегировать слишком много задач из области личной ответственности и склонны к манипуляции.
Душа команды
Однако они могут быть нерешительными при принятии групповых решений, поскольку разрываются между благосостоянием отдельных членов команды и способностью команды действовать как единое целое.
Исследователь ресурсов
Исследователи ресурсов изобретательны и любопытны, изучают все доступные варианты, устанавливают контакты и обсуждают ресурсы от имени команды. Это полные энтузиазма члены команды, которые выявляют внешние заинтересованные стороны и работают с ними, чтобы помочь команде достичь своих целей. Общительны и часто бывают экстравертами, из-за чего другие часто очень восприимчивы к ним и их идеям.
С другой стороны, такие люди могут точно так же быстро потерять энтузиазм и нередко чрезмерно оптимистичны.
Роли, ориентированные на мысли
Генератор идей
Генераторы идей склонны игнорировать заданные параметры и ограничения, часто это интроверты, у которых могут быть слабо развиты коммуникативные навыки.
Аналитик-стратег
Аналитики-стратеги лучше всего умеют анализировать и оценивать идеи, которые предлагают другие (часто генераторы идей). Такие люди проницательны, объективны и тщательно взвешивают за и против каждого варианта, прежде чем принять решение.
Из-за того что они мыслят критически и очень стратегически подходят к делу, их часто воспринимают как отстраненных или бесстрастных людей.
Специалист
Что, в свою очередь, может ограничить их вклад. Также, учитывая зацикленность на практических аспектах, у специалиста могут возникнуть проблемы с реальным применением своего опыта для решения более широких задач команды.
Как работать с моделью Белбина
Обычно каждый человек выполняет основную и второстепенную роли, которые можно определить, пройдя составленный Белбином тест (его легко найти в интернете). Исходя из его результатов, команда может судить о том, насколько сбалансированны роли внутри, а также о последствиях их дублирования или отсутствия тех или иных ролей. Однако нужно иметь в виду, что любые тесты и анкеты не способны выявить стопроцентно точную «правду», хотя и могут стать полезным стартом для обсуждения командных ролей и внесения улучшений в групповую работу.
Знание модели командных ролей Белбина может помочь определить потенциальные сильные и слабые стороны вашей команды, преодолеть конфликт между коллегами, а также понять и оценить вклад каждого
Если у вас большая группа, разделите участников на команды примерно по человек. Если вы работаете с небольшой группой, не разбивайте ее. Попросите каждую команду нарисовать круг, разделить его поровну на девять разделов, по одной для каждой из командных ролей Белбина, и ввести свои имена в сегменты, соответствующие их двум верхним ролям. Затем распределите людей по ролям таким образом, чтобы были закрыты все пробелы.
Роли также стоит регулярно пересматривать, чтобы люди не слишком фиксировались: это особенно важно в небольших организациях, где сотрудникам зачастую приходится развивать «всю ролевую компетенцию», то есть способность задействовать множество разных ролей.
Помните, что при структурировании команды не следует слишком сильно полагаться на эту модель: это лишь один из многих факторов, которые важны для того, чтобы заставить команду работать с максимальной отдачей. Тем не менее простое знание модели ролей может принести в команду больше гармонии, поскольку люди узнают, что существуют разные подходы, которые важны в разных обстоятельствах, и что ни один подход не является лучшим в любой отрезок времени.
Должность — тимлид
Тимлид (aka ведущий разработчик, team leader) — один из таких «специалистов», обязанности которого многие видят по-разному. Думаю, что складываются различные представления примерно так: поработал кто-то в команде под руководством тимлида, который хорошо справлялся с задачами проектирования системы, и считает теперь, что это именно то, что должен делать тимлид; в другой же команде тимлид плохо справлялся с планированием спринтов, а с другими обязанностями более или менее, и стали считать сотрудники, что планирование — не то, чем должен заниматься тимлид.
От разработчиков, проработавших долгое время в рамках одной компании или даже одной команды чаще услышишь четкое мнение о том, кто такой тимлид и в чем заключаются его обязанности. Повидавшие же разные проекты разработчики и менеджеры постепенно приходят к пониманию, что тимлид может заниматься много чем, какая-то деятельность лучше вписывается в его роль, какая-то хуже, и уже не готовы давать точное определение роли тимлида.
Откуда же появляется разное представление о должности тимлида?
ПРИМЕЧАНИЕ. Здесь и далее я говорю про тимлида только в рамках команды разработки. Догадываюсь, что многое из рассуждений распространяется и на другие команды, во многих видах деятельности.
Мне доводилось видеть тимлидов исполняющими роли руководителя проекта, системного аналитика, тестировщика, дизайнера, проектировщика интерфейсов, архитектора, даже специалиста по поддержке пользователей.
На практике, в здоровых организациях, по моим наблюдениям, роль тимлида обычно занимают разработчики, которые более других чувствуют ответственность за судьбу разрабатываемого продукта, нередко перерастающую в гиперответственность, чем умело пользуется руководство.
ПРИМЕЧАНИЕ. Гиперответственностью я называю случай, когда человек чувствует себя ответственным за обстоятельства, влиять на которые полномочий не имеет. Я не пытаюсь вложить в это качество ни позитивного ни негативного оттенка, лишь констатирую, что в некоторых сотрудниках гиперответсвенность проявляется.
Именно за счет этой гиперответствености тимлид берет на себя ту деятельность, для которой нет выделенной должности и, постепенно, эти обязанности закрепляются за ним и, как следствие, за его должностью. В это время остальные сотрудники тоже привыкают к таким обязанностям тимлида, закрепляя в сознании именно такой набор обязанностей для любого другого тимлида.
Конечно, описанное касается не только роли тимлида, и, в той или иной степени, картина верна для любой должности в любой деятельности, но должность тимлида среди тех, что наиболее подвержены описанному эффекту.
Какая же деятельность для тимлида родная?
Что должен уметь сотрудник, какими качествами обладать для того, чтобы быть хорошим тимлидом, а только потом хорошим архитектором или аналитиком?
Самое простое определение, которое я могу дать для роли тимлида звучит так: «тимлид — интерфейс команды разработки».
Он отвечает за все, за что отвечает команда, для этого у него есть полномочия формировать команду и использовать ее членов по своему усмотрению для решения задач команды.
Если на команду возлагается ответственность за проектирование системы, то тимлид должен позаботиться о том, чтобы кто-то систему спроектировал. Команда ответственна за разработку интерфейса пользователя — тимлид определяет кто в команде это сделает. И это справедливо для любой задачи команды: ответственен за ее выполнение в глазах внешнего для команды мира тимлид.
Что же конкретно тимлид должен делать?
Разберем, что с этим нужно делать.
Лидерство
«Нужно чтобы члены команды были согласны выполнять поручения» — так себе формулировка, но изящнее сложить не удалось. Имеется в виду то, что сотрудник должен принимать задачи в работу с намерением довести их до конца. Сотрудник не отказывается брать задачи в работу просто игнорируя указания, или ссылаясь на «кривость решения», не саботирует, по-тихому занимаясь своими делами, а принимается за задачу с намерением ее выполнить. Как заставить человека захотеть выполнить задачу? Способов много, от принуждения угрозой физического насилия до обещания поездки на девкон. Это то самое качество, что я определяю «лидерством».
Компетентность команды
ПРИМЕЧАНИЕ. Довольно часто несоответствие ответственности и полномочий проявляется в том, что тимлида не включают в процесс принятия решения о приеме кандидата, или не дают возможности исключить сотрудника из состава команды по инициативе тимлида. Притом ответственность за то, чтобы команда справлялась со своими задачами с тимлида никто не снимает. Вот она — вмененная гиперответственность.
В чем же здесь проявляется профессионализм тимлида?
Как всегда скоростью и качеством решения задачи обеспечения команды компетентными сотрудниками.
Качество в данном случае тем выше, чем дешевле обходятся компании сотрудники (и не только зарплату считаем) при условии соблюдения их уровня компетенции, достаточного для решения задач. В некоторых случаях скорость в приоритете, в некоторых качество.
Среди способов пополнения кадрами вижу принципиально два подхода:
1. Брать готовых специалистов с рынка труда.
2. Воспитывать кадры самостоятельно.
Остальные, так или иначе, — комбинации этих двух. Крайний случай первого — только хантинг экспертов в требуемых областях, второго — найм только из стажерских программ. Правильного способа нет, а крайности, как и везде, часто свидетельствуют о некоем сбое. Тимлид как раз тот человек, который должен найти подходящий компромисс в конкретной ситуации с учетом ее развития.
Нельзя дать ответ на общий вопрос «как обеспечить команду достаточно компетентными специалистами», можно найти его решение только в рамках конкретного проекта на конкретном предприятии. Можно только сказать, что тимлид при разработке этого решения должен учитывать характер задач в проекте, срочность поставленных задач, значимость (impact) срыва сроков, планы и тенденции развития проекта, состояние рынка труда, доступность специалистов на рынке, сложность обучения специалистов своими силами.
Оценка работ
Чтобы не взять на себя обязательств, с которыми команда не сможет справиться, команде приходится оценивать свои ресурсы, чаще всего речь идет только о доступном рабочем времени членов команды. Ответственнен за исполнение обязательств командой разработки тимлид. Вне зависимости от того, как именно производится оценка работ в команде: каждый оценивает свою задачу, или все вместе оценивают все задачи, или все задачи оценивает кто-то один в команде, за оценку отвечать будет тимлид. Из этого следует, что тимлид имеет полномочия вмешаться в любую из оценок и изменить ее по своему усмотрению, это бывает полезно на практике, когда мнения членов команды расходятся. Более того, команда разработки, в лице тимлида, также берет на себя обязательства по исполнению планов, если ставить задачи команде в организации принято планами. В частном случае итеративных методов разработки команда (говоришь «команда» — подразумеваешь «тимлид») берет на себя ответственность за выполнение всех задач взятых в итерацию.
В современных подходах к разработке менеджмент не лезет в дела команды разработки, не говорит им как решать задачу, кому именно из состава команды решать задачу. Менеджменту важно лишь, чтобы команда выполнила задачу в оговоренный срок, а как это произойдет — неважно. Интересно, что о распределении задач между участниками умалчивает даже популярная методология Scrum, предоставляя команде «самой решать», кто за что возьмется. Когда-то я выяснял для себя, а как же происходит распределение задач на практике, и меня удовлетворил чей-то ответ, что в любой команде рано или поздно найдется лидер , который возьмет на себя инициативу по решению конфликтных ситуаций в распределении задач. Аргумент в пользу того, что распределение задач между участниками — также задача тимлида.
Как ни удивительно, оценка, планирование и распределение задач — обязанность, которая выполняется легко, если тимлид успешно справляется с другими обязанностями. Для этого в его распоряжении есть компетентные сотрудники, которые мотивированы на выполнение задач, они легко справятся с оценкой и выполнением задач. Тимлиду нужно только организовать процесс оценки и распределения задач командой, чтобы затем контролировать его. Как именно это сделать — существуют готовые решения в виде методологий разработок.
ПРИМЕЧАНИЕ. Если не знаете какую методологию выбрать в обычных условиях — берите Scrum. Потому что он прост, определен вплоть до мелочей и довольно хорошо работает даже без адаптации под команду и организацию.
Настроения в команде
Как минимум, для того, чтобы задачи решались, нужно чтобы члены команды могли общаться друг с другом без взаимного раздражения.
Казалось бы, простая задача? Далеко не так! Если между сотрудниками назрел конфликт, то во многих случаях его можно разрешить только исключением кого-то из участников из состава команды. Но на предотвращение конфликта тимлид вполне в силах повлиять, тут универсальных советов не дать, кроме одного: нельзя замалчивать конфликты, при любом инциденте нужно реагировать, как именно реагировать — зависит от конкретных обстоятельств.
Также тимлиду следует соотносить характеры членов команды, если одного зануду команда переварит, то двух, возможно, уже и нет (ничего не имею против зануд, сам зануда еще тот).
Ну а чтобы «повысить эффективность взаимодействия между членами команды» есть такая дисциплина как «тимбилдинг», я весьма скептически к ней отношусь, может сказывается тот факт, что не видел я хороших тимбилдеров в деле.
Вообще хотел обойтись без этого пункта, но совсем про него не упомянуть нельзя.
Заключение
Итак, у тимлида есть родные его должности обязанности, все они касаются того, чтобы обеспечить работоспособность команды, то есть способность выполнять поставленные перед командой задачи. Все остальное — это то, что тимлид взваливает на себя добровольно (или принудительно) дополнительно, но не всегда это плохо. Например для себя я определил правило, что тимлид, в командах разработки, обязательно должен принимать непосредственное участие в разработке, то есть писать код, разрабатывать архитектуру и т.п. Это нужно для того, чтобы понимать как устроена система изнутри, без непосредственного участия в разработке такое понимание постепенно сходит на нет. Думаю многие из разработчиков знакомы с такой ситуацией, когда оставив интенсивно разрабатываемый проект на несколько месяцев, по возвращению обнаруживаешь лишь редкие знакомые элементы в новой архитектуре системы. Однако, согласно рассуждениям выше, непосредственная разработка не входит в число родных обязанностей тимлида, в некоторых проектах она может быть необоснованна.
В реальном мире тимлид не брошен один для решения всех этих задач, ему помогают руководители, коллеги соседних департаментов. На практике часто эта помощь перерастает в принятие решений за тимлида, такие моменты должны настораживать, так как фактически его обязанности переходят к другим сотрудникам. Бороться с этим или смириться — решать вам, но обращать внимание на реальное положение дел уж точно стоит.
Интересует мнение разработчиков (в широком смысле — всех, кто работает в составе команд-разработчиков), тимлидов, линейных и проектных руководителей, согласны ли вы с такой декомпозицией роли тимлида? Есть ли у вас какие-либо замечания, дополнения?