Тренинг формирования команды как метод повышения эффективности организации

Для большинства российских компаний актуальны задачи повышения эффективности. Перечислим некоторые из них:

  • Эффективность системы управления на уровне стратегии и ежедневной практики.
  • Усиление неформального авторитета менеджмента, основанного на признании членами организации его компетентности, полезности и результативности.
  • Развитие интеллектуальной составляющей бизнеса, создающей максимальную стоимость каждого продукта и операции для внешнего и внутреннего клиента.
  • Развитие личной ответственности каждого сотрудника за бизнес-результат всей Компании.
  • Формирование оптимального стиля взаимодействия всех сотрудников организации как внутри, так и между функциональными единицами, позволяющего оперативно решать задачи функционирования бизнеса как единого организма.

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

Развитие командного стиля работы в Компании возможно при соблюдении 3 условий:

      • формируется управленческая команда
      • развиваются функциональные команды
      • развивается межфункциональное взаимодействие (уровень всей организации, т.е. метакоманды).

Однако, начиная процесс развития команд в организации, полезно точно определить «Что такое профессиональная команда, работающая в бизнесе?». «Чем она отличается от рабочей группы отдела, подразделения, состава топ - менеджеров?»

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

Встречающиеся «стереотипы» и заблуждения

Как это реализуется в профессиональной команде на самом деле

Что необходимо сделать

В команде всем комфортно, всегда царит дружеская приятная обстановка

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

Сформировать у сотрудников готовность к изменениям, способность принять дискомфорт как атрибут развития. Такая готовность к новым «вызовам» во многом основывается на доверии к своим коллегам, прежде всего Лидерам.

В команде не бывает конфликтов

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

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

В команде всегда высокая сплоченность

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

Научить персонал ориентироваться на задачу как на «Солнце» профессиональной команды. Сделать правило своевременного достижения цели корпоративным законом. Создать неуемное желание новых достижений. Осознать и сформулировать единую Философию. Изжить «двойные стандарты», подрывающие уважение и доверие друг к другу.

Лидеры - это те, кого считают «своими» в команде

Лидер - это тот, кто наиболее соответствует Философии Компании, является примером для всех членов команды и отличается своей целеустремленностью, последовательностью, инициативой, ответственностью и результативностью

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

В команде всегда выслушивают и учитывают мнение всех

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

Определить процедуры принятия решения для различных вариантов задач. Сформировать доверие к лидерам - руководителям. Научить лидеров принимать решения по процедуре, наиболее подходящей к условиям задачи, а не их личным предпочтениям.

В команде решения принимают большинством

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

Научить персонал активно участвовать в процессе принятия решения (создать процедуры обсуждений, вовлечь персонал в процесс выработки решений), а принятые решения воспринимать как данность, как руководство к действию. Научить персонал навыкам «неформального» принятия мнений своих лидеров.

В команде превалирует коллективная ответственность

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

Сформировать у персонала навык эффективного планирования процесса, формирования структуры, учитывающей индивидуальные особенности состава, создания процедур. Но самое главное для России - научить соответствовать взятым на себя обязательствам.

Лидеров назначают или выбирают

Лидеры появляются, прежде всего, сами, как наиболее целеустремленные, ответственные и инициативные участники Команды, которым все остальные доверяют право принимать решения, в том числе и непопулярные. Административный ресурс (назначение) передается лидерам как признание их авторитета менеджментом Компании.

Формировать кадровый резерв менеджмента из людей - «победителей», обладающих страстью «жить», соответствующих Корпоративной Философии, отличающихся высочайшей критичностью по отношению к себе, ответственностью и результативностью.

Для команды наиболее важно сохранить целостность, сохранить состав

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

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

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

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

Формирование профессиональной команды - это путь, полный возможностей для проявления лидерами, ориентированными на достижение самых амбициозных целей, своей управленческой воли. Необходимо поставить цель на период 1 - 3 года и спланировать процесс построения Команды организации (МЕТАКОМАНДЫ).

Сформировать команду возможно путем проведения краткосрочного курса обучения, например тренинга формирования команды

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

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

Таким образом, мы делаем 3 основных вывода:

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

Формирование эффективной команды - длительный и кропотливый процесс. Для выхода команды на уровень продуктивной работы по нашей экспертной оценке необходимо от 6 месяцев для торговой команды и от 3 лет для управленческой.

Одним из важных элементов этого процесса является «тренинг формирования команды»

Основные задачи тренинга:

1. Создать у всех участников процесса единое понимание словосочетания «профессиональная команда»

2. Сформировать систему оценки эффективности команды

3. Сформировать первичные умения командной работы:

o Развития привлекательности общей цели для каждого члена команды.

o Планирования процесса командной работы (определения перечня действий, формата результата по каждому действию, планирования и контроля времени).

o Распределения ролей в командной работе в соответствии с требованиями задачи.

o Создания и развития лидерской позиции в команде.

o Определения стандартов взаимодействия между членами команды на различных этапах решения задачи и между структурными единицами.

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

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

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

На наш взгляд, подход к теме развития командных эффектов существенно шире. Качественная программа тренинга формирования команды должна:

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

По мнению авторов, программа профессионального тренинга формирования команды должна удовлетворять следующим требованиям:

Требования к среде тренинга:

  • соответствие среде бизнеса в России, характеризующейся высокой изменчивостью, неопределенностью, агрессивностью
  • соответствие рыночной ситуации Компании
  • соответствие организационной культуре, прежде всего Философии Компании

Требования к процессу обучения:

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

Например, для управленческих команд используются задачи связанные с описанием процедур стратегического планирования и оценки потенциала управленческой команды. Для торговых команд - задачи с измеримым финансовым результатом (увеличение объема продаж в торговой точке за 3 - 4 часа промо-акции в 3-6 раз по сравнению с выручкой самого «прибыльного дня»).

Требования к ведущему:

Области компетентности:

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

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

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

Особые личные качества:

Командный игрок и лидер

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

Личная зрелость, многообразный жизненный опыт.

Требования к обеспечению:

Помещения, оборудованные площадки, техника, возможность фото - видео съемки (в методических целях и для создания командной истории).

Инвентарь для организации командных задач

Возможность оказать экстренную медицинскую помощь (для задач с физическими рисками).

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

Автор:

Максим Долгов, тренер-консультант, ГК «Институт тренинга - АРБ Про»

 

Справка о Компании

Группа Компаний «Институт Тренинга - АРБ Про» (основана в 1993 г) включает два основных направления деятельности:

  • управленческий консалтинг (стратегический менеджмент, управление персоналом, информационно-аналитические продукты)
  • бизнес-обучение (тренинги и семинары: стратегическое управление, оперативное управление, управление персоналом, эффективная система продаж, командная эффективность, личная эффективность)

Группа Компаний «Институт Тренинга - АРБ Про» работает по всей России, в странах СНГ. Член Российской Ассоциации Бизнес-Образования с 1999 г.

В числе клиентов Кока-Кола, Рено-Автофрамос, Ригли, Хайнекен, Концерн Калина, Райффайзен Банк, Евросиб, Mr. Doors и другие.

 Интернет-Университет Информационных Технологий

   http://www.INTUIT.ru

Основы менеджмента программных проектов

Лекция #2: Функциональные роли в коллективе разработчиков: версия для печати и PDA Определяются функции, выполняемые сотрудниками в ходе развития проекта и типичные для программных проектов роли разработчиков; указывается, какие роли могут совмещаться при выполнении проекта. Представлены решения обсуждаемых вопросов, предлагаемые компанией Microsoft и Центром объектно-ориентированных технологий IBM.

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

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

Обычно роль объединяет родственные функции. Также принято обозначать роли их главными функциями. Продолжая только что приведенную иллюстрацию функций, выполняемых разработчиками проекта, укажем на следующие роли: кодировщик — действующее лицо, главной функцией которого является кодирование, аналитик — тот, кто занимается анализом требований. Подобную характеристику можно дать и тестировщику. Что же касается функции отладки, то в реальных проектах она обычно подразделяется на несколько видов: отладка компонентов, которой занимаются разработчики компонентов (например, те же кодировщики) и комплексная отладка, которая может поручаться специально выделенным сотрудникам или рассматриваться в качестве задачи группы разработчиков. Часто выполняются такие работы, как отладка спецификаций, декомпозиция проекта и др. Иными словами, функция отладки обычно не рассматривается как образующая роль, а распределяется по нескольким ролям в соответствии с принятой стратегией развития проекта.

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

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

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

