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

команда проекта

Как сформировать первоклассную проектную команду?

722
0

А действительно — как?

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

Перед написанием всех этих «букоф» я воспользовался поиском в сети и нашел следующие, сформулированные кем-то, шаги по формированию команды разработки:

  • Отобрать подходящих сотрудников
  • Отрегулировать численность команды
  • Совместно определить цели и задачи
  • Объяснить какие выгоды получит каждый в результате успешной деятельности команды
  • Помочь членам команды лучше узнать друг друга
  • Обучить членов команды
  • Обеспечить поддержание командного духа
команда проекта

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

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

Поехали…

Отобрать подходящих сотрудников

Само собой, вам достался самый непонятный, сложный и запутанный проект. Ну а какие проекты нам еще могут перепасть?! Нам выставили какие-то безумно жестокие сроки, нам грозят карами небесными, если вдруг что-то не так. В общем, все как всегда во многих местах, но только не там, где сейчас доводится работать мне.

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

создание команды

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

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

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

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

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

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

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

тестировщик

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

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

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

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

характер человека

Мне приходилось работать с командой, в которой был один явно выраженный холерик. Он очень быстро говорил, когда начинал волноваться и входить в раж, он очень быстро кодил с опережением мысли, возвращался назад, переделывал, и так пару раз, пока остальная команда делала в первый раз. Он активно генерил баги и не менее активно их исправлял еще до того, как тестировщик успеет сказать «баг!». Его держать надо было втроем, и четвертого готовить про запас. Он был пропеллер. Но два таких — это был бы перебор. Так что думайте о темпераментах членов команды, когда формируете состав.

А вообще, в целом, стабильные команды, которые работают вместе уже не первый проект, практически всегда выигрывают. Так что надо нарабатывать слаженные команды, чем мы, собственно, тут и пытаемся заниматься. Хотя у стабильных команд есть и оборотная сторона: когда-нибудь участники такой команды надоедают друг другу. Это как на подводной лодке. Через полгода плавания экипаж уже не может видеть друг друга. Но через какое-то время расставания, все начинают скучать друг за другом и готовы снова уйти в море. Ну, по крайней мере, я читал про это в рассказах реальных подводников.

Отрегулировать численность команды

Кстати, очень правильный шаг. В самом деле, в порыве командо-собиральческой деятельности можно и перебрать. Ну вот сколько реально нужно людей в команде? С одной стороны, есть целые методики, которые помогают чуть ли не автоматически рассчитать необходимое количество требуемых ресурсов в зависимости от сложности задач, оценок трудозатрат и еще много чего. С другой стороны, в интернетах кругом пишут, что число возможных взаимодействий между n членами команды равно n*(n-1)/2. Т.о. в команде из 9-ти сотрудников число возможных взаимодействий, приходящихся на каждого, составляет 36, а в команде из 4-х сотрудников только 6. И вот как быть?

Из своего личного опыта разработчика могу сказать, что число возможных взаимодействий, равное 6, выглядит и ощущается заметно лучше и приятнее, чем 36. Небольшая команда, состоящая из 4-5 человек, гораздо быстрее находит общий язык и приспосабливается друг к другу. Люди начинают понимать код соседа с первых букв цикла for. Тернарная операция перестает быть полуругательным выражением и начинает одинаково использоваться в нужных местах вместо if…then. Поумничал здесь, думаю пока достаточно.

отбор в команду

Ну хорошо, а если у нас проект явно не для 4-5 человек — что тогда? Я бы подумал о создании нескольких небольших команд, которые бы работали над своими отдельными фрагментами и постоянно синхронизировали свои результаты друг с другом. В каждой из таких мини-команд будет свой техлид, возникнет некая сетевая структура, каждая ячейка которой является полнофункциональной командой.

Совместно определить цели и задачи

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

Чтобы этого не было, нужно заранее для всех задач сформулировать критерии приемки (Acceptance Criteria), чтобы было ясно, что именно означает готовность функционала задачи, а также договориться, что мы имеем в виду, когда ставим у задачи статус "Выполнена" (сформулировать Definition of Done). Про каждое из упомянутых понятий можно найти много информации, но поверьте, это то, что нужно, чтобы не ехать «кто в лес, кто по дрова».

Выгоды. Или что нам за это будет?

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

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

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

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

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

Помочь членам команды лучше узнать друг друга

Стабильно сработавшиеся команды обычно и так знают друг друга до мозга костей. Если же команда собирается в первый раз, то всем придется пройти фазу знакомства. Подразумевается, что «фаза знакомства» — это не просто пятиминутное представление типа: вот это Леша, Коля, Вася, а вон там вот Наташа сидит и тестирует наш код. Все несколько сложнее и интереснее.

тимбилдинг

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

Или вот ты менеджер. Сидишь в отдельном кабинете, весь такой в белом, а команда твоя где-то там, в другой комнате, в той самой берлоге проекта. Ну и что из этого получится? А получится то, что все разработчики будут думать о тебе как о какой-то непонятной единице в штатном расписании компании, а не как о ком-то полезном и нужном для проекта. И будешь ты такой менеджер, который, вроде, как и есть, но никто его не понимает, что он, зачем он.

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

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

Обучить членов команды

Максим Батырев в книге «45 татуировок менеджера» одну из глав назвал «То, что очевидно для вас, не очевидно для других» (кстати очень интересная книга, написанная простым и доходчивым языком). Смысл в том, что перед тем как что-то ожидать от человека, его надо сначала научить тому, что от него требуется.

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

Многие компании создают базу знаний для того, чтобы вновь пришедшие сотрудники могли почерпнуть знания о том, как собственно все тут заведено. Наша компания не исключение, мы тоже накапливаем такой кладезь знаний и работаем над тем, как все это сделать более понятным, доступным и быстро понимаемым. Процесс этот не легкий и не быстрый. Но сделать это надо обязательно. В отсутствие такой базы знаний нам приходится на словах, из уст в уста, передавать знания и опыт. С одной стороны, это тоже фактор наработки командного духа и взаимодействия, с другой — все могло бы проходить несколько быстрее. Так что наша компания знает, чего мы хотим достичь, и представляет, как это сделать. Мы, как говорится, в пути…

Обеспечить поддержание командного духа

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

С другой стороны, мероприятия, описываемые в учебниках «ролевых игр» (вроде ловли падающего назад человека, одинаковой одежды и т.п.) — это тоже просто игры, не верю я им.

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

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

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

И последнее по списку, но не последнее по значению: относиться к людям нужно так, как ты хочешь, чтобы относились к тебе.

Удачи!

Автор иллюстраций — James Gilleard.