Правила управления командой

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

Правила создания команды

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

Правила управления командой

1. Помни что ты не начальник и не директор. Ты равный среди равных. Помни об этом во время обсуждений. Иначе тебя будут бояться.(Если на обсуждениях кто-то думает о том, что его "вообще-то могут уволить", то такое обсуждение не будет продуктивным.)
2. Помни что ты руководитель команды Помни об этом во время принятия решений. Тогда в тебе будут уверены. (Ты можешь быть нерешительным, сомневающимся, кусать галстук и грызть ногти.  Можешь сомневаться даже в том, что Земля вращается вокруг солнца. До того момента, пока ты не озвучил команде свое решение. После - сомнений быть не должно. Остается только признавать СВОИ ошибки.)
3. Твоя команда - это твоя "семья". Ты должен знать всё о каждом члене команды. Но никогда этого не показывать. (Знание того, что происходит в жизни участников команды поможет тебе правильно распределять задачи и нагрузку. Команда - это, конечно, не мафия. Но некоторые принципы построения мафии очень полезны.)
4. Главное в команде - чувство уверенности каждого в том, что он "среди своих". Он имеет право ошибаться, имеет право рассчитывать на помощь коллег. Но не имеет права не предложить свою помощь другим, если он может помочь. Создай такую атмосферу. Если кто-то из участников команды не вписывается в такую атмосферу - избавься от него (с ним и дальше можно будет работать, но участником команды он уже не будет).

Ты, команда и внешний мир 

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

Ха, да это точно. Просто "классика жанра"

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

1. "Заказчик сам не знает чего хочет". (причем этот вариант отличается от следующего по списку)
2. "Заказчик не может внятно объяснить чего хочет"
3. Заказчик: "У меня есть уже задание, так что не нужно по пустякам отрывать моих сотрудников от работы"
4. Заказчик: "Слушайте, мне ваше тз сейчас читать некогда. Но вы же все правильно поняли? Так что давайте."
5. Разработчик архитектуры в команде, глядя на ТЗ: "И что? Ты сам все это писал? Ну-ну ..."
6. Молодой программист: "Аааа! Все понятно. Хорошо, сделаем."
7. Руководитель проекта на вопрос о сроках: "Скорее всего, если подумать, то не уложимся при любом раскладе"
8. Заказчик на первом демо: "Здорово! И это тоже можно?" Заказчик через 2 месяца: "Слушайте, я же вам в самом начале говорил... Вы вообще меня не слушали что ли?"
9. Мы - команда и решения будут приниматься коллективно. Кстати, скажи чтобы этот урод из логистики мне больше не писал. Общение с заказчиком должно быть централизованным.
10. Заказчик хочет не то, что ему на самом деле нужно (спасибо Анатолию Белайчику за подсказку)
11. Команда проекта не обладает полной информацией по проекту. Где-то "недосказаны цели", где-то - принято решение, но не все участники в курсе.
12. Дежурный вопрос "РП" - "Вася, я прислал тебе задачку. Сколько времени займет?"
       Дежурный ответ "программера" - "Я не смотрел еще. Погоди, ща гляну."
В результате получаем: "Эту фигню надо дня 2 колбасить. Хотя они вообще-то сами козлы. Так что можно и за пару часов сделать. Но по уму весь этот кусок хорошо бы переделать, а-то периодически будем на такие косяки натыкаться."

(продолжение следует)

Что нам ждать друг от друга? (Заказчик проекта и Команда реализации)

В этом месте попробую начать собирать для себя (ну может и другим понадобится) ожидания Заказчиков и Команд по реализации.
И то, чего ждать не стоит.

Вообще-то, правильнее будет такое распределение ролей: "Заказчик - Руководитель проекта - Команда разработчиков".

Итак что ждать и чего ждать не надо.
Никакого позитива и вдохновляющих цитат - только жесткий треш и мизантропия. :)

Заказчику от команды реализации:

1. Не стоит ждать от исполнителей понимания своих пожеланий к продукту проекта. У исполнителя свои пожелания, свои тараканы. Он, вообще-то, зарабатывает на вас.
2. Система, которую вам передают в качестве продукта проекта, скорее всего не будет задокументирована. Половина (в лучшем случае) ваших обсуждений не будут задокументированы. И историю проекта вы все равно не восстановите.
3. Вы думаете, что именно вы управляете тем, как все происходит? Нет. Это разработчики "рулят" процессом". И они сами решают- в какую сторону повернуть. Если зазеваетесь, то получите приложение для андроида с игрушками. Вместо системы управления проектами клиента.
4. Если в ценовом предложении пишется "4 часа работы аналитика", то это означает, что руководитель проекта пару часов покурит над вашей задачей. Не ждите что в эти "4 часа аналитика" над вашей задачей будет думать какой-то там аналитик. Никаких аналитиков нет - это миф! Два литра пива руководителя проекта с программером - это и есть описанные в КП "4 часа работы аналитика".
5. Вам кажется, что вы максимально честны с разработчиком, но это не так. Вы ему постоянно что-то не договариваете. Даже сами не замечая этого.  И не будьте "максимально честны". Просто отвечайте на вопросы, которые вам задают.