Функции, выполняемые разработчиками в проекте, подразделяются на организационные и производственные. Первые создают условия для выполнения проектных заданий, вторые непосредственно связаны с этими заданиями. Часто неудачи проекта возникают из-за того, что менеджер не учитывает важность выполнения организационных функций. Так, обычно проектное задание фиксирует лишь то, что нужно предъявлять заказчику в качестве результатов. С точки зрения результатов просто не требуется знать, например, как организована передача проектных материалов между разработчиками, какая процедура отчетности предусматривается, но игнорирование задач реализации информационных потоков в проекте может привести к хаосу, что в конечном итоге отразится и на результатах.

Понятно, что как состав, так и значимость ролей разработчиков и тех, кто с ними связан, различаются в зависимости от выполняемого проекта, от коллектива исполнителей, принятой технологии, от других факторов. Неоднозначность выбора ролей приводит к тому, что их список часто становится непомерно велик (иллюстрацией тому может служить первая редакция документации по Rational Unified Processing (RUP), в которой определено свыше 20 ролей; в последующих версиях документа это число сокращено до обозримого уровня [30]). Чрезмерное увеличение числа есть следствие отождествления роли и функции и, соответственно, игнорирования понятия родственности функций. В то же время, если ролей выбрано недостаточно, есть опасность, что не все нужные в проекте функции будут охвачены планированием и управлением.

Как конкретный разработчик может получать одновременно несколько ролей, так и роль может быть распределена между несколькими исполнителями. В рамках изложения, следуя соглашению об абстрактных действующих лицах (см. лекцию 1), мы вправе отождествлять роль и действующее лицо. Но это не более чем способ представления материала, направленный на разделение сущностей. Когда менеджеру в конкретных условиях руководства коллективом придется распределять роли, он неизбежно столкнется с тем, что эта задача зависит и от специфики проекта, и от контингента исполнителей. В связи с этим уместно упомянуть об одном из ее решений, которое предлагается специалистами Microsoft в качестве универсального подхода.

В модели проектной группы концепции Microsoft Solution Framework (MSF) предлагается образовывать небольшие мобильные коллективы как атомарные производственные единицы с общей ответственностью за выполняемые задания — так называемые проектные группы [44]. Такие группы строятся как многопрофильные команды, члены которых распределяют между собой ответственность и дополняют области компетентности друг друга. Группа состоит не более чем из 10 человек. Все они считаются обладающими сходным уровнем профессиональной подготовки, хотя и в разных областях индивидуальной специализации. Провозглашается равноправие членов группы и коллективная ответственность за выполняемые задания: проектная группа — команда равных. Все это позволяет сохранять внутри группы неформальные отношения.

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

Определено шесть ролевых кластеров, которые соответствующим образом структурируют проектные функции разработчиков (рис. 2.1).

Ролевые кластеры модели проектной групп MSF [44] Рис. 2.1.  Ролевые кластеры модели проектной групп MSF [44]

  • Управление продуктом (product management). Ключевая цель кластера — обеспечивать удовлетворение интересов заказчика. Для ее достижения кластер должен содержать следующие области компетенции:
    • планирование продукта,
    • планирование доходов,
    • представление интересов заказчика,
    • маркетинг.
  • Управление программой (program management). Задача — обеспечить реализацию решения в рамках ограничений проекта, что может рассматриваться как удовлетворение требований к бюджету проекта и к его результату. Области компетенции кластера:
    • управление проектом;
    • выработка архитектуры решения;
    • контроль производственного процесса;
    • административные службы.
  • Разработка (development). Первостепенной задачей кластера является построение решения в соответствии со спецификацией. Области компетенции кластера:
    • технологическое консультирование;
    • проектирование и осуществление реализации;
    • разработка приложений;
    • разработка инфраструктуры.
  • Тестирование (test). Задача кластера — одобрение выпуска продукта только после того, как все дефекты выявлены и устранены. Области компетенции кластера:
    • разработка тестов;
    • отчетность о тестах;
    • планирование тестов.
  • Удовлетворение потребителя (user experience). Цель кластера — повышение эффективности использования продукта. Области компетенции кластера: — общедоступность (возможности работы для людей с недостатками зрения, слуха и др.);
    • интернационализация (эксплуатация в иноязычных средах);
    • обеспечение технической поддержки;
    • обучение пользователей;
    • удобство эксплуатации (эргономика);
    • графический дизайн.
  • Управление выпуском (release management). Задача кластера — беспрепятственное внедрение и сопровождение продукта. Области компетенции кластера:
    • инфраструктура (infrastructure);
    • сопровождение (support);
    • бизнес-процессы (operations);
    • управление выпуском готового продукта (commercial release management).

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

Если обратиться к менеджерским задачам руководства коллективом в проекте, то оказывается, что схема MSF мало что регламентирует. Говорится лишь о том, какие должны быть группы, но вопросы их формирования оставлены без ответа. Этого и следовало ожидать, имея в виду постулат невозможности формализовать руководство. В то же время, сама схема ограничивает действия менеджера. В подтверждение этому приведем один пример из опыта автора этих строк. При работе с очень квалифицированной программистской группой был замечен явный рост продуктивности ее членов, когда на собраниях присутствовала весьма привлекательная лаборантка, о профессионализме и компетентности которой не могло быть и речи. Единственное объяснение тому — повышение духа состязательности в коллективе. Вместе с тем по логике MSF для такой работницы просто нет места в проектной группе. Как учитывать и использовать подобные ситуации? Единственный совет, который можно здесь дать, — не очень полагаться на формализованные схемы организации и быть как можно более наблюдательным.

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

Мы придерживаемся ролевой структуры проекта, которая предложена Центром объектно-ориентированной технологии компании IBM [46]. Эта структура включает достаточно полный перечень типичных ролей, согласованный со многими реальными дисциплинами развития программных проектов. В то же время она представляет роли разработчиков в организационном контексте, т.е. рассматривает не только разработчиков, но и тех, кто, не участвуя в проекте в качестве исполнителей, оказывает влияние на постановку задач проекта, на выделение ресурсов и обеспечение осуществимости развития работ. В представленном перечне характеристика каждой роли, по сути, задает круг родственных организационных и производственных функций, которые объединяются с целью определить роль.

  • Заказчик (Customer) — реально существующий (в организации, которой подчинена команда, или вне ее) инициатор разработки или кто-либо иной, уполномоченный принимать результаты (как текущие, так и окончательные) разработки.
  • Планировщик ресурсов (Planner) — выдвигает и координирует требования к проектам в организации, осуществляющей данную разработку, а также развивает и направляет план выполнения проекта с точки зрения организации.
  • Менеджер проекта (Project Manager) — отвечает за развитие проекта в целом, гарантирует, что распределение заданий и ресурсов позволяет выполнить проект, что работы и предъявление результатов идут по графику, что результаты соответствуют требованиям. В рамках этих функций менеджер проекта взаимодействует с заказчиком и планировщиком ресурсов.
  • Руководитель команды (Team Leader) — производит техническое руководство командой в процессе выполнения проекта. Для больших проектов возможно привлечение нескольких руководителей подкоманд, отвечающих за решение частных задач.
  • Архитектор (Architect) — отвечает за проектирование архитектуры системы, согласовывает развитие работ, связанных с проектом.
  • Проектировщик подсистемы (Designer) — отвечает за проектирование подсистемы или категории классов, определяет реализацию и интерфейсы с другими подсистемами.
  • Эксперт предметной области (Domain Expert) — отвечает за изучение сферы приложения, поддерживает направленность проекта на решение задач данной области.
  • Разработчик (Developer) — реализует проектируемые компоненты, владеет и создает специфичные классы и методы, осуществляет кодирование и автономное тестирование, строит продукт. Это широкое понятие, которое может подразделяться на специальные роли (например, разработчик классов). В зависимости от сложности проекта команда может включать различное число разработчиков.
  • Разработчик информационной поддержки (Information Developer) — создает документацию, сопровождающую продукт, когда выпускается версия. Включаемые в нее инсталляционные материалы, равно как ссылочные и учебные, а также материалы помощи предоставляются на бумажных и машинных носителях. Для сложных проектов возможно распределение этих задач между несколькими разработчиками информационной поддержки.
  • Специалист по пользовательскому интерфейсу (Human Factors Engineer) — отвечает за удобство применения системы. Работает с заказчиком, чтобы удостовериться, что пользовательский интерфейс удовлетворяет требованиям.
  • Тестировщик (Tester) — проверяет функциональность, качество и эффективность продукта. Строит и исполняет тесты для каждой фазы развития проекта.
  • Библиотекарь (Librarian) — отвечает за создание и ведение общей библиотеки проекта, которая содержит все проектные рабочие продукты, а также за соответствие рабочих продуктов стандартам.

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

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

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

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

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

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

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

  1. Не следует допускать совмещения ролей, которые имеют конфликтные или противоречивые интересы. Если такое совмещение все-таки используется, то необходимо предусматривать механизмы, которые будут демпфировать противоречия.
  2. Представление ролей с конфликтными интересами различным людям обеспечивает равновесие противоречащих точек зрения.
  3. Прибегать к совмещению ролей для участников проекта, основной ролью которых является разработка, означает заведомое увеличение сроков выполнения соответствующих работ. По этой причине для них допустимы лишь такие совмещения, которые действительно необходимы в данный момент развития проекта (например, в некоторых авральных ситуациях) и которые не требуют постоянной деятельности в течение длительного срока.
  4. Если работнику поручается несколько ролей, то он всегда должен знать, какую из них он выполняет в данный момент.

