Общение с заказчиком: переходим на язык задач и проблем

Прежде чем приступать к решению задачи, грамотный проектировщик должен сначала её поставить...

Мне часто приходилось слышать о том, что неправильный дизайн системы существенно увеличивает затраты на разработку. Это действительно так. Думаю, немногие попытаются опровергнуть данное утверждение. Согласно моему опыту неправильная архитектура может увеличить затраты на 50, 80 и даже 90 процентов.

Такой перерасход бюджета является серьёзной проблемой, но не катастрофой. Последствия плохой архитектуры могут быть частично скомпенсированы хорошим менеджментом (== грамотным распределением задач) и, наоборот, плохой менеджмент может быть частично скомпенсирован хорошим дизайном. Почему? Потому что хороший дизайн вызывает меньше проблем и, как следствие, уменьшает нагрузку на менеджера.

Более страшной – в плане затрат– является неправильная постановка задачи. Потому что она увеличивает расходы в разы. (Запросто может увеличить бюджет в 2, в 3 и даже в 4 раза.) Здесь я имею в виду ситуацию, когда разработчики делают не то, что клиенту нужно, а реализуют то, что клиент говорит.

Существует большая разница между:

• проблемой и тем, что клиент думает о ней;
• решением проблемы и решением, которое клиент себе представляет.

Клиент, как правило, не является специалистом в программировании. Нередко он по складу ума вообще не технарь, а гуманитарий. Поэтому странно от него ожидать, что он сформулирует задачу в виде, пригодном для технического воплощения.

Часто описание проблемы, полученное от клиента, представляет собой не описание задач, которые технический специалист должен решить, а описание "решений" этих задач.

Приведу пример. При работе над консольной игрой для маленьких девочек под Nintendo Wii продюсер со стороны издателя настаивал, чтобы разработчики активно использовали возможности контроллеров Remote и Nunchuk. В одной из мини-игр он вообще пожелал использовать 8 различных движений этими контроллерами.

По мнению разработчиков такое разнообразие было нецелесообразно, потому что:

1)      технологически сложно распознать все 8 движений (сложно отличить одно движение от другого, т.к. некоторые движения были похожи);

2)      девочки просто запутались бы в этих движениях (8 движений – это слишком много), а игра была на скорость.

Стали разбираться. Получился вот такой диалог с заказчиком:

Технический специалист: Зачем Вам понадобилось столько много движений?

Заказчик: Потому что так прикольнее.

Технический специалист: Вы не думаете, что это будет сложно для маленьких девочек.

Заказчик: Нет. Но даже если и будет немного сложно, то так будет веселее.

Технический специалист: Т.е. Вам нужно, чтобы игра была веселее?

Заказчик: Разумеется, иначе в неё не будут играть ни дети, ни родители.

Технический специалист: Таким образом, Вам нужно, чтобы в игру играли и дети, и родители? Это Ваша настоящая цель?

Заказчик: Да, пожалуй, так.

Технический специалист: Тогда давайте будем решать настоящую задачу – чтобы в игру играли и взрослые, и дети, а про контроллеры и их движения пока забудем. Пусть наш гейм-дизайнер подумает, как решить Вашу задачу, и предложит возможные варианты. А Вы потом выберете.

Заказчик: Звучит разумно. Но я бы всё-таки активнее использовал возможности Wii Remote'а и Nunchuk'а.

Технический специалист: Хорошо, наш гейм-дизайнер учтёт это пожелание.

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

Если бы технические специалисты не выяснили настоящую цель заказчика, а стали бы реализовывать то, что он попросил, то были бы впустую потрачены время и деньги.

После реализации Заказчик увидел бы, что его идея не работает и попросил бы переделать уже сделанную работу. Скорее всего, он не поставил бы под сомнение качество своей идеи, а решил бы, что программисты её неудачно реализовали. Далее он предлагал бы поменять движения или же переписать код их распознавания, предлагал бы менять сочетания движений, но не отказывался бы от своей идеи. В результате, целая команда людей (программисты, художники, гейм-дизайнер, продюсер) работала бы впустую. Только для того, чтобы реализовать некачественную идею.

Хороший проектировщик должен отсекать такие идеи на этапе постановки задачи.

Стратегически важно при общении с заказчиком переводить описание проблемы с языка конкретных решений на язык задач и проблем. Для этого нужно не стесняться задавать вопрос "Зачем?".

Типовой диалог с заказчиком тогда выглядит так:

- Хочу, чтобы в Вашем шутере мишени были постоянно навиду.

- Зачем?

- Чтобы игрок не мог их перестрелять.

- Зачем?

- Чтобы игрок, перестреляв все мишени, не ждал, пока появятся новые.

- Иными словами, проблема в значительном времени ожидания появления новых мишеней?

- Да.

- Хорошо. Мы поняли проблему. У нас мишени появляются медленно, потому что аниматор сделал слишком длинную анимацию их появления. Мы уменьшим анимацию, и мишени станут появляться гораздо быстрее.

- Договорились. Сделайте так.

Литература:

1. В. М. Герасимов, В. С. Калиш, М. Г. Карпунин, А. М-. Кузьмин, С. С. Литвин. Основные положения методики проведения функционально-стоимостного анализа: Методические рекомендации. - http://worldquality.ru/pages/print/30.html
2. Сычёв С.В. Элекронный кейс "Алгоритм решения маркетинговых и рекламных задач "Рекламное Измерение". Версия 2010.1.7. - http://www.triz-ri.ru/ri-school/case-ri.asp