За одного вовлеченного двух аутсорсеров дают
Я свято верю в то, что по-настоящему качественные продукты получаются только у тех команд, все участники которых глубоко вовлечены в процесс. Дизайнер не нарисует гениальный дизайн, если для него не очень важно, что выйдет в итоге. Разработчик не будет дотошно воплощать дизайн и биться над удобством интерфейса, если он просто «выполняет работу за деньги». Тестировщик может формально проверить задачу по чек-листу и не обратить внимания на недоработки, которые не были прописаны в нем. Ваша задача как руководителя — помогать участникам процесса проникнуться задачей.
Есть множество методов, как к этому прийти. Вы можете завести традицию приглашать разработчиков на беседы с пользователями. Можете коллективно разбирать жалобы из службы поддержки. Наконец, можете просто на общих собраниях перед большим количеством людей подчеркивать важность проекта — это тоже помогает повысить заинтересованность.
О необходимости вовлекать людей в процесс очень много пишет Эд Кэтмелл, основатель компании Pixar. В качестве иллюстрации он приводит историю, перевернувшую с ног на голову промышленность в Японии. Компания Toyota в сотрудничестве с американским консультантом Эдвардсом Демингом первой внедрила систему, в которой каждый работник конвейера по сборке автомобиля мог в любой момент его остановить и высказаться по поводу того, что пошло не так.
«Подход Деминга — и Toyota — наделил ответственностью за качество продукта сотрудников, активнее всего вовлеченных в его создание. Люди начали относиться к продукту как к чему-то личному. В дополнение к простому повторению одних и тех же действий на конвейере работники могли предлагать изменения, поднимать проблемы и (этот следующий элемент кажется мне особенно важным) испытывать гордость за свой вклад в совершенствование производства по всему миру.
В процессе запуска Pixar идеи Деминга служили для меня маяком».
Чем лучше каждый участник команды понимает, каким должен быть конечный результат, тем больше неожиданных и очень ценных подсказок вы будете получать по ходу работы. Разработчики будут находить неудобства в интерфейсе, дизайнеры — придумывать оптимально подходящие решения.
Попробуйте организовать регулярные встречи, на которых будут встречаться люди, занимающиеся разными аспектами одного проекта, — раз в неделю или две собирать вместе дизайнеров, тестировщиков, разработчиков и других заинтересованных людей. Замечательно, если часть решений по проекту команда будет принимать совместно, — например, дизайнеры будут советоваться с разработчиками по поводу дизайна.
Бывают проекты, на которых встречи организовать не выйдет, — например, разработка ведется по принципу конвейера и команда просто не может себе позволить обсуждать каждую задачу. В этих ситуациях можно пробовать организовать переписку дизайнеров и разработчиков или писать письма-статусы, в которых сообщается об успехах проекта и отмечаются заслуги всех его участников. В идеале все должны воспринимать проект как важный для себя. Тогда не захочется делать работу некачественно.
Еще один положительный побочный эффект при такой организации работы заключается в том, что один человек с горящими глазами может «зажечь» всех остальных. Очень сложно оставаться равнодушным к задаче, если ты видишь, что коллега воодушевлен и старается сделать все как можно лучше.
В названии главы я противопоставила неравнодушных исполнителей аутсорсерам. Стоит сказать пару слов в защиту аутсорса. Во-первых, есть большое количество задач, где не требуется сильное погружение людей в проект. Вы можете просто и понятно написать техзадание, и в таких ситуациях аутсорс — отличный выход. Во-вторых, многие сотрудники или целые команды, работающие на аутсорсе, заключают договор на несколько лет. За это время люди успевают влиться в проект и затем работают наравне со штатными сотрудниками (а то и лучше). Решение отдать задачу на аутсорс может быть неудачным, если время, требующееся на погружение нового человека в контекст задачи, несоизмеримо больше, чем время, отведенное на ее выполнение. В остальном различий не так много.