В большинстве случаев заказчик и планировщик ресурсов являются действительно внешними по отношению к проекту действующими лицами, а потому совмещение этих ролей с другими — нечто экзотическое. Тем не менее роль заказчика как члена коллектива разработчиков, аккумулирующего точки зрения всех инициаторов работ, весьма полезна. В частности, подход экстремального программирования считает это обязательным, чтобы развитие проекта всегда гарантированно было направлено в сторону, нужную пользователям [3]. Поскольку в этом подходе ролевая дифференциация работников отходит на второй план, его апологеты не выделяют специально роли эксперта предметной области. Скорее всего, они считают, что его функции должны выполнять заказчик, который составляет тесты для проверки системы в целом (по крайней мере специфицирует их), и остальные разработчики группы, которые по мере уяснения актуальных пользовательских потребностей поймут, как их воплотить в коде. Но задачи эксперта предметной области иные: он должен понимать структуру пользовательской деятельности, чтобы отвечать на вопросы об узких местах этой деятельности, о критериях актуальности принимаемых решений, о содержательных формах, в которых предоставляемые средства должны преподноситься пользователям. Даже если не брать в расчет перегрузку роли заказчика экспертными функциями, понятно, что предположение о включении заказчика в команду, выполняющую проект, представляется скорее исключением, нежели правилом. Уже из этого примера видно, насколько размыты границы между функциями разных ролей, а значит, и совмещения ролей в команде. Точное определение ролей, их разграничения и совмещения — область специфики конкретных проектов. Тем не менее уместно сформулировать рекомендации, основанные на опыте успешного и неудачного менеджмента программных проектов.

Менеджер проекта по своему назначению является выделенным в команде. Он берет на себя взаимодействие с заказчиком и планировщиком ресурсов, с одной стороны, а с другой — распределяет работы среди членов команды. Последнее означает, что он должен обладать полной информацией о декомпозиции проекта. Как следствие, совмещение его роли с ролью архитектора проекта является весьма желательным, а потому довольно частым. Единственным условием для такого совмещения является требование четко знать, когда и чьи функции выполняет данное действующее лицо (см. общий для всех совмещений принцип 4).

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

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

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

  • Критерии качества для проектировщика подсистемы лежат в области использования, он должен стремиться к постановке задания, максимально полно удовлетворяющего потребности использования, тогда как для руководителя команды желательно оградить команду от излишнего внешнего влияния, в том числе от влияния пользовательских потребностей (см. принцип 1).
  • Руководитель команды должен выдавать задания исходя из системы реализационных понятий, которая принципиально отличается от системы понятий подсистемы в целом, соответствующей уровню использования. Этот уровень отслеживается проектировщиком.
  • Разделение ролей проектировщика и руководителя способствует равновесию точек зрения пользователя и разработчика подсистемы (см. принцип 2).

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

По тем же причинам не допускается совмещение ролей менеджера и разработчика. Здесь запрет более жесткий, поскольку контрольные функции менеджера несовместимы с исполнительскими задачами разработчика. Даже в тех случаях, когда у менеджера остается свободное время после выполнения своих прямых обязанностей, ему не следует «помогать» разработчикам. Лучше занять себя другим делом, в частности выступить в роли разработчика другого проекта.

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

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

Редко бывает эффективным совмещение ролей специалиста по интерфейсу и эксперта предметной области. Причиной тому — разный угол зрения, под которым рассматривается система. Для эксперта система представляется прежде всего структурированным набором функций, который обеспечивает поддержку пользовательской деятельности, а способ управления активизацией этих функций вторичен. Как следствие, возможно игнорирование таких аспектов интерфейса, как совместимость с другими системами, учет сложившихся стандартов и т.п. Эффективность обсуждаемого совмещения ролей возможна, если в проекте необходимость исследования интерфейсных вопросов не очень высока, а эксперт предметной области обладает достаточной квалификацией в организации интерфейсов. Как всегда, здесь обязательно следование четвертому принципу регламента для совмещений: четкое разделение того, в какой роли выступает работник в данный момент.

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

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

Но как обеспечить «независимое» тестирование? Весьма разумный метод — априорное тестирование, т.е. создание тестов до, а не после кодирования модуля. Это одно из требований экстремального программирования, которое вполне может быть распространено на другие методики ведения проектов. В статье [32] вводится специальный термин для обозначения программистов, которые привыкли писать тесты до разработки: инфицированные тестами, и показывается, что эта «болезнь» только ускоряет процесс в целом. В книге [4] Бек показывает, как можно выполнять программные проекты с помощью априорного тестирования, какие преимущества это дает для процесса разработки и для его результата.

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

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

В цепочке ролей «заказчик, эксперт предметной области, тестировщик» нет противоречивых интересов, а потому, с точностью до того, что заказчик обычно является внешним по отношению к проекту лицом, здесь совмещение ролей оправданно. Что же касается экстремального программирования, провозгласившего включение заказчика в группу разработчиков как принцип, то при описании подхода явно указывается, что это означает лишь предоставление представителя заказчика команде. Иными словами, имеется в виду эксперт предметной области с дополнительными, разумеется частичными, полномочиями заказчика. Продуктивность данной схемы вполне понятна. Более того, ее можно считать проверенной временем: по этой схеме в советские времена работали все программистские коллективы, выполнявшие проекты военного ведомства. Явное участие представителя заказчика в ключевых моментах разработок приносило хорошие плоды, но только при одном условии: если военпред (как тогда называли представителя заказчика) не сводил свою работу лишь к выполнению контрольно-надзирательных функций. Впрочем, его карьерная заинтересованность в успехе проектов чаще способствовала выработке правильных отношений с коллективом, чем мешала работе (что также было нередко, о чем не следует забывать сторонникам экстремального программирования).

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

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

В качестве итога обсуждения совместимости ролей для действующих лиц проекта в табл.2.1 приводятся краткие характеристики совмещения ролей, которые можно рассматривать как рекомендации для менеджмента. Разумеется, нельзя абсолютизировать эти характеристики для любых проектов. Не стоит жестко фиксировать распределение ролей и в одном проекте. Более того, распределение ролей можно рассматривать в качестве одного из инструментов, с помощью которого менеджер может руководить коллективом. Если этим инструментом пользоваться умело, то удается добиться наиболее эффективного разделения труда, соответствующего индивидуальным особенностям участников проекта.

Таблица 2.1. Роли действующих лиц проекта и совмещение ролей

Роли

Характеристика совмещения ролей

Менеджер и архитектор

Желательно

Менеджер и руководитель команды

Противоречиво

Руководитель команды и архитектор

Возможно

Руководитель команды и проектировщик подсистемы

Нежелательно

Менеджер и разработчик

Не допускается

Для различных разработчиков

Эффективно с ограничениями(обычное дело)

Создание документации (все сотрудники)

Успешно распределяется

Специалист по интерфейсу и менеджер

Разумно

Эксперт предметной области и менеджер

Зачастую разумно

Специалист по интерфейсу и эксперт предметной области

Редко бывает эффективно

Эксперт предметной области и разработчик

Бывает полезно

Специалист по интерфейсу и разработчик

Часто полезно

Библиотекарь и один из разработчиков

Допустимо

Тестировщики и другие члены команды

Перекрестно

Эксперт предметной области, тестировщик

Оправданно

  1)   Термин «инициаторы работ» — перевод английского слова «stakeholdes». В литературе можно встретить и другие его переводы: организаторы работ, заинтересованные лица и даже акционеры (последнее уводит далеко в сторону). Некоторые прибегают к транслитерации и говорят о стейкхолдерах проекта. Мы предпочитаем назыать всех тех, чьи интересы в той или иной мере затрагивают проект и его результаты, инициаторами работ. Наряду с этим мы употребляем термин «заинтересованные лица», обозначая им всех тех, кто проявляет интерес к проекту и от действия которых может зависеть его развитие, пусть даже косвенно. Таким образом, инициаторы работ включают в себя заинтересованных лиц (в частности, разработчиков проекта), но обратное неверно. К примеру, акционер проекта является инициатором работ, так как его интересы судьба проекта, безусловно, затрагивает. Но полагаясь на своего брокера, он может позволить себе даже не думать о проекте, т.е. не быть его заинтересованным лицом (в нашей терминалогии).

