Мама, я тимлид! Практические советы по руководству IT-командой

1 Ведем прицельный огонь

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

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

Умение привести команду к результату — важный навык тимлида. Вот слова одного из руководителей:

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

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

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

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

2 Цели бизнеса vs цели команды

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

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

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

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

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

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

3 Просветительская роль тимлида

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

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

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

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

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

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

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

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

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

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

4 За одного вовлеченного двух аутсорсеров дают

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

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

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

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

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

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

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

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