Заказчик и аутсорс — как перестать контролировать мониторы и начать эффективно работать

Заказчик и аутсорс — как перестать контролировать мониторы и начать эффективно работать

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

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

Три варианта развития событий

Когда заказчик работает с командой на аутсорсе, он хочет знать, как её контролировать. Это и хорошо, и плохо. Плохо потому, что заказчики, задающие вопрос «Как я буду вас контролировать?», скорее всего, привыкли создавать себе излишние сложности в работе. Здесь важно понять, почему они спрашивают про контроль.

  1. Часто заказчик не приемлет аутсорс как таковой, но вынужден к нему обратиться. Человек предполагает, что команду можно контролировать, только посадив в офис.
  2. Заказчик думает, что разработка — это ключевая компетенция, которую передавать никак нельзя. Но это не так. Одно дело, когда идёт разработка инновационной технологии или сервиса, другое — когда в проекте используются уже созданные технологии. В этом случае можете спокойно аутсорсить.
  3. Самый, пожалуй, мудрый заказчик — тот, кто не может принимать факты без объяснений. Ему важно не просто контролировать команду, а попытаться понять процесс. Таким людям — способным критически мыслить, анализировать информацию и выбирать рациональный для себя путь, будет полезен этот текст. Хорош вопрос о контроле тем, что разумным способом и определёнными действиями контролировать аутсорс-разработку несложно.

Некомпетентный заказчик — это хорошо

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

Более того — это не просто нормально, а если хотите, хорошо. Есть важный нюанс: хорошо не потому, что заказчика легко надуть, а потому, что вы в состоянии закрыть его боли. Иначе какой смысл в работе, если он всё может сделать за вас?

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

Вы должны научить заказчика правильно принимать результат и потом им пользоваться, не садясь на иглу зависимости от аутсорсеров. Мы в начале проекта тратим много времени на такое «образование», подробное объяснение всего. Это долгосрочная инвестиция, но когда через год работы заказчик предлагает прототип нового экрана, который можно сразу передавать в дизайн без длительного обсуждения, — вам засчитывается профит.

Не путайте некомпетентность заказчика в определённой услуге с его некомпетентностью вообще. Если он не является специалистом в своей предметной области, и/или не ведёт дела профессионально — проект не получится.

Предпроектное исследование

Ощущение заказчика «всё понятно», созданное в начале проекта, с ходом проекта должно только расти. Если вдруг он что-то не понимает, то после диалога с исполнителем, это непонимание должно улетучиться.

И это понимание — тот самый контроль аутсорс-разработки.

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

Даже если вы делаете небольшой сайт из 5 страниц, то всё равно сначала нужно понять, зачем вы его делаете, почему он будет таким, а не другим. Неважно, что это будет — черно-белый прототип, кликабельный прототип, текстовый документ, всё вместе — заказчику должно быть понятно, какие страницы будут у сервиса, как по ним будет перемещаться пользователь и так далее.

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

Вывод

Не нужно думать, что детальное изучение сделает любую идею 100% прибыльной. Команда разработчиков — не акселератор, не ментор, она не может быть гарантом верности бизнес-идеи заказчика. Нужно понимать, как и когда аутсорсить разработку и как контролировать собственную IT-команду. Команда несёт ответственность только за продукт и его корректную работу.

Читайте далее — Эпизод II: рабочий процесс.