Хорошая команда – залог успеха

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

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

Речь не о команде, речь о тебе.

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

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

Давай я переведу это на язык бизнеса и процессов – ты:

                - договорился с командой о наборе задач и их очередности;

         - команда понеслась их выполнять – ты просто наблюдаешь, не вмешиваясь (важно);

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

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

                - ты возвращаешься в функцию «наблюдателя»

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

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

Перед тем, как ринуться в это увлекательное путешествие, подумай трижды. Лучше – примени логику:

-  Этой проектной команде предстоит один виток задач или они будут взаимодействовать несколько фаз проекта, как минимум, год-полтора?

- Какого рода задачи стоят перед командой? Они взаимозависимы? Взаимозаменяемы?

- Все ли члены команды одинаково сильны с точки зрения навыков и знаний? Потребуется ли взаимовыручка, обучение, помощь?

Если на два из трех вопросов ответ «да, скорее всего», то тебе не отвертеться – придётся строить команду. Всерьез. Основанную на полном доверии. А это дорого, иногда – непозволительно дорого. Поэтому подумай трижды...

Сценарий номер один: времени полно (редко, но бывает). Способ выполнения – строить команду, дружить их всех. Закатывай рукава и вперед! Здесь пригодится и психология, и основы игротехники и, на крайний случай, совместимость гороскопов.

Из предметных советов:

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

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

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

Все придет. Команда создаст саму себя и тебе воздастся за твое терпение. Еще раз о важном – такая модель возможна только когда действительно много времени.

Сценарий номер два: времени нет. Способ выполнения – менеджмент, чистый проектный менеджмент и ничего личного.

В таком случае помни:

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

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

            - говори с ребятами и говори много – раза в три больше, чем если бы ты говорил с целостной командой. Но разделяй. Диалог – человек ß> человек, а не человек  ß-> команда