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

March 16 2023
Три варианта развития событий
Некомпетентный заказчик — это хорошо
Предпроектное исследование
Вывод

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вывод

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

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

Автор статьи
Кирилл Гришанин
Последние 10 лет руковожу командой аналитиков, дизайнеров и разработчиков

Подпишитесь на блог WB—Tech

Никакого спама, только анонсы новых статей

    Последние статьи

    Миграция внутренних пользователей Jira в новую директорию с сохранением данных об активности

    Рассказали, как осуществили перенос пользовательских данных из Jira (Internal Directory) в директорию Microsoft Active Directory.

    Как эффективно хранить и актуализировать корпоративные данные средствами low/no-code

    Рассказали, как организовали поток HR-данных, чтобы оргструктура и бонусно-бухгалтерские расчеты всегда были актуальны.

    Мало кода, больше результативности: платформы low-code и no-code

    О low-code и no-code платформах, примерах использования и разбор нужно ли быть программистом.

    ИП Гришанин Кирилл Олегович
    ИНН 774313842609

    Коворкинг Starthub

    Б. Новодмитровская ул., 36, стр. 12, вход 6,
    Москва, Россия, 127015

    Коворкинг Wework

    Ahad Ha'am 54,Tel Aviv-Yafo,Израиль

    © 2023 WB—Tech. Мы разрабатываем уникальные решения для компаний из России, США и Европы.