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

воскресенье, 12 июня 2011 г.

Тезисы третьей встречи (построение команд)

Встреча состоялась 4 июня, в первом корпусе СГАУ и была посвящена построению команд и отношениям фирма-сотрудник. Участники встречи: Калугин Александр, Константин Быченков, Денис Журавлев, Игорь Степин, Александр Сергеев, Андрей Чернов, Денис Пушкин,Николай Глумов, Артем Попов, Александр Белов, Ольга Белова.
 
Построение команды
Команду можно построить или на основе основе собранных людей (Есть люди — решаем кто, что будет делать) или на основе четко прописанных ролей (Сначала строим ролевую модель и потом подбираем под нее людей).
Построение команды зависит от модели организации. В линейной модели команды создаются надолго и решают проблему за проблемой. В проектной модели команды создаются краткосрочно. Однако строить модель и набирать под нее людей получается только если есть выбор. Матричная модель организации не нужна, если есть полная загрузка. В этом случае нужна линейная модель. Для создания успешных команд организация должна дойти до состояния «санитарной гигиены». То есть когда кадры, собранные в организации уже прошли некий отсев а руководство достаточно зрелое.


Роли исполняют
Часто в успешной команде участник застревает в своей роли и не растет профессионально. Выход их «вилки» когда хочется и команду сохранить и рост обеспечить — создание мини-команд в рамках организации. Участники команды мотивируются с помощью крепких связей и могут в то же время расти. Решение вопросов управления командами и выстраивания отношений между организацией и сотрудниками может взять на себя проектный офис. Наличие метрик и зрелых процессов позволяет зрелым организациям сравнивать эффективность различных команд.


Модель корабля для описания команды
Успех команды корабля — во взаимодействии исполнителей четко определенных ролей. Каждый кто хорошо выполняет свою роль — хорошо чувствует себя «на корабле». Так как отношения ролей, по построению, часто являются конфликтными (тестировщики и разработчики) личные отношения могут мешать эффективной команде. Когда люди меняют часто роли от проекта к проекту — получается команда на уровне фирмы.
Был полнят вопрос о профессиональном росте. С одной стороны сотрудники не очень то любят менять роли. Одновременно, мало кто видит себя в роли разработчика до пенсии. Работает ли модель waterfall в карьерном развитии или нет? Повышение квалификации — это осваивание новых ролей или совершенствование в чем-то одном?


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


Подходы к работе с командой
На длительный проект (от 6 месяцев) надо набирать взаимодополняющих и взаимозаменяемых людей по квалификации и моральным качествам. Сплачивает команду или общая цель или общий враг. Если команда небольшая (до 5 человек) то управляемость достигается ежедневными планерками и документированием «для начальства». Качество работы сотрудников регулярно (несколько раз в неделю) тестируются. Если метрики не устраивают — надо что то решать. При управлении коллективом исходить надо из того, что любой сотрудник может уйти хоть завтра. Поэтому необходимо дублирование исполнителей определенных ролей и должностные инструкции. Должностная инструкция необходима не только для улаживания трудовых вопросов но и для решения возможных юридических коллизий. Роли должны описываться в должностных инструкциях как можно полнее. Понятно, что описать все невозможно и в компании-семье должностные инструкции могут восприниматься как давление и ограничение «исконных свобод».


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

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


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

1 комментарий:

  1. Считаю, что самый реальный способ создать настоящие команды - действовать как в CQG. Создавать небольшие мобильные команды (3 человека), которые работают от проекта к проекту. Команда на уровне фирмы - нонсенс. Для фирмы она не имеет никакой ценности потому что все равно контроль снизить не удастся. Так же не встречал ни разу на практике чтобы команда строилась от ролей, которые необходимо "закрыть". Скажу больше, "построить" команду практически невероятно. Можно только создать условия в которых команды _могут_ появиться. И потом сохранять выращенное.

    ОтветитьУдалить