Источник требований: не пользователь, а здравый смысл

Компьютеры и программное обеcпечение призваны служить людям. Приложение «Калькулятор» помогает складывать и умножать, Фейсбук делает доступными тусовки, игровое ПО развлекает, операционные системы делают возможным запуск калькуляторов, фейсбуков и игр. Большой пласт софта — заказной корпоративный, предназначенный для решения задач на конкретном предприятии. Я сам работаю на производстве такого корпоративного софта.
Как же понять, каким должен быть софт? Откуда взять характеристики, требования для построения софта? Многие разработчики отвечают на этот вопрос так: надо спросить пользователей, чего они хотят. В данной статье попытаюсь разобраться, почему проектирование из-под пользователя не работает.

Разработку ПО часто сравнивают с производством автомобилей. Эта область многим близка и понятна: на машинах ездят все, все знают что это сложное техническое устройство. Есть в этой аналогии большая ошибка: соотношение процессов проектирования и построения автомобиля не соответствует этому соотношению для ПО. Проектирование составляет почти 100% трудозатрат в производстве софта, все построение делается по большей части автоматически (написание кода я также отношу к проектированию, но более низкоуровневому). В дополнение к этому, софт может гораздо быстрее реагировать на обратную связь. Это значит, что последствия ошибок проектирования не такие тяжелые, как на производстве машин.
В одном есть сходство: машины также призваны служить людям. Продолжим рассуждать в аналогии с машиностроением, но с оговорками, обозначенными выше.

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

Положим, некая компания «Мое окно» занимается наружной мойкой окон зданий. Руководитель компании подсчитал, что эффективность вырастет вдвое, есдт мойку осуществлять не вручную, а с помощью машин, которые будут подниматься на нужную высоту и тереть щетками по стеклу. То есть, можно будет уволить половину сотрудников. Он пришел в компанию «Рога и колеса», имеющую опыт в подобных проектах. Договорились, что машина будет устанавливаться на ножках и подниматься на высоту нескольких этажей. Мойщик будет сидеть в кабине и управлять процессом мойки и ополаскивания. Заключили контракт.

Проектировщики компании «Рога и колеса» на первом этапе придумали концепцию, приняли базовые архитектурные решения, такие как способ крепления и подъема кабины. Придумали название проекта: «Кузнечик». Нужно было переходить к деталям, проектировать основной функционал и интерфейс мойщика.
Разработчики в мойке окон шарили как свиньи в апельсинах и отдавали себе отчет в этом. Значит, нужно прийти к мойщику и спросить, а что бы ты хотел видеть в Кузнечике. Пошли.

Представим себя на месте мойщика. Он долго работал руками, приноровился, делает свою работу быстро и четко, практически на автомате — долгая практика. Тут пришли разработчики менять процесс. Спрашивают, что он хочет изменить. Да ничего! Чтоб платили больше! Ходят слухи, что после успешного внедрения проекта сократят половину штата. Не стоит пояснять, в каких отношениях мойщик хотел бы состоять с этим Кузнечиком. А радостный сотрудник «рог и колес» говорит: «а давай-ка ты, мойщик, еще и поможешь делать нам нашу работу». Окей! С чего начнем?

— Какие инструменты вы бы хотели видеть в своем интерфейсе?
— Для начала мне нужен люк в лобовом стекле.
— ???
— Ну а как я по-вашему швабру буду к окну просовывать? Через дверь?

Смешно, а ведь для многих разработчиков этого достаточно. Они ринутся делать люк, а когда спросишь: «зачем?» с безмятежностью ответят: «Это элементарно. Чтобы мойщик мог просунуть швабру». Это несмотря на то, что по задумке машина должна делать все сама, а мойщик — только на кнопочки нажимать.

Генри Форд говорил: если бы я спросил своих покупателей, а что им нужно, то они бы ответили: «более быстрых лошадей». Что касается данного примера, то люк в лобовухе может быть и нужен, а может и нет, но одно ясно: нельзя проектировать функциональность лишь на основании требований пользователя. Узнавайте цели, цели которые стоят за этими целями, и так до тех пор, пока сами не осознаете весь смысл.

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

— Что должно быть на панели приборов Кузнечика?
— Нуу часы, наверное…
Вспомнит ли мойщик, что ему нужен будет уровень моющих средств, если раньше он всегда мог определить его, посмотрев на банку в руке? Вспомнит ли про заряд аккумуляторов? Топливо? Силу ветра, чтоб Кузнечик не грохнулся с высоты? Может быть и вспомнит, но нельзя от него этого требовать. Технические тонкости лучше представит именно разработчик. Согласование с пользователем — да, необходимо. Но на вопрос «что должно быть?» пользователь отвечать не обязан.
— Какое должно быть кресло?
— Конечно, мягкое кожаное. Да. И с этим… с массажем. Как в торговых центрах стоят же, по 10 рублей. Это необходимо для работы. Да, и еще магнитолу. Как работать без музыки? Обязательно чтоб вещало узбекское радио.

Одобрит ли владелец компании эти затраты? Действительно ли это поможет процессу мойки? Может быть. Опрос второго мойщика показал, что ему магнитола не нужна. И тут рождается гениальная мысль у разработчтка: а давайте сделаем это опцией! Пусть будет выдвижная панель, которая удобно прячется под приборку.
Алло, ребята! Деньги (стоимость разработки) кто-то считает? Делать магнитолу в кабине Кузнечика дорого, делать её опцией сборки дороже, делать её опцией рантайма — ещё дороже. А пользы от нее?

Многие разработчики живут под лозунгом «make user happy» и забывают, кто в конечном итоге платит деньги. Нет, о юзерах думать, конечно, надо, но в первую очередь «make customer rich», а потом уже «user happy», и только если второе не противоречит первому.

Допустим, мойщик и вытиральщик — разные люди. Работает бригада: три мойщика, один вытиральщик. Провели интервью, выяснили, что инструменты для работы того и другого имеют сходства и отличия. Решили: напхать все в одну панель, пусть каждый смотрит в свой угол и пользуется тем, что нужно именно ему. До кучи вывели показания десятка датчиков: для технического обслуживания специалистами компании «Рога и колеса». Здесь другая крайность. Заваливать людей, которые не обременены инженерными знаниями и тонкостями чужой работы — преступление. Об этом говорят все книжки по юзабилити. Возможно, если вы будете беседовать с пользователем, он вам перечислит все инструменты, которые могут ему понадобиться, чтобы ничего не упустить. Но это не значит, что все эти инструменты равнозначны. Вспомните панели приборов в автомобилях: спидометр всегда крупнее, чем одометр, но будете ли вы об этом упоминать, отвечая на вопрос «что вы хотите видеть на панели?»

Итак, выводы.

1. Нельзя оставлять пользователя единственным генератором идей. Думайте за него, пытайтесь представить себя за штурвалом Кузнечика, предлагайте варианты — выбирать всегда проще.
2. Помните, что пользователь не знает об особенностях конструкции.
3. Все, что будет предложено пользователем, нужно пропустить через призму здравого смысла: оценку полезности и стоимости реализации, соответствия целям проекта.
4. Опции = деньги. Чем больше опций и гибкости, тем дороже проект.
5. Разные инструменты требуют разного внимания, не стоит превращать машину для мойки окон в космический корабль, спрячьте все, что будет отвлекать.

Я ни в коем случае не призываю отказаться от общения с пользователями и заказчиками! Разговаривать нужно, все дело в постановке вопроса. Не «что должно быть», а «расскажите, как вы это делаете», «подойдет ли наш вариант для вашей работы» и сто раз «почему».