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

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

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

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

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

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

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

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

4

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

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

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

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

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

В процессе запуска Pixar идеи Деминга служили для меня маяком».[13]

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

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

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

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

В названии главы я противопоставила неравнодушных