Рейтинги

Рейтинг эффективности управленческих команд

Рейтинг эффективности управленческих команд

 

 

ТОП-50 наиболее эффективных управленческих команд

С самого начала работы Ассоциации Менеджеров одним из ключевых направлений деятельности организации является создание рейтингов профессиональной репутации российских топ-менеджеров. Развитие этих рейтингов шло от создания общих рейтингов лучших топ-менеджеров к рейтингам менеджеров-функционалов, отвечающих в компаниях за конкретные направления (маркетинг, финансы, управление персоналом, информационные технологии). Следующим логичным шагом на пути эволюции рейтингов стала разработка рейтинга управленческих команд, объединяющих первых и вторых. Первый подобный рейтинг был представлен в 2003 году. Сегодня, пересмотрев подходы к созданию данного Рейтинга, Ассоциация Менеджеров завершила работу по созданию принципиально нового Рейтинга - Рейтинга ТОП-50 наиболее эффективных управленческих команд страны. Данный Рейтинг не базируется на результатах каких-либо других рейтингов и представляет собой отдельный полноценный продукт. В рамках данного проекта партнером Ассоциации Менеджеров выступил журнал «Секрет фирмы», экспертную поддержку оказало «Агентство контакт». Целью данного проекта является выработка стандарта и ключевых факторов успеха управленческой команды посредством определения лучших управленческих команд России.

МЕТОДОЛОГИЯ СОСТАВЛЕНИЯ РЕЙТИНГА

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

Главные аспекты в работе эффективной управленческой команды:

  • Цели и задачи работы управленческой команды, планирование и выбор методов достижения
  • Распределение ролей среди участников управленческой команды, ответственности и обязанностей
  • Система взаимодействия участников управленческой команды, принципы работы, межличностные коммуникации
  • Роль руководителя управленческой команды

КАНДИДАТЫ РЕЙТИНГА

В рамках рейтинга ТОП-50 оценивались управленческие команды ведущих российских компаний. Управленческая команда всегда ассоциируется с компанией, на благо которой она работает. В этом смысле очевидна взаимозависимость показателей эффективности управленческой команды и эффективности компании в целом. Тем не менее, при составлении анкеты, акцент был сделан на максимально возможном логическом разделении этих 2-х факторов. Основные функциональные составляющие управленческой команды:

  • Руководитель управленческой команды - общее управление, координация действий членов команды
  • Финансовый и экономический блок
  • Производственный и/или операционный блок
  • Коммерческий и маркетинговый блок
  • Блок организационного развития и управления персоналом
  • Блок ИТ-обеспечения

КРИТЕРИИ ОЦЕНКИ ЭФФЕКТИВНОСТИ УПРАВЛЕНЧЕСКИХ КОМАНД

Критерий 1 - Понимание и следование членами команды общим принципам командной работы Критерий 2 - Постановка членами команды четких и амбициозных задач, соответствующих целям всей компании. Критерий 3 - Согласованность действий членов команды Критерий 4 - Роль руководителя в управленческой команде и стиль руководства (интегральная оценка):

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

Критерий 5 – Распределение ролей, ответственности и обязанностей среди участников управленческой команды (интегральная оценка):

  • Четко определены ролевые статусы членов команды
  • Соответствие структуры команды и распределения ролей целям и задачам команды, принципам командного взаимодействия
  • Активное применение методов группового принятия решений

Критерий 6 – Процессы и процедуры (интегральная оценка):

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

Критерий 7 – Взаимоотношения между членами команды (интегральная оценка):

  • Члены управленческой команды эффективно сотрудничают друг с другом
  • В управленческой команде применяется система эффективного управления конфликтными ситуациями

ЭКСПЕРТЫ РЕЙТИНГА

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

  • руководители и директора функциональных направлений ведущих российских компаний (включая и те, которые попали в список кандидатов)
  • Руководители и консультанты рекрутинговых компаний
  • Руководители и консультанты консалтинговых и аудиторских компаний
  • Представители средств массовой информации.

РЕЗУЛЬТАТЫ РЕЙТИНГА

Успех любой компании зависит, прежде всего, от профессионального и эффективного управления. А это возможно только при наличии у компании сильной и сплоченной управленческой команды. Управление производственными процессами, конкурентоспособность, определение приоритетных направлений, перспектив и планов развития компании, внедрение новых технологий - решение всех этих вопросов напрямую зависит от слаженной работы управленческой команды. Нынешняя ситуация отражает тот факт, что большинство российских компаний сталкиваются с трудностями при формировании состава управленческой команды. Таким образом, поиск управленческих кадров является, по мнению лидеров бизнеса, одной из наиболее актуальных задач для большинства российских компаний. Исследование Ассоциации Менеджеров, направленное на изучение командной работы менеджеров-руководителей российских компаний, ставило перед собой цель определить лучшие управленческие команды российских компаний, специализирующихся в разных отраслях. По результатам экспертной работы первое место в рейтинге ТОП-50 наиболее эффективных управленческих команд заняла инвестиционная компания Тройка Диалог. Второе и третье место поделили соответственно «Магнитка» и финансовая корпорация Уралсиб. Общая же десятка лидеров Рейтинга ТОП-50 выглядит следующим образом:

  • ИК Тройка Диалог
  • Магнитогорский металлургический комбинат
  • ФК Уралсиб
  • Мобильные Телесистемы
  • Северсталь
  • Русский алюминий
  • Газпром
  • СУАЛ-Холдинг
  • Связьинвест
  • ЕЭС России

Если посмотреть, в общем, на Рейтинг ТОП-50, можно сказать, что в число лучших вошли управленческие команды компаний из различных отраслей; значительная их часть - лидеры в своей отрасли. Отраслевой анализ результатов дает весьма позитивный для экономики страны результат - наибольшее число эффективных управленческих команд сформировано в финансовом и потребительском секторах (13 и 8 компаний соответственно на сектор). Радует то, что отрасли металлургии и нефтегазового сектора уже не являются неоспоримыми лидерами в большинстве аспектов развития (7 и 5 компаний соответственно). Этот факт еще раз отражает тенденцию того, что наша экономика постепенно перестает быть однополярной, появляются новые отрасли, которые в ближайшее время, возможно, станут локомотивами развития. Общее распределение по отраслям выглядит следующим образом:

Отрасль

Число компаний - участников Рейтинга ТОП-50

Финансовый сектор

13

Потребительский сектор

8

Металлургия

7

Нефтегазовый сектор

5

Телеком

5

Консалтинг/Профессиональные услуги

3

Машиностроение

2

Торговля

2

Транспорт

2

Лесная и лесоперерабатывающий сектор

1

Химическая промышленность

1

Электроэнергетика

1

Бросается в глаза разрыв между баллами, которые набрали компании, занявшие первую и последнюю строки рейтинга - ровно «в два раза». Заметно присутствие в Рейтинге ТОП-50 компаний с участием международного капитала. А теперь, сам Рейтинг ТОП-50 наиболее эффективных управленческих команд страны.

50 НАИБОЛЕЕ ЭФФЕКТИВНЫХ УПРАВЛЕНЧЕСКИХ КОМАНД

Рейтинг

Компания

Отрасль

Регион

Балл

1

ИК Тройка Диалог

Инвестиционные компании

Москва

829

2

Магнитогорский металлургический комбинат

Черная металлургия

Челябинская обл.

788

3

ФК Уралсиб

Инвестиционные компании

Москва

768

4

Мобильные Телесистемы

Операторы сотовой связи

Москва

766

5

Северсталь

Черная металлургия

Вологодская обл.

764

6

Русский Алюминий

Цветная металлургия

Москва

756

7

Газпром

Нефтегазовая промышленность

Москва

752

8

СУАЛ-Холдинг

Цветная металлургия

Москва

752

9

Связьинвест

Операторы сотовой связи

Москва

746

10

ЕЭС России

Электроэнергетика

Москва

743

11

Татнефть

Нефтегазовая промышленность

Республика Татарстан

742

12

Альфа-Банк

Коммерческие банки

Москва

738

13

ТНК-ВР Менеджмент

Нефтегазовая промышленность

Москва

737

14

Сбербанк России

Коммерческие банки

Москва

731

15

ВымпелКом

Операторы сотовой связи

Москва

711

16

Российские железные дороги

Общий транспорт

