Как распределять роли в проекте, чтобы потом не возникло вопросов «кто виноват?» и «что делать?»

Некоторое время назад обратил свое внимание на артефакт Концепция продукта (product vision) методологии разработки программного обеcпечения RUP (Rational Unified Process) и обнаружил, что отправной точкой разработки программного продукта является выявление проблемы, на решение которой нацелен продукт.

Аналогичный подход существует и в отечественной практике – так в ГОСТ 34.601-90 говорится, что на стадии Формирование требований к АС (автоматизированной системе) производится «выявление проблем, решение которых возможно средствами автоматизации».

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

Общая характеристика процесса принятия решений

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

Откуда возникает необходимость что-то решать? Обратимся к теории…

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

С чего начинается родина решение?

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

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

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

Цель

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

Задача

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

Таким образом, цель трансформирует в совокупность задач.

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

Операция и решение

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

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

После этого начинается процесс практической реализации принятого и доведенного до исполнителей решения.

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

Оценка эффективности управленческого решения

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

Только когда деятельность участников завершится, ЛПР станет ясно, та ли предпосылка (первопричина) проблемы была выбрана для решения, правильно ли была сформулирована цель операции, верно ли эта цель была разделена на задачи, в то ли время и тем ли исполнителям было поручено эти задачи решить и т.

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

В результате оценки можно прийти к следующим выводам:

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

Природа требований к программному продукту

Какая задача – такое и решение

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

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

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

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

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

Что такое требование?

В соответствии с определением, под термином автоматизированная система подразумевается совокупность персонала организации и комплекс средств автоматизации, реализующего информационную технологию выполнения действий, направленную на достижение определенной цели (см. ГОСТ 34.003-90).

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

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

Уровни требований

Если рассмотреть процесс создания автоматизированной информационной системы с точки зрения теории управления, то можно проследить аналогию с описанным выше порядком принятия управленческого решения. Как распределять роли в проекте, чтобы потом не возникло вопросов «кто виноват?» и «что делать?» Рисунок 2. Процесс создания автоматизированной системы

Потребность

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

Функция

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

Программное требование

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

Оценка эффективности программного решения

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

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

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

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

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

Кто виноват и что делать?

Очень часто в процессе сбора и анализа происходит искажение требований или же источник этих требований (проблема заинтересованного лица) не выявляется вовсе. Как распределять роли в проекте, чтобы потом не возникло вопросов «кто виноват?» и «что делать?» Рисунок 3. Искажение требований

На рисунке 3 показан пример процесса, в ходе которого возникают искажения. Когда ЛПР осознал проблему и сформулировал цель деятельности по ее устранению он доводит перечень задач (T0) до исполнителей — персонала организации. Допустим, что именно эти исполнители будут использовать разработанный позднее программный продукт, т.е. они будут являться его пользователями. Каждый из них по-своему понимает поставленную ему задачу и при формулировании требований к программному продукту исходит из своих предположений (T1).

Читайте также:  Что делать, если арендатор не заплатил и сбежал

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

В лучшем случае, в результате описанного процесса получится продукт, удовлетворяющий требованиям персонала, в худшем – только требованиям аналитика или менеджера проекта. Такой результат является следствием отсутствия понимания у группы проекта реальных потребностей будущих пользователей и заинтересованных лиц, на чью работу повлияет разработанное программное решение. В особо тяжелых случаях получившийся продукт не имеет ничего общего с ожиданиями заказчика и отражает собственные представления разработчика о том, как должны работать пользователи. Если же на начальном этапе проекта выявить проблему и все выявляемые требования пользователей, равно как и предлагаемые решения, соотносить именно с ней (см. рисунок 4), можно ожидать, что получившийся продукт будет максимально соответствовать как потребностям пользователей, так и ожиданиям заинтересованных лиц. Как распределять роли в проекте, чтобы потом не возникло вопросов «кто виноват?» и «что делать?» Рисунок 4. Соотнесение требований с проблемой Более того, понимание решаемой проблемы позволит качественно управлять масштабом проекта – например, в первую очередь реализовать ту функциональность, которая решает 80% проблемы. Как этого добиться?

Определение проблемы

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

Многие источники предлагают использовать нижеприведенную форму для формулировки определения проблемы (problem statement), которую требуется решить.

Приведенная форма учитывает и цели, которые ожидается достигнуть будущим решением.

Элемент Описание
Проблема [описание проблемы]
воздействует на [перечень сторон, на которых оказывает влияние данная проблема]
результатом чего является [описание воздействия данной проблемы на заинтересованных лиц иили бизнес-деятельность]
Выигрыш от [описание предлагаемого решения]
Может состоять в следующем: [перечень основных преимуществ, представляемых решением]

Пример

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

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

Заключение

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

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

В исследовании компании Standish Group International, результаты которого отражены в документе The CHAOS Chronicles 2013, ключевыми факторами успешности программного проекта названы:

  • вовлечение в проект заинтересованных лиц (Executive management support) — 20%;
  • привлечение конечного пользователя (User involvement) — 15%;
  • управление масштабом проекта (Optimazation) — 15%.

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

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

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

