Работа в команде

Автор: Steve Pavlina
Dexterity Software

Перевод: Виктор и Ирина Шепелевы
ТО "Движение в Защиту Слонов"

Источник: www.dexterity.com
Опубликовано: 19.02.2004
Версия текста: 1.0

Чтобы сформировать сильную команду, нужно стать профессионалом в создании команд
Сначала команда, потом - проект
Выбор правильных членов команды - единственно важный фактор успеха или провала проекта
Выбирайте командных игроков, не индивидуалов-суперзвезд
В команде должен быть единственный руководитель
Программа = команда
Поддерживайте связь
Разделяйте вознаграждение
Запишите это
Выгоняйте отстающих членов команды

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

Хотя командные проекты могут принести большую выгоду, но и риск здесь больше. Когда проваливается проект "одинокого волка", ущерб минимален. Зачастую затронут лишь один человек, и этот человек заведомо принимает полную ответственность за результаты. Мало кто и заметит. Вы ошиблись - вы навредили только себе и, надеюсь, чему-то научились - ни вреда, ни мата. Иногда провалившийся личный проект даже считают почетным знаком, признаком: вы, мол, хотя бы пытались прыгнуть выше своей головы. Когда же проваливается командный проект, это задевает многих. Стрелки переводят куда попало. Сердитые посты рассерженных членов команды заполоняют форумы: "проектировщик - идиот", "все дизайнеры - лентяи", "программист некомпетентен", "проект был чересчур претенциозным". Проект умирает болезненной смертью при большом скоплении народа. Озлобленные экс-участники решают, что командные проекты, видимо, обречены изначально, и решают никогда не повторять этой ошибки.

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

Хорошая новость: есть способы увеличить шанс на успех командного проекта безо всякого волшебства. Большая часть нижеследующего вытекает из обычного здравого смысла, но несмотря на это, принципами "здравого смысла" слишком редко руководствуются при создании команды. Так что давайте без лишних слов выясним, как сформировать и поддерживать большую команду....

Чтобы сформировать сильную команду, нужно стать профессионалом в создании команд

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

Ну и как набраться опыта в формировании команды? Как и в любом другом умении. Читать книги и статьи, слушать аудиокурсы, смотреть видео, говорить с командами, успех которых очевиден, посещать семинары. Умению создать команду можно научиться, и для этого нужно время. Имейте терпение. Нужная информация - вот она, но нужно осознать ее прежде, чем использовать. Вряд ли кому нужен программист, не способный написать цикл от 1 до 10, не заглянув в книгу; так же опасно начинать формировать команду, не усвоив основные навыки. Учиться методом проб и ошибок неплохо, но если этот метод использовать для тренировки командных навыков, можно многим испортить жизнь, потерять репутацию и, может быть, приобрести парочку врагов. Создавать по-быстрому команду, чтобы научиться это делать - это как отправиться на войну поучиться воевать. В обоих случаях сильно повезет, если выживешь, а можно и погубить всю команду заодно с собой. Так что стоит обучаться основным командным навыкам сначала в одиночестве. Как говорят американские "морские котики", "тяжело в учении - легко в бою" (в оригинале: "The more you sweat in training, the less you bleed in war").

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

Как узнать, готовы ли вы начать формировать команду? Я предлагаю такое "правило большого пальца": вы готовы, когда считаете, что охотно присоединились бы к команде, сформированной и управляемой кем-то вроде вас. Если вы дважды подумали бы, присоединяться ли к такой команде - значит, еще не готовы формировать свою. Заметьте, какие факторы заставили вас задуматься, и немедленно начинайте исправлять их. Мы живем в информационном веке - так пользуйтесь этим.

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

Сначала команда, потом - проект

Многие разработчики выбирают проект, над которым хотят работать, создают проектную документацию, а затем начинают собирать команду для этого проекта. Эта идея только кажется хорошей, на самом деле это не так. Невозможно реалистично выбрать проект, пока нет команды. Неплохо иметь общую идею проекта, который хочется создать, но пока команда не собрана, не стоит определяться с деталями. Почему? Рассмотрим обе альтернативы (сначала команда / сначала проект), чтобы понять, к чему это может привести....

