Майк Грифитс, специалист по гибким методологиям, опубликовал в своем блоге excel-шаблон для оценки качества сотрудничества внутри команды проекта. Шаблон был разработан Edgardo Gonzalez, и базируется на основе данных из книги “Collaboration Explained“.
Нажмите на изображение, чтобы скачать шаблон в формате xls.
Работать с ним очень просто - нужно попросить участников команды оценить каждый из признаков по пятибальной шкале, где 1 - вообще не согласен, 5 - полностью согласен. После этого нужно внести данные в шаблон и проанализировать красивые графики.
Этот способ родом из гибких методологий, но ничто не мешает его использовать и в рамках традиционного управления проектами, если мы хотим оценить сплоченность команды и ее нацеленность на результат.
Итак, перечислим признаки высокоэффективной команды:
1. Самоорганизация
Самоорганизуемая команда, а не “административно-командная”
2. Возможность принятия решений
Команда обладает возможностью обсуждать, оценивать и принимать решения, а не просто исполняет решения, диктуемые извне
3. Уверенность в вИдении и успехе
Участники команды понимают цели проекта, и верят в то, что они, как команда могут решить любую проблему и достичь целей проекта
4. Преданность участников команде
Участники команды стремятся достичь успеха как команда, а не индивидуального успеха любой ценой
5. Доверие участников
Все участники готовы работать вместе и избегать страха, гнева, запугивания
6. Коллективное принятие решений
Участники команды занимаются принятием решений, а не следуют авторитарной воле других
7. Единодушие
Участники команды делятся своими мнениями и их мнение учитывается при принятии окончательного решения.
8. Конструктивные споры
Команда способна обсудить различные альтернативы и последствия решений, и выбрать самый выигрышный вариант.
13 ответов на данный момент ↓
1 Алексей // Mar 12, 2008 at 1:19 pm
Вот почему никто ничего не говорит по менталитете. То, что хорошо работает на западе, может провалиться на Руси.
Гибкие методологии это особенно рискованная вещь. Как и венчурные инвестиции - может дать сверх-результат, но велика вероятность провала.
В России в первую очередь нужен руководитель, капитан, царь. А остальное - получается само собой без западных шаблонов. Также и в Китае и в Индии.
Почему это считается крамолой, ведь славянские племена не изменились даже с принятие христианства и татаро-монгольским игом и с жизнью в СССР. Почему западные методологии должна нас подстроить под нормы и правила западных Best practices?
2 Андрей Куликов // Mar 12, 2008 at 5:01 pm
Алексей, я согласен с тобой в том, что в России принято руководить по-другому. Мне сложно сказать, откуда это выросло, и как это объяснить на философском уровне - но это так.
Но я точно знаю, что гибкие методологии могут работать - просто они намного более требовательны к коллективу. В небольшой компании, в которой каждый сотрудник - не просто исполнитель задач, а исполнитель интеллектуальных задач, это может сработать.
Конечно, не стоит рассматривать то, что пишут в книгах, как панацею. Это просто какие-то способы, которые могут сработать или не сработать - все зависит от конкретных условий. Но познакомиться со способами стоит, согласен?
3 Алексей // Mar 12, 2008 at 7:37 pm
Познакомиться - стоит. Я вообще против невежества и уверен что знание лишним не бывает. Информация из поста есть обобщение большого объёма эмпирической информации.
Но есть ли хоть одна эффективная команда на Руси?
Если есть, то как получилось её собрать и удержать? Если нет - то, что надо делать чтобы её собрать?
Как быть в случаях, когда через полгода-год после старта проекта кто-то начинает смотреть не на общую цель, а на что-то другое (self-emloyment, другие фирмы)?
Collaboration в западных странах отлажен и отточен, на сколько мне известно. Там точно посчитано на сколько человек должен быть один начальник. Обязанности каждого прописаны до пецела.
Collboration в России это
1. —————
- Вась, я сегодня чего-то плохо себя чувствую.
- А ну ладно, можешь не приходить, выздоравливай.
2. —————-
- Петь, тебе давали _месяц_ назад задание выгрузить на Прайс.ру наши товары
- Только этим и занимаюсь, не успеваю.
3. —————-
Если какой-то сотрудник чего-то понатворил, его даже уволить нельзя - работу выполнять некому.
4. —————-
Начальниками очень(!) часто становятся никак не приспособленные к этому люди. И количество начальников иногда достигает каких-то странных объёмов. В отделе из шести человек двое сидят на руководящей должности и получают директорскую зар.плату.
Резюме такое: брать западные технологии “AS IS” несколько чревато. Во-первых молодёжь зазубривает нужные слова и всеми силами пытается показать своё превосходство.
Наверное, интереснее был бы пост вида:
—
Обычно в разработке бывает проблема X. Для её решения используется аспект Y методологии Z. В российской действительности его можно применить в таком виде (модификации) …
В частности я смог добвиться того, что … (например сотрудники свободно могут подменять друг друга без какого-либо ущерба для качества кода)
—
То есть очень интересно использование этих способов, что называется, “от проблемы”. Например проблема - команда не эффективна. По вышеприведённым параметрам мы оценили уровень не эффективности. Что делать чтобы его постепенно повышать?
4 Алексей // Mar 12, 2008 at 9:56 pm
Честно-говоря, я очень надеюсь, что у Вас найдётся время по-немного описывать то как использовать опыт западных коллег в российской действительности :)
У Юрия Ветрова вроде получается без называния конкретных фамилий и конкретных проектов описывать “боевые” ситуации. У Вас совсем времени нет?
5 Андрей Куликов // Mar 13, 2008 at 11:31 am
Алексей, со временем, конечно, туго.
Но это хорошая мысль - описать конкретные случаи, а не хваленые методологии.
Я постараюсь в ближайшие дни написать запись о том, как пытаться строить эффективную комманду, и у меня есть предложение к вам: давайте вместе попробуем придумать некие гипотетические (или из реальной российской жизни) ситуации, в которых можно пробовать применять всякие методологии.
6 Алексей // Mar 13, 2008 at 3:59 pm
Первой темой хорошо бы выбрать Startup’ы.
Наверное в России есть люди знающие и(!) понимающие как надо набирать команду, как им дать задание, как его контролировать, как управлять “кнутом и пряником”, что дозволять, а что - нет, и т.п.
Но я - не видел и не слышал. И это можно понять, 99%-ов людей в сети - имбицилы и под градом их понтов мало что/кто выдерживает, в том числе люди.
Дак вот об ИТ-отделах в стартапах такие вопросы для разбега:
1. Как набрать сотрудников? кадровые агентства, по знакомым, или из периферии как-то выуживать?
2. Сначала выберем методологию (группу методологий) в зависимости от предметной области, или сначала команду наберём, а потом уже будет глядеть чего делать?
3. Какие программные средства будем делать сами, а какие будем покупать?
4. Как будем обучать сотдруников других отделов работать с нашим ПО? Например, купили Axapta, на её основе разработали интерфейс. Ведь он будет уникален (особенно если у руководителя нет большого опыта в этой сфере), надо выделять программистов под обучение. А многие программисты считают себя эллитой, и они врят ли кого-то смогут чему-то обучить.
5. Как быть с новыми технологиями? Собрали опытных бойцов, каждый что-то знает и получает за это зар.плату, как его мотивировать к использованию новых библиотек/процедур?
6. Если мы провели аудит/оценку эффективности команды/предприятия/решения. То что делать с полученными данными? Хоршо бы как-то проанализировать и понять как и куда лучше развиваться, какие у нас слабые места и как их сделать сильными, а главное - как преодолеть сопротивление людей к изменениям?
7. Как быть с дурными примерами? Когда один программист начинает проявлять неуважение к директору, начальнику или ведущему программисту? например, много раз был свидетелм такого:
Совещание. Директорша(!) чего-то рассказывает. Раздаётся звонок телефона, владелец свободно достаёт трубку и разговаривает. Это ведёт к тому, что никого из начальников никто не слушает. Если кто-то приходит новый, то через два-три месяца и он начинает так поступать. Как быть в таких случаях? И как быть в случаях когда плохой пример исходит от начальника или ведущего программиста?
Если некоторые вопросы требует слишком большого поста, то было бы не плохо их как-то декомпозировать, с обязательным описанием связей (”мостов”) между разными частями вопроса.
7 Алексей // Mar 14, 2008 at 9:09 pm
Чего-то затишье. Я ошибся в определении сложностей старапов?
Вообще стартапы сейчас рождают какие-то огромные массы накачественных начальников/руководителей. Фальшивый успех кружит людям голову. Возожно, имеет смысл с этой точки зрения рассматривать какие-то вопросы.
8 Алексей // Mar 14, 2008 at 10:14 pm
от ещё один вопрос о подборе команды.
Когда хорошие друзья приходят в одну фирму и получают должности разного уровня. Ведь не во всех случаях они будут представлять собой эффективней рабочие единицы – вроде и согласованность, и общий язык, и понимают друг друга с полуслова. Но сможет ли слабое сознание отказаться от претензий вроде “чем он лучше меня” (всё-таки начальник – это престиж, и чем меньше человек способен на руководство, тем больше он жаждет должности, а ещё начальник – более высокая з/п).
Можно ли по этим параметрам _оценивать_ силу/надёжность конкретного человека?
9 То, что я читаю « Эффективный человек // Mar 15, 2008 at 12:19 am
[…] Куликов. “Сотрудничество - основа высокоэффективной команды…. Андрей очень в такт интересующей меня теме приводит […]
10 Алексей // Mar 17, 2008 at 12:01 am
Я вот подумал, что сотрудничество это не только основа для команды, но ещё - основа ждя жизни.
Сотрудничество в виде СССР или Евросоюза, или единого экономического пространства США+Канада. Виды бывают разные, и это вопрос для рассмотрения (как мне кажется).
Как два конкурента могут сотрудничать. Навижн и Аксапта работают на одном рынке по-горзонтали (ERP) но на разных по-вертикали (Навижн примерно равен 1С, Аксапта - для более крупных объёмов данных).
Ведь у Вашей компании явно есть конкуренты, раздражающие руководство своим существованием. Какое-то описание возможно дать сего аспекта?
11 nadi // Mar 17, 2008 at 7:49 pm
Интересные критерии оценки сотрудничества! Мы пока просто оцениваем сотрудничество по 5-ти бальной шкале, где норма - 4, 3 - есть единичные легко устранимые замечания,5 - есть плюсы в работе…
По крайне мере, по этим оценка мы всегда видим проблемные зоны во взаимодействии между подразделениями, видим те подразделения, которые умеют взаимодействовать как с внутренними, так и с внешними клиентами.
12 Алексей // Mar 17, 2008 at 9:58 pm
Вообще, выработка регламентов (и, быть может, даже метарегламентов для описания процесса упорядочивания) для росскийских (украинских, беларусских) реалей могло бы стать прибыльным делом.
После развала СССР (с его экспериментальными химико-технологическими системами) были заводы которые жили только за счёт продажи регламентов. Хорошо жили. Потом регламенты кончились.
Ведь пост описывает (как мне показалось) правила оценки эффективности для последующей координации деятельности руководителя.
Я думаю каждый, сдавший PM, просто обязан вложиться в создание такой “экспертной системы”. Ведь если человек получил, волею судьбы, какие знания/умения на земле Русской, то надо бы чего-то и отдать :) вроде в том-то и суть collaboration’а :)
13 Управление проектами - кадры решают все? // Mar 17, 2008 at 11:12 pm
[…] комментариях к записи о высокоэффективных коммандах Алексей очень настойчиво :) предложил мне […]
Оставить комментарий