Роли в проекте

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

Но у тех, кто к этой профессии не имеет никакого отношения, часто возникает непонимание каких-то моментов.

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

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

Рассмотрим ролевую модель, которая описана в самом популярном в мире (если верить исследованиям PWC) подходе к управлению проектами – PMBOK.

Название роли Ответственность Полномочия
Руководитель проекта Достижение всех целей проекта в срок и в бюджет Зависят от организационной структуры
Заказчик проекта Утверждение требований к продуктам проекта Приемка продуктов проекта Изменение приоритетов в реализации требований к продуктам проекта
Спонсор проекта Утверждение целей проекта, сроков и бюджета Выделение ресурсов для проекта Решение вопросов, лежащих за пределами компетенции руководителя проекта
Команда проекта Реализация задач проекта в согласованные с руководителем проекта сроки Сигнализировать о проблемах, возникших при решении задач, руководителю проекта

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

Как распределять роли в проекте, чтобы потом не возникло вопросов «кто виноват?» и «что делать?»

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

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

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

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

  1. Сотрудники каких подразделений компании будут использовать программный продукт, автоматизирующий CRM?
  2. Кто из руководителей этих подразделений больше всего заинтересован в том, чтобы CRM помогла ему решать его задачи?
  3. Может ли потенциальный заказчик проекта CRM тратить на него 2-4 часа в неделю?

По данным Standish Group, на каждую $ 1000 стоимости времени людей в ИТ-проекте приходится принимать 1,5 решения. Предположим, проект внедрения CRM-системы оценен в 50 000$, из них стоимость лицензий – 10 000$, а оставшиеся 40000$ — стоимость времени людей.

По статистике Standish Group получается, что в этом проекте нужно будет принять около 60 важных решений, причем заказчик должен принять участие в 20% из этих решений. Предположим, что в среднем на решение одного вопроса заказчик тратит 4 часа.

12 важных решений по 4 часа на каждое – получается 48 часов.

Если продолжительность проекта составляет примерно полгода, то 48 часов как раз распределятся на 24 недели по 2 часа в неделю. Однако заказчик будет тратить время не только на принятие важных решений.

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

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

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

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

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

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

Читайте также:  Какие изменения могут появиться в Налоговом кодексе-2018: комментарии экспертов

В таком случае у него все-таки есть мотивация стать заказчиком.

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

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

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

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

Так кого назначить руководителем проекта в нашем кейсе?

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

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

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

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

Ну и четвертая роль — команда проекта.

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

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

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

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

Несмотря на это, надеюсь, читателем стала понятна точка зрения на ролевую модель в проекте, описанная в подходе PMBOK.

И в завершение – одно наблюдение: чем четче описаны ответственность и полномочия для всех рассмотренных в статье ролей, тем лучше для всех участников проекта. А отсутствие одной из этих ролей приведет к резкому снижению шансов проекта на успех!

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

Успехов вам в определении ролей в проектах!

Как распределять роли в проекте, чтобы потом не возникло вопросов «кто виноват?» и «что делать? Распределение ролей в группе

  • Помимо того, что в должностных инструкциях прописаны определенные права и обязанности сотрудников, в любой команде необходимо, чтобы каждый четко знал свою роль и выполнял свойственные этой роли действия.
  • Существует ряд критерий, определяющих закономерности распределения ролей в группах:
  • Роль определяет действия сотрудника с членами группы
  • Каждая роль подразумевает свои права и обязанности
  • В случае, когда членом группы не выполняются функции роли, случаются конфликты и сбои в работе
  • Группа работает на ура только тогда, когда все сотрудники честко знают свои роли и добросовестно исполняют свои обязанности
  • Когда меняется лидер — меняется распределение ролей
  • Человек может выполнять одновременно несколько ролей
  • Для того, чтобы достигнуть успеха в коллективной работе, необходимо избежать доминирования какой либо из роли.
  • Известные доктора Рэймонд Мередит Белбин
    и Рауль Шендлер
    выдвинули свои теории распределения ролей, которые в настоящее время активно используется в HR-практике.
  • По Шендлеру, ролевую динамику в команде можно представить так:

«Альфа»
— независимый лидер группы, активный деятель. Уверен в себе, всегда стоит на первом месте, но при этом, связывает свою судьбу с жизнью группы.

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

«Гамма»
— таких людей еще называют «амебами». Они пассивны и легко ко всему приспосабливаются, зачастую безответственны.

«Омега»
— как правило, такие сотрудники — изгои. Они отстают от других из-за неумения или неспоспобности, неуверенности.

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

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

Если возникают недоразумения, необходимо выполнять следующие действия:

Помогать группе преодолеть бюрократические барьеры;

Минимизировать конфликты, недоверие и т.д.