Для начала предположим, что выбран стандартный подход "сначала проект, команда - потом". Вдохновившись идеей, разрабатываем архитектуру игры до некоторой степени подробности, выясняем, какие таланты необходимы, чтобы завершить проект, и начинаем собирать команду. Допустим, вы хотите быть проектировщиком и разработчиком, и решаете, что нужны еще два программиста и один художник. Музыку и звуковые эффекты можно лицензировать. По сути проект - простой 3D-action. Вы уверены, что игра будет потрясной, и спецификации выглядят достижимыми. Вы оцениваете, что игру можно сделать за 4-6 месяцев.

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

Что случается с вышеупомянутым проектом в действительности? Месяцами вы ищете и не находите приличного 3D-программиста, готового работать на ваших условиях. Лучшее, что у вас есть - 2D-программист, изучающий 3D-программирование. Художник не нарисует приличной текстуры даже для спасения собственной жизни, зато оказывается великолепным 2D аниматором и хочет "заставить это стрелять". Второй программист находится за границей и едва говорит по-английски, но может работать удаленно. Приходится получать максимум из того, что есть.

Все идет не так. Мнения двух программистов частенько противоречат друг другу. Художник не может делать качественных текстур, сколько бы не практиковался. По экрану что-то бегает, но технология глючная, и игра вовсе не забавна. Члены команды и не пытаются следовать первоначальному дизайну - каждый пытается осуществить собственные идеи, вас огорчает, что они невнимательно читают проектную документацию, вы пытаетесь усилить контроль, говорите художнику, что конкретно рисовать, даете программистам еще более детальным инструкции и задачи. Тем не менее каждый видит готовую игру по-своему, и недостаток единства тормозит проект. Члены команды стараются делать необходимый минимум, чтобы создать видимость работы, и никто уже не верит в успех. Оказывается, что один из членов команды уже участвует в другом проекте, и ваш для него - на втором месте. Проект катится вниз и в конце концов проваливается.

Ошибкой было предположить, что проектирование хорошей игры - необходимое и достаточное условие успеха. Может быть, это и так для индивидуальных проектов, но не для командных. Для командных проектов необходимое и достаточное условие - выбор правильных членов команды. С неправильной командой в конце концов все ваше время уходит на обеспечение контроля. С правильной - особый контроль не нужен, и нормой становится индивидуальная ответственность.

Другая проблема подхода "сначала проект, потом команда" - возможности команды используются неоптимально. Намного лучше разработать игру так, чтобы использовать в полной мере имеющиеся таланты. Разработчики расцветают, когда делают посильную работу. Есть выдающийся 2D художник - используйте его, чтобы создать выдающуюся 2D игру, а не паршивую 3D. Раз команда - ограничивающий фактор, она должна диктовать проект.

Рассмотрим второй вариант: "сначала команда, потом проект". Стоит обдумать общую идею проекта, но оставить вопрос о деталях открытым. Нужно потратить время, чтобы выбрать в команду, по возможности, лучших. Поскольку тут можно гибко подбирать членов команды (ведь вы оставили вопрос о конкретизации проекта открытым), можно уделить больше внимания межличностным отношениям, и выбрать в команду людей, которые будут хорошо работать вместе. Как только команда собрана, все вместе определяют архитектуру, лучше всего использующую силы коллектива и компенсирующую его слабости.

Для успеха проекта нужно, чтобы каждый был предан общему делу. И разработчики будут более преданы проекту, если внесли вклад в его архитектуру и могут в полной мере проявить свои силы. Каждый член команды знает, что его вклад будет заметен, и принимает совладение проектом. Тут и проект идет в гору - на энтузиазме и преданности общему делу. Скорее всего, команда захочет работать вместе и в будущем.

Выбор правильных членов команды - единственно важный фактор успеха или провала проекта

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

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

Выбирайте командных игроков, не индивидуалов-суперзвезд

Чтобы командный проект выжил и процветал, нужно отобрать и принять на работу именно командных игроков, а не индивидуалов-суперзвезд.

