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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

    Кирилл Гришанин

    Кирилл Гришанин

    Последние 10 лет руковожу командой аналитиков, дизайнеров и разработчиков.

    🇮🇱 Israel http://wbtech.ru/