Эндрю Хант - Программист-прагматик. Путь от подмастерья к мастеру

Различия между требованиями, политикой и реализацией могут быть весьма размытыми, если речь идет о пользовательских интерфейсах. Слова «Система должна давать возможность выбора срока предоставления ссуды» представляют собой формулировку требования. Выражение «Для выбора срока предоставления ссуды необходимо окно списка» может являться формулировкой, а может таковой и не являться. Если пользователям позарез нужно окно списка, то в этом случае речь идет о требовании. Если же вместо этого они описывают свою способность выбирать, используя окно списка лишь в качестве примера, то здесь говорится не о требовании. Врезка ниже «Когда интерфейс становится системой» описывает проект, который пошел совсем не в ту сторону, поскольку потребности пользователей в интерфейсе были проигнорированы.

Важно обнаружить основополагающую причину того, почему пользователи поступают определенным образом, а не так, как они привыкли это делать. В конечном итоге разрабатываемой программе придется решать проблемы их бизнеса, а не просто отвечать их заявленным требованиям. Документируя причины, по которым были выдвинуты требования, команда разработчиков получит бесценную информацию, необходимую для принятия ежедневных решений, связанных с реализацией.

Существует простая методика: чтобы взглянуть изнутри на требования (которые часто являются весьма недостаточными) ваших пользователей, нужно самому стать пользователем. Пишете систему для службы поддержки? Посидите пару дней на телефоне вместе с опытным сотрудником этой службы. Занимаетесь автоматизацией ручной системы управления складскими запасами? Поработайте на складе с неделю [41] Неделя – это долго или нет? На самом деле нет, особенно если рассматривать процессы, в которых менеджмент и исполнители находятся в разных мирах. Менеджмент дает одно представление о том, как все работает, но как только спускаешься в цех. то встречаешься с иной реальностью, для адаптации к которой требуется время. . Вы получите представление о реальном использовании системы и вдобавок будете просто поражены тем, насколько просьба «Можно я посижу рядом с вами недельку и посмотрю, как вы работаете?» способствует доверию и закладывает основы ваших взаимоотношений с пользователями. Но не путайтесь у них под ногами!

Подсказка 52: Работайте с пользователем, чтобы мыслить категориями пользователя

Добыча полезных требований важна – в это время начинают складываться связи с вашим пользовательским ядром, изучаются их ожидания и надежды на создаваемую вами систему. Более подробно это обсуждается в разделе «Большие надежды».

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

Ивар Джекобсон [Jac94] предложил концепцию «сценариев использования системы» для фиксирования требований. Они позволяют описывать частные случаи использования системы не с точки зрения пользовательского интерфейса, а в более абстрактном виде. К сожалению, книга И. Джекобсона несколько расплывчата в деталях, поэтому в настоящее время не существует единого мнения о том, что же считать «сценарием использования системы». Что это – формальный или неформальный термин, прозаический или структурированный документ (подобный канцелярской форме)? Каким должен быть уровень детализации (помните, что у нас весьма широкая аудитория)?

В своей статье (журнал «Wired», январь 1999, с. 176) продюсер и музыкант Брайан Иноу описал чудо техники – новейший микшерный пульт. Этот пульт заставляет звучать все, что в принципе может звучать. И все же, вместо того, чтобы помочь музыкантам в создании лучших произведений или ускорить (или удешевить) процесс записи, он «путается под ногами», нарушая творческий процесс.

Чтобы понять, почему это происходит, необходимо взглянуть на работу инженеров студии звукозаписи. Они сводят звук интуитивно. За годы работы в студии у них вырабатывается врожденный цикл обратной связи между ушами и кончиками пальцев, управляющих плавно движущимися регуляторами, вращающимися ручками и т. д. Однако компьютерный интерфейс нового микшерного пульта не усиливал их способностей. Вместо этого он заставлял пользователей набирать текст на клавиатуре и/или щелкать мышью. Функции, обеспечиваемые этим интерфейсом, были универсальными, но они были скомпонованы неизвестными и экзотическими способами. Функции, необходимые инженерам в их работе, иногда скрывались за невразумительными названиями или же достигались за счет неестественных сочетаний базовых средств.