Рассмотрим Зимние Олимпийские игры-1980. Команда США произвела фурор в хоккее, победив команду СССР 4:3 и получив золото, несмотря на то, что в последнем матче перед Олимпиадой СССР разгромил США со счетом 10:3. Герб Брукс, тренер команды США, сказал в интервью, что он использовал психологические тесты, чтобы выкинуть эгоцентричных суперзвезд, и отобрал только командных игроков, поддерживающих друг друга.

Командные игроки уважают индивидуальные различия, и в то же время стремятся к достижению общей цели. Командные игроки тоже честолюбивы, но их амбиции касаются проекта или компании, а не их собственного "я". Их амбиции командны. Они перепишут любой кусок кода, переделают любой рисунок, пересочинят любую мелодию, охотно и без жалоб, для пользы проекта - для пользы команды. Командные игроки - как клетки тела, работают вместе для поддержания жизни и здоровья всего организма.

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

Характер одерживает верх над индивидуальностью. Если личное достоинство священно - каждый берет на себя ответственность за проект. Если честность превыше всего - подозрения и недоверие не имеют оснований. И если взаимное уважение высоко - мелкие личные различия просто не имеют значения.

В команде должен быть единственный руководитель

В каждой команде обязательно должен быть ровно один лидер, и каждый должен недвусмысленно понимать, кто этот лидер. Лидер подает пример, которому следуют остальные, и он должен заработать уважение команды. Если члены команды больше не уважают руководителя - проект катится вниз. Уважения по принуждению не бывает. Его можно только заработать.

Как руководителю команды заработать уважение? Используя преимущества единства и ставя потребности команды на первое место. Руководитель команды - пример для ее членов. Руководитель команды должен стараться быть честным, порядочным и объективным. Если руководитель дает обещание - оно должно быть выполнено. Руководитель должен стать воплощением стандартов, вне зависимости от того, соответствуют ли этим стандартам члены команды.

Задача руководителя - принести команде победу в первом проекте, неважно в каком. Поскольку это - жуткая ответственность, нужно совмещать это с высокой степенью контроля. Руководитель выслушивает всех членов команды, но всякий раз, когда нужно принять ключевое для проекта решение, это - задача руководителя. В хорошо функционирующей команде, члены команды редко пересматривают решения лидера. Если нужно делать выбор, то, зная все факты, командные игроки приходят к одному, лучшему, решению, даже если для них лично это означает лишнюю работу или ограничение свободы.

Программа = команда

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

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

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

Поддерживайте связь

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

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

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

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

Разделяйте вознаграждение

Есть много методов раздела прибылей. В идеале, команда работает лучше всего, если все члены команды разделяют потенциальные прибыли, то есть получают проценты с продаж. Очень важно, чтобы члены команды чувствовали, что им воздастся по заслугам и что "лишняя" работа будет вознаграждена. Если чувствуете, что справедливо поделить прибыль невозможно - не начинайте проект вообще.

Кроме финансовой компенсации, каждого члена команды нужно упомянуть в титрах игры. Обильно похвалите каждого, и будьте искренни в похвале. Даже не предполагайте, будто они знают, что сделали хорошую работу. Похвала - простой способ поднять боевой дух. Если возможно, всегда хвалите каждого публично (в присутствии остальных членов команды). Будьте определеннее в похвале. Не говорите просто "Хорошая работа". Лучше скажите "Вы сделали выдающуюся работу с этими текстурами на прошлой неделе. Уровень детализации и освещение превосходны. Превосходная работа! Ваши рисунки сделают игру великолепной".

Запишите это

О чем бы вы ни договорились с членами команды, это нужно записать. Людям часто проще договориться устно, но когда все записано, упущения и несогласованности легче обнаружить. Старайтесь предсказать всевозможные непредвиденные обстоятельства и решить, что с ними делать. Что делать, если член команды хочет выйти из проекта? Как распределяется прибыль? Какие обязательства должен выполнить каждый член команды? Когда будут посылаться чеки оплаты? Кто владеет интеллектуальной собственностью? Может ли музыкант продавать песни, созданные для проекта, на своих дисках? На эти вопросы нет правильных или неправильных ответов. Каждая команда ответит на них по-другому. Единственный неправильный вариант - не решить эти вопросы заранее и не записать их в контракт с подписями.

Выгоняйте отстающих членов команды

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

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

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

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


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