Мама, я тимлид!

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

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

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

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

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

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

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

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

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

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

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