Москва

694

17

Энергомашэкспорт-Силовые машины

Общее машиностроение

Москва

694

18

Новолипецкий металлургический комбинат

Черная металлургия

Липецкая область

658

19

НК ЛУКОЙЛ

Нефтегазовая промышленность

Москва

658

20

КБ Газпромбанк

Коммерческие банки

Москва

656

21

КБ МДМ-Банк

Коммерческие банки

Москва

643

22

Внешторгбанк

Коммерческие банки

Москва

643

23

Аэрофлот – российские авиалинии

Авиационный транспорт

Москва

604

24

Procter&Gamble

Торговля

Москва

598

25

АФК Система

Холдинговая компания

Москва

591

26

Ernst&Young Представительство

Аудиторско-консалтинговые компании

Москва

589

27

Инвестиционная группа Ренессанс Капитал

Инвестиционные компании

Москва

584

28

РОСНО

Страховые компании

Москва

554

29

Заволжский моторный завод

Автомобилестроение

Нижегородская область

536

30

Данон Индустрия

Мясо-молочная и жировая промышленность

Москва

530

31

Вимм-Билль-Данн

Мясо-молочная и жировая промышленность

Москва

523

32

Перекресток

Торговля

Москва

520

33

МегаФон

Операторы сотовой связи

Москва

518

34

Нижнекамскнефтехим

Химическая промышленность

Республика Татарстан

518

35

Сеть магазинов Пятерочка

Торговля

Санкт-Петербург

512

36

Ростелеком

Операторы фиксированной связи

Москва

504

37

Пивоваренная компания Балтика

Пивоваренная промышленность

Санкт-Петербург

503

38

Красный Октябрь Московская кондитерская фабрика

Кондитерская, бакалейная и хлебо-булочная промышленность

Москва

502

39

Бритиш Американ Тобакко Россия

Табачная промышленность

Москва

502

40

Сургутгазпром

Нефтегазовая промышленность

Тюменская обл.

501

41

ИФД КапиталЪ

Инвестиционные компании

Москва

501

42

Ингосстрах

Страховые компании

Москва

500

43

Карельский окатыш

Черная металлургия

Республика Карелия

500

44

Oracle CIS

IT-обеспечение

Москва

500

45

ИК АТОН

Инвестиционные компании

Москва

499

46

PriceWaterHouse Представительство

Аудиторско-консалтинговые компании

Москва

489

47

Филип Моррис сэйлз энд маркетинг

Табачная промышленность

Москва

482

48

Горно-металлургический комплекс ЕвразХолдинг

Черная металлургия

Москва

461

49

Илим Палп Интерпрайз

Лесная и лесоперерабатывающая промышленность

Санкт-Петербург

455

50

Кондитерское объединение Россия

Кондитерская, бакалейная и хлебо-булочная промышленность

Самарская область

414

 

 

Создание высокоэффективных организаций посредством рабочих команд

Джозеф Г. Бойетт, Джимми Т. Бойетт Фрагменты из книги "Лучшие идеи мастеров управления"

Оглавление

Спустившись в угольные шахты Непременные условия высокой эффективности Доводы в пользу высокоэффективных организаций Переход к высокой эффективности Предсказуемые стадии развития команды Советы, приемы и методы: как достичь успеха команды Резюме

Переход к высокой эффективности

Как можно ожидать, каждый из наших гуру предлагает свое уникальное руководство по осуществлению поэтапного перехода от организации традиционного типа к высокоэффективной организации. Например, Джон Зенгер и команда из компании Zenger Miller описывают “четыре столпа архитектуры внедрения”. Чарлз Манц и Генри Симс дают “карту пути к успеху”. Сьюзен Элберс Мормен и команда, созданная Центром изучения организационной эффективности, рекомендуют “схему последовательности действий”, включающую пять шагов. А Ян Катценбах и Дуглас Смит предлагают восемь подходов, позволяющих “поднять кривую эффективности”. Какой из этих рецептов является наилучшим? Как признают Катценбах и Смит, единственного наилучшего рецепта нет. Но есть некоторые общие моменты, с которыми, по мнению всех наших гуру, приходится сталкиваться организациям, осуществляющим переход к высокой эффективности, независимо от избранных ими моделей, карт, последовательности действий или от подъема кривой. Самыми важными из этих моментов являются следующие:

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

2. Каковы будут роли и обязанности менеджеров, контролеров, руководителей и членов команды?

3. Какие новые навыки потребуются менеджерам низшего и среднего звена, руководителям команд и работникам, для того чтобы эффективно работать в организации нового типа?

И вот что наши гуру считают необходимым сказать по каждому из этих вопросов.

Типы и интеграция команд

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

Типы команд

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

1.     рабочие команды;

2.     межфункциональные команды;

3.     команды по решению проблем;

4.     команды повышения эффективности;

5.     команды, обслуживающие процесс;

6.     интегрирующие команды;

7.     управленческие команды;

8.     команды, работающие в рамках одного проекта;

9.     направляющие команды;

10.                       самоуправляемые команды;

11.                       полуавтономные команды.

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

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

2. Команды повышения эффективности (КПЭ). Такие команды дают рекомендации относительно изменений, которые следует совершить в организации, в осуществляемых ею процессах и (или) технологиях, для того, чтобы повысить качество, снизить издержки и (или) улучшить своевременность поставок продуктов и услуг. Обычно их набирают из членов одной или нескольких рабочих команд. В отличие от последних, КПЭ зачастую являются временными образованиями. Их создают для работы над определенной проблемой или конкретным проектом, а после решения проблемы или реализации проекта распускают. Команды по осуществлению проектов, по проведению аудиторских проверок, по повышению качества, оперативные группы, команды совершенствования процессов и другие подобные группы, создаваемые для решения конкретных задач, — всё это примеры КПЭ.

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

Рабочие команды и КПЭ по своей природе могут быть как функциональными, так и межфункциональными — в зависимости от типа работы, которую им надо выполнять, и от того, насколько тесной должна быть их кооперация, чтобы они могли добиться успеха. Команды, сформированные по функциональному признаку, весьма сильно походят на отделения или секции, существующие в организациях традиционного типа. Люди в таких командах сгруппированы в соответствии с их специальностями: контроль за качеством, маркетинг, производство, закупки, техника и т.д. В межфункциональных командах работники группируются по проектам или процессам, причем в состав одной команды входят люди разных специальностей. Как решить, какую команду следует создавать — функциональную или межфункциональную? Сьюзен Элберс Мормен, Сьюзен Коэн и Аллан М.Мормен-мл., соавторы книги “Designing Team-Based Organizations” и научные сотрудники Центра изучения организационной эффективности, предлагают вам ответить на следующие ключевые вопросы:

1. Какие действия необходимо предпринять и интегрировать друг с другом, чтобы поставить потребителям некую ценность?

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

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

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

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

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

Хотя в состав многих компаний, считающихся высокоэффективными, входят и функциональные, и межфункциональные команды, обычно в большинстве действительно высокоэффективных организаций доминируют межфункциональные команды. Как отмечает Гленн М.Паркер, автор книги “Cross-Functional Teams” (“Межфункциональные команды”), тому есть несколько причин:

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

2. Комплексность. Межфункциональные команды повышают способность организации решать сложные проблемы [потому что в такие команды набирают людей, обладающих широким спектром разнообразных навыков и ориентаций].

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

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

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

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

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

Рисунок 4.1 Структура традиционной организации

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

Рисунок 4.2 Структура высокоэффективной организации

Достижение интеграции команд

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

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

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

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

Роли и обязанности членов и руководителей команд

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