Команде реализации проекта от заказчика и руководителя проекта

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

Руководителю проекта от команды разработчиков

1. Заказчик тебя обманывает! Он хочет чтобы ты ему гарантировал написание новой операционной системы за деньги, которые могут просто покрыть расходы на написание приложения для телефона. Причем предоставил ему первую версию через месяц. И тогда он подумает - стоит ли за это платить?
2. Программист тебя обманывает! Он напишет то, что ты от него хочешь не за месяц,а за неделю. Просто ему сейчас это не очень интересно.
3. Тобой всегда  все будут недовольны. Просто потому что ты "здесь, под рукой". И тобой можно быть недовольным без опасения "навлечь на самого себя гнев начальства", без вариантов быть назначенным виновным в провале, ... Ты -удобная мишень. Ты-виноват! 
4. Команда всегда будет смотреть на тебя как на "несправедливо назначенного", если ты назначен. И всегда будет смотреть на тебя как на лидера, только в одном случае - если ты действительно лидер!

Руководителю проекта от заказчика

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

(продолжение следует)

Взгляд со стороны "противника"

Почему мы часто не понимаем тех, с кем сидим за одним столом переговоров?

Потому что:
"Заказчик не всегда все понимает ..."
"Ему уже вчера было нужно. А чего же он только сегодня об этом ..."

А у нас ведь:
"Свежие идеи и мы выстраиваем команду для того чтобы .."
"Архитектура новых приложений должна быть совсем другой."

Как-будто мы - противники.
Заказчик и разработчик.
РП и команда.
Программер и тестер.

А если попробовать посмотреть на ситуацию с "его" стороны?
Не один раз посмотреть. И увидеть что: "ладно, хорошо, был не прав, признаю".

А в систему это привести.
Смотреть всегда и с другой стороны. В смысле - и с другой стороны тоже.

Не в смысле постоянных "демо" с заказчиком.
И не в смысле "думания за него".

А просто принимая его позицию, как возможную.

Необходимо и достаточно (заметки на полях)

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

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

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

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

Если ты ... (не очень подробные заметки на полях)

Если ты…(Внедряешься внутрь?)

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

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

Если ты … (Ты - эксперт/консультант? Ух ты!!!)

Если ты «консультант по системе», то радостно наплюй на все возможные подводные камни проекта и радостно разъясняй людям «преимущество определенного покроя костюма» и невозможность «пришить вторую пуговицу». Ты специалист в этой конкретной системе и лучше тебя ее знают вообще-то не так много людей, а уж про знания системы теми людьми, которые гордо именуют себя "заказчиками", ты просто деликатно молчишь. Главная опасность для тебя - фраза "это противоречит логике системы". И ты можешь даже вслух ее не произносить (сдерживаться), но если она звучит у тебя в голове - ты в опасности. Ты сможешь скатиться в общение на профильных сайтах, думать терминами и логикой системы\продукта и в итоге твой продукт/система станут для тебя "системой ценностей и взглядом на жизнь".
Вывод: читай больше про другие системы\продукты\варианты. И даже если работа с данным продуктом стала для тебя стилем жизни, а ее (жизни) смыслом стала борьба с другими продуктами\системами - все равно изучай все новое. Ты хотя бы будешь знать врага в лицо.

Если ты ... (Ты - руководитель проекта. И теперь многое будет по-другому)

Если ты «руководитель проекта» – наплюй на функциональность системы и на систему в принципе, и думай о подтверждении договоренностей, о ясности целей и оценке результата, о подборе и мотивации команды. Ты настоящий "руководитель проекта" если у тебя есть набор сертификатов, если ты разбиваешь приготовление завтрака на этапы, если тебе сначала становится все равно из чего ты готовишь завтрак, потом - в какое время суток ты его готовишь, потом ты перестаешь особо думать в какой обстановке "условный завтрак" готовится (на кухне или в лесу), а на пике карьеры ты не будешь даже слушать предложения приготовить завтрак из продуктов общей стоимостью меньше ... у.е.
Вывод: ты сумеешь реализовать проект в любой области, ты будешь иметь портфель проектов, список публикаций, перечень сертификатов. Но старайся периодически выполнять и другие роли в проектах. Главная опасность для тебя - превратиться в высоколобого эксперта, преподающего в престижном заведении.

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

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

Если ты…. (Ты – аналитик в команде разработчиков? Поздравляю J)

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