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

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

Я бы добавил пункт о необходимости формировать небольшие рабочие группы и разделять более крупные. В нашей практике кристаллизация команды происходила при наличии лидера в группах не более 5-7 человек, но зато уже несколько раз. Во всех больших группах команда обязательно разваливалась. Этот процесс хорошо описан в книге "Человеческий фактор" Тома Демарко.

Хорошие советы, которые стоило бы расписать подробнее, чтобы они не казались словами Капитана-Очевидность.

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

Как ни крути в нашей сфере деятельности кадры — это 90% успеха. Пожалуй, стоит выделить несколько тезисов, с которыми мне приходилось сталкиваться в работе:

• интерес — заинтересовать команду даже на самый заурядный проект, значит зачастую получить отличный результат. Ведь понимание, что твой проект/продукт кому-то нужен, интересен и будет пользоваться спросом — прекрасное чувство
• вовлеченность — как мне кажется, это основная проблема корпораций. Человек не чувствует себя частью команды, он чувствует себя «винтиком», хотя и это иногда кому-то нравится. Что касается средних и небольших коллективов (в том числе, которые не всегда могут позволить компенсировать время сотрудника высоким окладом), главное дать понять людям, с которыми ты работаешь, что вы работаете вместе на итоговый результат, а не они на вас.
• мотивация — кому-то приятно осознавать, что он профи в своем деле, кто-то хочет материального поощрения. Задача руководителя любого звена — понять, кто из сотрудников склонен к каждому виду мотивации поддерживая их успехи.
• совместный досуг и тимбилдинг — часто читаю много «негатива» о тимбилдинге, но думаю проблема, что проблема в понимании данного термина по-своему. Можно ездить на природу и «падать спиной на руки коллегам», а можно проводить досуг за просмотром футбола, походами и т. п. Это не должно быть «обязаловкой», пусть люди в коллективе сами решат, что им интересно.

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

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

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

Хочу поддержать точку зрения Тачата Игитяна на работу и отношения с командой – все верно подмечено.

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

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

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

Ну и еще хочу посоветовать руководителям команд – старайтесь не только работать со своей командой, но и отдыхать время от времени с ней (ходите в походы, ездите на оупенйэры, делайте шашлыки совместные)…

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

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

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

Всем успехов.

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

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

П. 2 «Давайте команде полную картину». Заголовок правильный, а содержание отражает только его часть. Потому что «итоговая бизнес-задача» звучит красиво, но на практике мы не застрахованы от проектов, в которых полная картинка такова: клиент так хочет, значит
так надо делать, даже если это дурь полная, и никакой бизнес-задачи тут нет, кроме той, что компания должна получить за этот проект деньги, которые пойдут в частности и на зарплату команды. И в таких проектах каждый член команды должен понимать «полную картину», но не красиво-теоретическую, а такую, что иногда (даже не иногда, а частенько) приходится и тупо батрачить и делать неинтересную работу, и именно «рисовать» и «программировать», а не «разрабатывать бизнес-логику», что даже такую работу нужно делать качественно и вовремя. Жизнь жестока :). Вот мы, например, сейчас делаем тупейший проект для финансовой организации, от которого у всей команды рвотный рефлекс. Но это — деньги и перспектива работы для компании с другими аналогичными фин. организациями, поэтому надо терпеть, причем всем — от программиста до юриста.

П. 4. «Проводите время с командой». Тут надо бы обозначить, что именно имеется в виду. Проводить совещания и обсуждения по проекту — да. Пить с ними пиво после работы и проводить душеспасительные беседы — нет. Любой руководитель должен дистанцироваться от подчиненных и не допускать, во-первых, панибратства, во-вторых, того, что члены команды начнут учить руководителя руководить. Если доходит до второго, начинается разруха и в проекте, и в компании. У таких «проведений времени» слишком много отрицательных сторон, если речь идет о работе в коммерческой организации. Почему так часто разрушаются и делятся на части компании, у которых учредители друзья? Именно поэтому — нет дистанции, нет четкого понимания, кто главный. Дистанция между руководителем и подчиненным должна быть обязательно.

П. 6. «Будьте хорошим коммуникатором». Абстрактно хорошо, благодарить людей за работу — хорошо, разный подход к людям — хорошо, адаптироваться под каждого человека — не хорошо. Не должен руководитель адаптироваться под подчиненных. Руководитель априори самый важный член команды, и в идеале должен подбирать сотрудников, с которыми можно было работать, не перестраивая себя.

П. 7. Говорить с командой на одном языке. Тоже сомнительно. Хорошо, что у автора статьи был опыт работы админом и он смог расположить к себе админов, но расширять этот случай до того, чтобы руководитель сам ковырялся в фотошопе и программном коде, не хорошо. Извините за сравнение, но для дрессировки собаки Вы не встаете на четвереньки и не лаете. Люди — не собаки, разумеется, но если они не выполняют распоряжений руководства, это не значит, что Вы должы спускаться на их уровень. А тот факт, что админы или кто-либо другой сами решают, что задачи того менеджера, который им нравится, нужно сделать, а на остальные можно забить, вообще никуда не годится. Команда сама выбирает, какой руководитель ей подходит, а какой нет. Это анархия натуральная. Это ж анархия натуральная. Вполне вероятно, что при такой схеме выиграет конкретный проект и его менеджер, но это крайне вредно для компании в целом. А менеджер, который не делает хорошо компании в целом, не есть хороший менеджер.

Итого. Да, не нужно относиться к команде как к ресурсам, но корешиться с командой весьма не полезно.