Роли и обязанности, выполняемые членами команд

  • Определение времени отдыха и перерывов. Члены команды самостоятельно, по своему усмотрению составляют свои рабочие графики, в том числе устанавливают время перерывов.
  • Выборы и смещение руководителей групп. Руководителей групп или избирают, или эту должность по очереди занимают члены команды. Обычно руководитель группы занимается вопросами организации, планирования, решением межличностных проблем и разрешением конфликтов, т.е. тем, что прежде делали управляющие среднего звена. Однако руководитель группы выполняет указанные функции по усмотрению членов команды. По мере того как команда берет на себя все больше ответственности, роль традиционного управляющего среднего звена изменяется до неузнаваемости (см. ниже).
  • Инициатива по ремонту машин и оборудования. Члены команды сами выполняют большую часть работ по техническому обслуживанию оборудования, на котором работают, и производят мелкий ремонт. Команда самостоятельно, не обращаясь за разрешением к руководству, заказывает крупный ремонт.
  • Распределение конкретных рабочих заданий среди членов команды. Команды вырабатывают различные методы распределения рабочих заданий. В некоторых командах разные виды работ выполняют по принципу ротации. В других командах рабочие задания распределяют в строгом соответствии с принципом старшинства — самые старшие работники имеют право выбора. Существует и такой вариант: работники договариваются друг с другом и стараются так распределить работы, чтобы каждый делал то, что ему больше нравится, не нанося вреда эффективности.
  • Обучение новых членов рабочих групп. Члены команды обеспечивают профессиональную подготовку новичков на рабочем месте.
  • Материально-техническое обеспечение производственного процесса. Руководитель группы, избранный или исполняющий эти обязанности временно, на основе ротации, зачастую осуществляет текущий контроль за использованием материалов и компонентов оборудования и отвечает за пополнение материально-технических запасов из внешних источников.
  • Табельный учет фактически отработанных каждым членом команды часов. В высокоэффективных организациях обычно не ведут централизованного учета рабочего времени. Вместо этого члены команды сами учитывают отработанные ими часы и передают свои записи руководителю, который сводит их воедино для оформления платежных ведомостей и иных целей. Манц и Симс отмечают, что на заданный одному из членов команды вопрос, не обманывают ли там людей, они получили ответ: “Кого здесь надувать? Других членов команды? Может быть, разок-другой обман и удастся, но и все. Одурачить своих товарищей по команде нельзя”1).
  • Контроль за качеством и сбор данных. На многих высокоэффективных промышленных предприятиях нет контролеров качества. Вместо внешнего контроля члены команды сами несут ответственность за качество своей продукции и за сбор статистических данных о качестве. Очень небольшой отдел контроля за качеством может время от времени проводить проверку представленных командами данных, но в основном ответственность за качество — это дело команд.
  • Подготовка бюджетов материально-технического обеспечения и оплаты труда. Манц и Симс отмечают, что возможна подготовка двух параллельных бюджетов: один составляет рабочая команда, а другой — руководство или внешний бухгалтер. Затем команды улаживают с руководством все разногласия по двум бюджетам и получают окончательный бюджет.
  • Учет продукции, произведенной за день, и оставшихся запасов. Члены команды ведут собственный производственный учет, который подлежит периодическим проверкам, проводимым внешними группами, например группой производственного планирования.
  • Разработка рекомендаций относительно изменений, которые инженеры должны внести в конструкцию оборудования, технологический процесс и продукт. Команды осуществляют собственный анализ процесса и дают руководству рекомендации относительно необходимости закупок нового оборудования, внедрения новых технологий и внесения изменений в производственные процессы и конструкцию продукта. Обычно команды пользуются широкой свободой в вопросах изменения своих методов работы и процессов и могут осуществлять такие перемены, если считают их необходимыми для повышения эффективности собственной работы.
  • Отбор и увольнение членов группы. Члены команды обычно имеют право окончательного одобрения при отборе новых членов и могут осуществлять большую часть тех дисциплинарных полномочий, которыми обладает традиционный менеджер среднего звена.
  • Оценка членов команды при решении вопросов о повышении заработков. Члены команды часто оценивают эффективность работы друг друга. Это делается раз в год или раз в полгода на собраниях равных по положению членов команды, и команда несет ответственность за результаты таких оценок. Если оплата труда зависит от квалификации или знаний (такую зависимость часто устанавливают в высокоэффективных организациях), то члены команды могут помочь в разработке и (или) применении тестов, используемых для определения уровня профессионального мастерства.
  • Прекращение производственного процесса или сборки, если качество вызывает сомнения. Как правило, если команды сталкиваются с производственными трудностями или проблемами обеспечения качества, они имеют право останавливать производство, не спрашивая на то разрешения руководства.
  • Проведение еженедельных собраний групп. Команды еженедельно проводят в рабочее время получасовые собрания, а если возникают проблемы качества или эффективности, то и более продолжительные совещания.

1) Manz C.C., Sims H.P. Business without Bosses, New York: John Wiley & Sons, 1993, p.45—46.

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

Таблица 4.2. Схема распределения ответственности команд

Обязанность

Команда

Руководство

в настоящее время

через шесть месяцев

Распределение рабочих заданий

 

X

 

Выравнивание рабочей нагрузки

 

X

 

Решение проблем

X

 

 

Проведение собраний команды

 

X

 

Заполнение табелей рабочего времени

X

 

 

Разработка графика отпусков

X

 

 

Обучение новых работников

X

 

 

Наставничество для рабочих той же специальности

X

 

 

Консультации по техническим вопросам

 

 

X

Соблюдение технических стандартов

 

 

X

Расстановка людей для выполнения будущих проектов

 

 

X

Обеспечение консультаций по вопросам служебного продвижения

 

 

X

Постановка задач команде

X

 

 

Анализ и одобрение задач команды

 

 

X

Опрос мнения потребителей об эффективности команды

 

X

 

Участие в оценке эффективности

X

 

 

Проведение оценок эффективности

 

X

 

Решение дисциплинарных проблем

 

X

 

Рекомендации относительно улучшений

X

 

 

Разработка бюджета команды

 

X

 

Источник: адаптировано по кн. Mohrman S.A., Cohen S.G., Mohrman A.M., Jr. Designing Team-Based Organizations: New Forms for Knowledge Work. San Francisco: Jossey-Bass, 1995, p.163—164.

Осуществляйте переход поэтапно

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

Стадия 1: начинающая команда (см. рис. 4.3). Межфункциональные команды созданы, но в их состав входят формальные контролеры, называемые теперь руководителями команд и назначенные руководством. Контролер-руководитель по-прежнему присутствует при повседневной деятельности команды, но от ее членов ожидают того, что они возьмут на себя часть ответственности за успехи или неудачи группы. Обязанности, прежде выполняемые менеджером-контролером, делегированы сначала некоторым, а затем и всем членам команды. От членов команды требуют, чтобы они сами решали собственные проблемы. Контролер (руководитель) команды доступен в качестве наставника, обучающего работников, как действовать в тех или иных ситуациях, но члены команды уже не должны обращаться к нему с просьбами разрешить любую возникающую проблему.

Рисунок 4.3. Начинающая команда: рабочие группы (показаны квадратами) находятся под повседневным контролем их руководителя (показан кружком в центре)

Ян Катценбах и Дуглас Смит раскрывают некоторые основные ожидания в отношении руководства на этой стадии развития команд. От внешних контролеров и руководителей команд ждут выполнения следующих обязанностей.

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

Стадия 2: команда переходного периода (см. рис. 4.4). По мере того как члены команды принимают на себя все большую ответственность за повседневное управление ее деятельностью, роль руководителя изменяется: он все больше занимается координацией и все меньше — контролем. Члены команды постепенно берут на себя выполнение конкретных задач, таких как поиск и сбор информации, укрепление согласия в группе, разрешение возникающих в ней конфликтов, принятие решений без участия менеджеров среднего звена, инициирование изменений групповой политики, процедур и методов выполнения повседневной работы. Руководитель управляет группой, координируя навыки и действия отдельных ее членов. Впрочем, он затрачивает все больше времени не на отслеживание повседневной деятельности своих людей, а на получение ресурсов для команды и на управление отношениями с внешними группами.

Рисунок 4.4. Команда переходного периода: руководитель команды не столько контролирует ее работу, сколько координирует ее

Стадия 3: опытная команда (см. рис. 4.5). К моменту, когда команда приобретает опыт, ее руководитель (которого теперь можно называть координатором) удален от группы и уже не осуществляет непосредственного контроля за повседневной деятельностью людей или даже не вникает в их работу. Члены команды берут на себя полную ответственность за решение текущих вопросов, которые, как показал опыт предшествующих стадий, они могут решать самостоятельно. Руководитель команды — он же координатор — выступает, скорее, в роли старшего управляющего, осуществляющего контроль за деятельностью нескольких команд. Такой руководитель (координатор) собирает данные о производительности, качестве, издержках, удовлетворенности клиентов и других важных показателях и информирует членов команды, как они работают. На этой стадии координатор затрачивает все больше времени на получение ресурсов для подотчетных ему команд, на осуществление посредничества между ними и другими командами, а также внешними клиентами и потребителями. Команды в основном сами управляют своей повседневной деятельностью, и их координатор может не углубляться в рутинные проблемы, с которыми сталкиваются команды, и не вникать в то, как они реагируют на эти проблемы. Члены команды принимают решения на основе согласия и несут полную ответственность за оцениваемые по важнейшим параметрам результаты деятельности и эффективность команды. Проходят дни, прежде чем бывший руководитель команды, а ныне ее координатор, мимолетно встречается с членами команды. Зачастую и этого не бывает.