Реализовать потенциал сотрудничества.

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

  1. Стоит учесть несколько факторов:
  2. 1) разные задачи лучше решаются людьми, успешно выполняющими соответствующие задачам роли;2) люди склонны прилагать больше усилий в решении тех задач и выполнении тех ролей, которые они предпочитают;
  3. 3) люди стремятся к удовлетворенности в работе, поэтому если не добиваются успехов, то переходят на другое место.
  4. По мнению Белбина, в каждой группе есть девять ролей, которые являются не стереотипами, а определенным стилем деятельности.
  5. Роли, ориентированные на интеллектуальную деятельность:

  6. Роли, ориентированные на практическую деятельность:

  7. Нейтральная роль

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

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

Нужно задать себе несколько вопросов о своей деятельности, например: «Что, как и зачем я делаю?»

Пройти тест Белбин и предложить пройти его своим коллегам.

Хорошо, если менеджер по персоналу играет важные для группы роли, например «генератор идей». Но бывает и такое, что он оказывается вне команды — не знает задачи, стоящие перед командой, не разбирается во взаимоотношениях, происходящих в коллективе.

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

Читайте также:  Декларация соответствия на продукцию в рамках 44-фз и 223-фз

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

Распределение ролей в команде.

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

распределение ролей в команде. Американские профессора Мескон, Альберт, Хедоури предлагают разделить все роли в команде на целевые и поддерживающие.

Зная их, нетрудно составить схему распределения ролей в команде (рис. 16.1).

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

Председатель (Chairman) —

это главная роль. Этот человек выполняет вполне конкретную ролевую функциональную задачу.

  • Координатор 0Coordinator)

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

Генератор идей {Ideas)

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

Информатор {Informer).

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

Эксперт {Expert)

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

Проработчик {Elaborator).

Его роль — разъяснять, приводить примеры, развивать мысль, пытаться прогнозировать дальнейшую судьбу предложения, если оно принято.

Завершатель {Completor)

обобщает, суммирует все предложения, подводит итог, формулирует окончательное решение.

Рис. 16.1.

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

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

Рассмотрим основные поддерживающие роли.

Поощритель (Encourager

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

Придающий форму (Shaper).

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

Исполнитель (Doer)

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

Устанавливающий критерии (Purposing criterion)

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

Ответственный за внешние контакты (Ext contacter).

Его задача — связать команду с внешним миром.

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

Распределение ролей в команде происходит в соответствии с принципами — принципами компетентности и предпочтения.

Согласно принципу компетентности

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

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

  1. Согласно принципу предпочтения

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

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

Вечные вопросы управления: «Кто виноват?» и «Что делать?»

Александр Соломатин

Источник: http://www.solomatin.su

Почему случается так, что подчиненные не справляются с поставленными им задачами? От кого зависит – будут ли достигнуты те или иные рабочие цели, или нет? Что делать в ситуации, когда мы сталкиваемся с неисполнением поставленных задач?

«Я им говорю – не ложьте, а они ложут!»

(из фильма «Доживем до понедельника»)

Конечно, можно ответить, что «Подчиненные “НЕ ТЕ”», «Исполнители недостаточно квалифицированные», «Сотрудники недостаточно ответственные» и пр. Однако, эти ответы продемонстрируют абсолютную беспомощность руководителя.

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

Задача не выполнена, потому что… Кто виноват? Что делать?
1.…у сотрудника не хватает нужного опыта, знаний, навыков Большая часть ответственности – на руководителе , т.к. он поручил задание сотруднику, не оценив его способность справиться с заданием
В меньшей степени, но тем не менее – также виноват работник , т.к. принял на себя выполнение этого задания, переоценив собственные возможности
Перепоручить задание другому сотруднику, если оно срочное
Обучить сотрудника необходимым навыкам, если это позволяют сроки выполнения задания
2 …сотрудник недостаточно мотивирован на выполнение этой задачи Руководитель , т.к. в момент постановки задачи не проконтролировал настрой сотрудника на выполнение данного поручения
Сотрудник , т.к. сам должен был проявить активность и заявить о своем отношении к выполнению задачи
Объяснить сотруднику – какое значение имеет выполнение этих задач для компании в целом, и для сотрудника в — частности
3, …у сотрудника проблемы личного характера: здоровье, семья, и пр. Сотрудник , т.к. он сам должен решать свои проблемы. Руководитель может проявить внимание и сочувствие и оказать моральную поддержку
4, …сотруднику не хватило информации для выполнения задания Большей частью — руководитель , т.к. сотрудник может не представлять, какого рода источники необходимо использовать. Предоставить полную информацию, либо – указать, какую именно информацию необходимо использовать, и где ее взять.
5 …сотрудник неверно понял задание и сделал «не то», или – интерпретировал задание по-своему Большей частью, руководитель , т.к. упустил из внимания то, что каждый склонен слышать то, что хочется, а не то, что говорится Ставя задачу, убедиться в том, что сотрудник понял и пойдет выполнять действительно ту задачу, которую необходимо, а не ту, которую ему удобно выполнитью.
При постановке задачи, назначать точки промежуточного контроля

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

Оцените публикацию

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *