Три варианта развития событий
Некомпетентный заказчик — это хорошо
Предпроектное исследование
Вывод
Проблема коммуникации между заказчиком и исполнителем стара как мир. Заказчик считает, что исполнитель делает не то, а исполнитель считает заказчика дураком, который не знает элементарных вещей. Сводится все простыми вопросами взаимодействия — как контролировать команду и как наладить коммуникацию, чтобы проект случился.
Я поделюсь личным опытом со стороны команды разработки и расскажу, как общаться с заказчиком, чтобы все были довольны (но это не точно).
Три варианта развития событий
Когда заказчик работает с командой на аутсорсе, он хочет знать, как ее контролировать. Это и хорошо, и плохо. Плохо потому, что заказчики, задающие вопрос «Как я буду вас контролировать?», скорее всего, привыкли создавать себе излишние сложности в работе. Здесь важно понять, почему они спрашивают про контроль.
- Часто заказчик не приемлет аутсорс как таковой, но вынужден к нему обратиться. Человек предполагает, что команду можно контролировать, только посадив в офис.
- Заказчик думает, что разработка — это ключевая компетенция, которую передавать никак нельзя. Но это не так. Одно дело, когда идет разработка инновационной технологии или сервиса, другое — когда в проекте используются уже созданные технологии. В этом случае можете спокойно аутсорсить.
- Самый, пожалуй, мудрый заказчик — тот, кто не может принимать факты без объяснений. Ему важно не просто контролировать команду, а попытаться понять процесс. Таким людям — способным критически мыслить, анализировать информацию и выбирать рациональный для себя путь, будет полезен этот текст. Хорош вопрос о контроле тем, что разумным способом и определенными действиями контролировать аутсорс-разработку несложно.
Некомпетентный заказчик — это хорошо
Когда заказчик спрашивает, как проверить вашу работу, он показывает, что не разбирается в услуге и не понимает, как ее принять. Это нормально.
Более того — это не просто нормально, а если хотите, хорошо. Есть важный нюанс: хорошо не потому, что заказчика легко надуть, а потому, что вы в состоянии закрыть его боли. Иначе какой смысл в работе, если он все может сделать за вас?
Главная задача исполнителя сводится к тому, чтобы во время проекта заказчик из некомпетентного превратился в компетентного. Если он с каждой встречей все больше понимает, как устроена разработка — вы все делаете правильно.
Вы должны научить заказчика правильно принимать результат и потом им пользоваться, не садясь на иглу зависимости от аутсорсеров. Мы в начале проекта тратим много времени на такое «образование», подробное объяснение всего. Это долгосрочная инвестиция, но когда через год работы заказчик предлагает прототип нового экрана, который можно сразу передавать в дизайн без длительного обсуждения, — вам засчитывается профит.
Не путайте некомпетентность заказчика в определенной услуге с его некомпетентностью вообще. Если он не является специалистом в своей предметной области, и/или не ведет дела профессионально — проект не получится.
Предпроектное исследование
Ощущение заказчика «все понятно», созданное в начале проекта, с ходом проекта должно только расти. Если вдруг он что-то не понимает, то после диалога с исполнителем, это непонимание должно улетучиться.
И это понимание — тот самый контроль аутсорс-разработки.
На первых встречах аутсорсеры должны показать себя экспертами в сфере, которые благодаря своему опыту решат задачи заказчика. Первое, за чем надо проследить — сходится ли у всех понимание, что будет результатом проекта. Для этого мы проводим предпроектное исследование и выясняем, каким должен быть проект.
Даже если вы делаете небольшой сайт из 5 страниц, то все равно сначала нужно понять, зачем вы его делаете, почему он будет таким, а не другим. Неважно, что это будет — черно-белый прототип, кликабельный прототип, текстовый документ, все вместе — заказчику должно быть понятно, какие страницы будут у сервиса, как по ним будет перемещаться пользователь и так далее.
Вопросы от команды — та самая экспертиза, которая нужна заказчику. Они помогают команде формализовать видение самого заказчика. Вопросы не просто изучают проект, но и влияют на него. Иногда меняют архитектуру бизнеса, могут спровоцировать изменение бизнес-модели. Вопросы — это нормально.
Вывод
Не нужно думать, что детальное изучение сделает любую идею 100% прибыльной. Команда разработчиков — не акселератор, не ментор, она не может быть гарантом верности бизнес-идеи заказчика. Нужно понимать, как и когда аутсорсить разработку и как контролировать собственную IT-команду. Команда несет ответственность только за продукт и его корректную работу.
Читайте далее — Эпизод II: рабочий процесс.