Рисунок 4.5. Опытная команда: руководитель команды (или координатор) выведен из группы и просто наблюдает за ее деятельностью

Стадия 4: зрелая команда (см. рис. 4.6). На этой заключительной стадии команда несет полную ответственность за свою работу, а менеджер среднего звена для них в сущности исчезает. Большинство административных, финансовых и личных вопросов решают члены команд, которые планируют свою работу, распределяют роли и обязанности и сами преодолевают технические и прочие трудности при минимальном вмешательстве извне. Координатор команды превращается для нее в распределителя ресурсов, и команда самостоятельно определяет, когда ей необходима помощь в решении социальных или технических вопросов и каков объем этой помощи. По запросу команды координатор либо оказывает ей непосредственное содействие, либо привлекает для этого внешние источники.

Рисунок 4.6. Зрелая команда: руководитель группы исчезает; команда несет полную ответственность за свою работу

Как быстро командам следует совершать переход?

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

  • Степень взаимозависимости членов команды. Если задачи, выполняемые командой, взаимосвязаны настолько тесно, что работа одного члена команды критически важна для работы остальных, то, наверное, есть необходимость в формальном руководителе, который регулирует нерешенные вопросы, проводит собрания и гарантирует участие нужных людей в принятии важнейших решений. Когда уровень взаимозависимости невелик или она распылена, существует большая вероятность того, что члены команды самостоятельно, без вмешательства формального лидера, справятся с внутренней координацией.
  • Размеры команды. По мере увеличения размеров команды пропорционально возрастает количество взаимосвязей, решений, точек зрения, которые необходимо учитывать, и, соответственно, объем необходимого планирования. Три человека запросто могут координировать свои действия без формальной помощи. Однако, утверждают Мормен и ее коллеги, команде, состоящей из 20 человек, координировать свои действия гораздо труднее. Следовательно, чем многочисленнее команды, тем выше вероятность того, что они будут по-прежнему нуждаться в людях, играющих роль формальных руководителей.
  • Функциональное (профессиональное) разнообразие членов команд. Чем больше представителей различных профессий в команде, тем большее число точек зрения необходимо учитывать. Члены команды, выполняющие различные функции и виды работ, думают о проблемах и подходят к ним по-разному, так что интеграция людей, имеющих разные профессии, может потребовать помощи “переводчиков”, обладающих разнообразной профессиональной подготовкой и выступающих в роли руководителей.
  • Степень автономности команды. Степень автономности команды влияет на сложность обработки информации. Если команда обладает необходимыми ей ресурсами, то координация и принятие решений становятся ее внутренним делом. Если команда не автономна, т.е. связана с другими командами или лицами, сложность обработки информации возрастает неизмеримо. Иногда для управления отношениями между командами достаточно интегрирующих групп, но для управления сложными межподразделенческими функциями могут быть необходимы формальные руководители или “связные”.
  • Масштабы изменений. Любые обстоятельства, в том числе непредвиденные технические трудности, изменение стратегий организации и распределения ресурсов, неожиданности, которые приносит конкуренция, способны изменить миссию и (или) стратегию команды. Чем больше такие отклонения, тем больше обрушивающееся на команду бремя решений, которые необходимо принимать. Способность команды быстро и адекватно реагировать на подобные ситуации можно повысить, выдвинув на роль руководителя или управляющего того, кто сможет обеспечить команду критически важной для нее информацией.
  • Технические навыки и опыт. Способность команды нести ответственность за профессиональную подготовку новых людей и за наставничество над ними, а также за соблюдение технических стандартов зависит главным образом от имеющихся у членов команды опыта и набора навыков. Менее опытные команды могут нуждаться в человеке, выполняющем роль формального лидера и обеспечивающем техническое руководство.
  • Срок жизни команды. Если люди раньше не работали в самоуправляемых, достигших зрелости командах, а выполняемый командой проект краткосрочен, наверное, нет смысла вкладывать ресурсы и тратить время на то, чтобы развить команду полностью. Вместо этого она может существовать на первой стадии, имея назначенного руководителя, который проводит собрания, составляет графики, обеспечивает справедливое распределение работы и управляет отношениями с другими командами.

Высокоэффективные команды требуют новых навыков

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

Технические навыки

Поскольку члены высокоэффективных команд должны обладать знаниями и навыками, необходимыми для выполнения поставленных перед ними задач, значительное внимание следует уделять приобретению этими людьми концептуальных и практических знаний. Сьюзен Элберс Мормен и специалисты из Центра изучения организационной эффективности отмечают, что сочетание навыков в высокоэффективных командах столь же важно, как и глубина знаний в конкретных технических сферах, а может быть, и важнее. Они доказывают, что членов команды легче обучить конкретным предметам в рамках любой дисциплины, с которой они уже знакомы, чем растолковывать им начала новых дисциплин. Мормен и ее коллеги считают, что, например, “фармацевтическая группа, отвечающая за коммерциализацию нового лекарства... должна иметь в своем составе врачей, маркетологов и специалистов по клиническим исследованиям. Было бы неверным включать в состав такой команды только врачей... а команда, занимающаяся маркетингом продукта, не смогла бы компенсировать отсутствие в ее составе технического специалиста по оформлению соответствующей документации”.

Вопросы профессионально-технической подготовки являются, по существу, вопросами об объеме взаимного обучения, которое будет происходить в команде. Мормен отмечает, что в прототипах высокоэффективных рабочих команд, вроде тех, которые встречаются в промышленности, их членов обучают выполнять все или почти все необходимые виды работ. Такое обширное взаимное обучение, однако, не обязательно для всех команд, особенно если они состоят из высококвалифицированных рабочих. “Разумеется, — пишут эксперты из Центра изучения организационной эффективности, — фармацевтической компании не нужно взаимное обучение, при котором ее специалисты по маркетингу учатся на врачей (и наоборот)... Однако... поводив врачей на встречи с потребителями, их можно до некоторой степени приобщить к виґдению мира глазами маркетолога. Чтобы решать проблемы, находить компромиссы по мере обсуждения разных и несовпадающих точек зрения и устанавливать в конце концов согласие по поводу направления деятельности, необходимо, чтобы члены команды по меньшей мере представляли себе навыки, которые имеют их товарищи. Знакомство с навыками и познаниями других создает основу для делового общения людей”.

Административные навыки

От большинства высокоэффективных команд ожидают, что они возьмут на себя задачи, прежде выполняемые управляющими и контролерами (см., например, врезку “Роли и обязанности, выполняемые членами команд”, в которой перечислены стандартные контрольные функции высокоэффективной рабочей команды, действующей в промышленной компании). Для успешного выполнения этих функций членам команды необходима по меньшей мере некоторая формальная подготовка, дающая, между прочим, следующие навыки:

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

Навыки межличностного общения

Высокоэффективные организации объединяют людей разных профессий, усвоивших различные массивы знаний, по-разному рассматривающих информацию, имеющих неодинаковое мировоззрение и зачастую выступающих с разных позиций при обсуждении технических вопросов. Такие различия создают благодатную почву для взаимного непонимания и межличностных конфликтов. У большинства людей, если только они ранее не работали в высокоэффективных организациях и группах, нет необходимых навыков общения и разрешения конфликтов, и поэтому боґльшая часть команд будет нуждаться в обучении некоторым навыкам межличностного общения. Как подчеркивают почти все наши гуру, наиболее важными из них являются навык общения и навык разрешения конфликтов. Членов команд надо научить слушать других, адекватно выражать свои идеи и чувства, вырабатывать общее понимание проблем и работать ради достижения взаимоприемлемых решений. (Некоторые навыки общения, постановка вопросов и проверка интеллектуальных моделей, которым можно обучить команды для развития навыков межличностного общения, обсуждались в главе 3.)

Навыки принятия решений и разрешения проблем

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

  • стадия 1: определение приоритетности проблем;
  • стадия 2: сбор данных;
  • стадия 3: анализ данных;
  • стадия 4: генерирование альтернативных решений;
  • стадия 5: оценка решений и выбор решения, которое будет реализовано;
  • стадия 6: планирование и реализация решения;
  • стадия 7: оценка результатов.

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

  • Создание эталонов
  • Построение диаграмм “причина—следствие”
  • Метод номинальной группы
  • Гистограммы
  • Проверка отчетов
  • Анализ соотношения “затраты/выпуск”
  • Построение диаграмм рассеяния
  • Совместное конструирование
  • Развертывание функции качества
  • Построение графиков Парето
  • Управление статистическим процессом
  • Планирование экспериментов
  • Определение затрат на качество
  • Построение контрольных графиков
  • Анализ последовательности операций

Объем подготовки, необходимой высокоэффективной команде

Сколько времени необходимо уделить профессиональной подготовке? Много, говорят наши эксперты, по крайней мере по сравнению с объемом подготовки, которую дают в организациях традиционного типа. Эдвард И.Лолер III рекомендует, например, освободить минимум 5% рабочего времени для ежегодной переподготовки. В противном случае, утверждает Лолер, вы просто проявите полное равнодушие к потребностям ваших команд.

Предсказуемые стадии развития команды

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

Чарлз Манц и Генри Симс, например, предсказывают, что на самом деле эффективность работы большинства команд после начала их деятельности снижается и не вернется на уровень, на котором она была до создания команды, в течение примерно года. Реальные успехи в повышении эффективности могут наступить лишь через 18 месяцев. Несмотря на все планирование и мудрейшие наставления наших гуру, дорога к высокой эффективности оказывается весьма ухабистой. Самое лучшее, что они могут вам присоветовать, — это приготовиться к нелегкому пути. Ожидайте, говорят гуру, того, что вашим командам предстоит пройти через четыре предсказуемые стадии: формирования, преодоления шторма, возвращения к норме и, наконец, нормальной деятельности.

Стадия 1: формирование

В начале формирования команд следует ожидать периода нервического возбуждения. Люди, отобранные в команду, будут гордиться этим, но и станут бомбардировать вас вопросами: “Чего от меня ожидают?”, “Подойду ли я?”, “Что мне предстоит делать?” и “Каковы правила?”.

Стадия формирования — это стадия изучения. Наряду с возбуждением, вызванным новизной ситуации, люди ощущают неуверенность, озабоченность, замешательство. Каждый член команды оценивает про себя способности и позиции других. В книге “The Team Handbook” Питер Р.Шолтес и его коллеги из фирмы Joiner and Associates сравнивают эту стадию с поведением людей, которые стоят у реки и пробуют воду ногами, колеблясь, стоит ли купаться. Поскольку никто не знает наверняка, чтоґ должно произойти, производительность снижается. Эксперты предупреждают: не ждите от команд особых достижений на стадии формирования.

Чтобы успешно провести команду через стадию формирования, Шолтес и его коллеги предлагают сделать следующие шаги:

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

Стадия 2: преодоление шторма

Возникает впечатление, что на второй стадии дела идут все хуже и хуже. Члены группы теряют терпение из-за отсутствия успехов и стремятся работать, но не знают, как добиться результатов. Все начинают понимать, что в команде достичь результатов гораздо труднее, чем казалось вначале. Люди испытывают неудобства от совместной работы, переживают и часто злятся на самих себя и коллег по группе. Это период обвинений и защиты от них, столкновений, отсутствия единства, напряженности и враждебности. Люди начинают подозрительно относиться друг к другу. Формируются подгруппы. Между враждующими, конкурирующими за влияние фракциями происходят стычки. Команда борется за определение своей миссии, своих целей, ролей, исполняемых членами команды, и соглашений относительно того, как совместно работать. Производительность по-прежнему то падает, то возрастает. Так команда проходит через самую трудную стадию — штормовую.

Чтобы успешно преодолеть эту стадию, Шолтес предлагает:

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

Стадия 3: возвращение к норме

На этой стадии дела неожиданно начинают улучшаться. Команда вырабатывает некоторые основные правила (или нормы), регулирующие совместную работу. Люди перестают, наконец, рисоваться перед окружающими и осознают, что их сила только в единстве. Постепенно они даже начинают любить свою команду, привязываться друг к другу и все сильнее ощущать свою принадлежность к команде. Возникает чувство коллективной общности, выражаемое понятием “мы”. Люди начинают гордиться тем, что являются частями какого-то организма, и, вместо того чтобы соперничать, начинают сотрудничать. Открываются каналы общения, крепнет доверие. После штормовой стадии жизнь команды становится почти спокойной, иногда даже чересчур. Люди сосредоточивают внимание и силы на укреплении сложившихся в команде отношений и проявляют больший интерес к поддержанию мира, нежели к осязаемым, материальным результатам своей деятельности. Однако производительность труда остается невысокой.

Для того чтобы провести команду через стадию нормализации, Шолтес и его коллеги рекомендуют следующее:

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

Стадия 4: нормальная деятельность

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

Чтобы провести команду через завершающую стадию, Шолтес и группа специалистов из Joiner and Associates предлагают следующее:

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

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

Роль руководителя в формировании команды

Вид работы

Курсовая

Раздел

Менеджмент

ВУЗ

Челябинск, ЮУРГУ

Язык

Русский

Содержание

ВВЕДЕНИЕ 2 1. ОПРЕДЕЛЕНИЕ РОЛИ РУКОВОДИТЕЛЯ В ФОРМИРОВАНИИ КОМАНДЫ 4 1.1. ПОНЯТИЕ КОМАНДЫ И РАБОТА В КОМАНДЕ 4 1.2. ТИПЫ РУКОВОДИТЕЛЕЙ И ИХ ВЛИЯНИЕ НА РАБОТУ КОМАНДЫ 6 1.3. СОВРЕМЕННЫЕ ТЕНДЕНЦИИ ПОДБОРА РАБОТНИКОВ И ФОРМИРОВАНИЕ КОМАНДЫ В КОММЕРЧЕСКИХ ФИРМАХ 20 2. ПОДБОР КОМАНДЫ И ПРОБЛЕМА УПРАВЛЕНИЯ В ООО «АВТО- КОМПЛЕКЦИЯ» 27 2.1. ОПИСАНИЕ РОЛИ И ФУНКЦИЙ МЕНЕДЖЕРОВ ФИРМЫ 27 2.2. РОЛЬ ДИРЕКТОРА В ФОРМИРОВАНИИ И УПРАВЛЕНИИ КОМАНДОЙ 28 ЗАКЛЮЧЕНИЕ 34 СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ 35 Список использованной литературы 1. Авдеев В.В. Формирование команды. - М.: Сфера, 1999. - 542 с. 2. Адамс Дж. Эффективное управление распределенной работой //Консультант директора. - 2002. - N 9. - С. 29-31. 3. Базаров Т., Рыбкин И., Пыркова Т. Управленческие команды // Консультант директора, 1998, №2, с.17-24 4. Блинов А., Плохов В. Искусство формирования боеспособной команды // Управление персоналом, 2002, № 12, с.35-37 5. Борисова Е. Насколько эффективна ваша команда? //Служба кадров. - 2003. - N 4. - С. 25-31. 6. Добренькова Е.В. Психология формирования команд в бизнесе: Учеб. метод. пособие - М.: Изд-во Междунар. ун-та бизнеса и упр., 2001. - 213 c. 7. Дьякова О. Создание команды. //Консультант директора. - 1999. - N 10. - С. 25-33. 8. Завьялова Е. Роли в команде: российский вариант//Перsонал-Микс. - 2003. - N 5. - С. 99-101. 9. Иванов Ю. Подбор управленческой команды.//Управление персоналом. - 2001. - N 8.-С. 52- 55. 10. Иванов Ю. Таланту ноты не помеха. //Служба кадров. - 2001. - N 7. - С. 75-81. 11. Кларин М. Развитие команды в организации. //Консультант директора. - 2000. - N 19. - С. 23-25. 12. Колесников Ю. Краткий толковый словарь практического кадрового менеджмента// Служба кадров. - 2003. - N 8. - С. 106-109. 13. Либо М. "Команда, без которой мне не жить...": Команда в спорте и бизнесе //Перsонал- Микс. - 2002. - N 3. - С. 63-66. 14. Максвелл Д.С. Шеф и его команда: Как создать команду своей мечты/Пер. с англ. Н. Мишаковой. - СПб. и др.: Питер Ком, 1998. - (Бизнес без секретов). - 246 с. 15. Новиченкова Л. Забудьте о погоде: Внутрикоропоративные новости как инструмент формирования команды //Управление компанией. - 2003. - N 3. - С. 41-44. 16. Петрова Н. Команда в современном бизнесе//Управление компанией. - 2003. - N 10. - С. 54-57. 17. Петрова Н.П. Стратегия командного развития компании в канун 10-летия //Менеджмент в России и за рубежом. - 2003. - N 2. - С. 27-33. 18. Скриптунова Е. Как сделать команду работоспособной //Менеджмент сегодня. - 2002. - N 2. - С. 15-20. 19. Таманов В.М. Как создать профессиональную команду?: Возможности компьютерного тестирования //Справочник по управлению персоналом. - 2003. - N 9. - С. 12-27. 20. Филонович С.Р. Лидерство и практические навыки менеджера: Учеб. пособие - М.: Инфра-М, 1999. - (Модульная программа для менеджеров; Модуль 9). - 306 с.