20 июля 2011 г.



Анализируй это!

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

Все это очень хорошо, все при деле. Однако, на мой взгляд, есть одно большое НО. Зачастую мы забываем проанализировать конкретные потребности пользователя. Заметьте, не требования, которые он сам нам выставил, а именно его потребности, как человека, который каждый день будет использовать ваше приложение. Какая разница? Она есть. Требование к приложению (особенно функциональное) может звучать так (утрированно): «У нас тут есть вот такие документы и продукты, надо бы их между собой связать, да еще и с возможностью удобного поиска и сортировки». В это же время, потребностью пользователя может быть нечто другое: «Хочу пораньше уйти домой, поэтому мне надо просто выбрать кучу документов с одной стороны, кучу продуктов с другой, нажать красную кнопку и завтра утром получить отчеты в нужной мне и удобной для анализа форме». Или, например, что-нибудь такое: «Во всех документах есть свои нюансы. Было бы очень круто, если бы программа подсвечивала мне только те из них, которые мне нужны в данный момент». Другими словами, придумать можно много чего. Особенно если организация большая и пользователей много.

Чтобы зарубить на корню возражения и проклятия в мой адрес, скажу: да, я знаю про существование специальных людей, специалистов по взаимодействию пользователя с приложением, специалистов по юзабилити и построению интерфейсов пользователя. Они все замечательные и очень нужные люди. Однако на данный момент специфика нашей работы (по крайней мере в наших региональных белорусских широтах) такова, что подобных специалистов на проекте чаще всего просто нет. Причин тому может быть много, очень разных, но большинство их них сосредоточено в плоскости (не)понимания существующей проблемы. Начиная от непонимания начальством полезности таких специалистов (зачем тратить еще кучу денег на их содержание?) до банальной нехватки бюджета ввиду, например, жадности или излишней осторожности заказчика.

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

Каков же выход из созданной мной только что ситуации? :-)

Мне кажется, что выход довольно очевиден. Распределить роль специалиста по проектированию взаимодействия по проектной команде. Но прежде, конечно же, необходимо прийти к пониманию важности такой роли (понятно, что не везде она нужна, но давайте не будем говорить о таких проектах, все же их меньшинство).

В понимании проблемы важную роль играет менеджер проекта и тим-лид(ы), которые могут стать проводниками для своей команды. Поэтому начнем с них.

Так как эти люди ближе всего находятся к заказчику, то они много чего могут сделать. Во-первых, можно разъяснить заказчику важность работы по проектированию взаимодействия. Во-вторых, можно попробовать составить портрет типичного пользователя, выбив всю эту информацию из заказчика. В-третьих, можно предложить проектной команде необходимые ориентиры и ценности (первоначально объяснив их важность и необходимость и удостоверившись, что все вас понимают), руководствуясь которыми команда будет разрабатывать более качественный во всех отношениях программный продукт. Короче говоря, важный узел всего проекта. Если не будет нужного отношения к проблеме здесь, то его не будет нигде.

Что анализировать на этом уровне? Понятно, что для начала менеджеру нужно проанализировать насколько работа по проектированию взаимодействия нужна как приложению, так и пользователям. Мало ли, вы разрабатываете консольную утилитку для пары-тройки убежденных линуксоидов, которые так ненавидят любые окна, что предпочитают жить в подвале :-) После этого нужно проанализировать заказчика, попытаться просчитать его возможное отношение к проблеме и соответственно подготовиться. Ну и заодно проанализировать возможности применения потенциального опыта проектирования взаимодействия в других проектах.

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

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

Можно, конечно, сказать, что разработчикам это не по плечу. Сидят себе таки гики и что-то там колупаются, произнося время от времени матерные заклинания. Не поддавайтесь на этот миф! Хорошему специалисту по разработке ПО должно быть по плечу решение вопроса о взаимодействии приложения и пользователя. Только на более низком уровне, нежели для менеджера или тим-лида.

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

Поэтому разработчику, архитектору или тестировщику достаточно помнить, что приложением будет пользоваться живой человек. Человек, у которого есть человеческие потребности. И мы их хорошо знаем и можем анализировать. Просто часто забываем это делать. А ведь иногда достаточно просто представить себе, как именно пользователь будет решать проблему с помощью части приложения, которую ты еще только собираешься разрабатывать. Велик соблазн просто выполнить поставленные требования и удостовериться, что программа работает корректно. Забыть о ней и взяться за следующую. Что сделает пользователь? Правильно, тоже самое - забудет о вашем приложении и возьмется за следующее. Однако стоит только сделать немного больше и появляется шанс создать такой продукт, от которого получат удовлетворение не только разработчики но люди, ради которых все затевалось, - пользователи.

Несколько скомкано, но во время июльской жары по-другому не получается. Мысли так и норовят разбежаться в стороны :-) Спасибо за внимание и понимание!





Понравилось сообщение - подпишитесь на блог Подписка на блогFollow grodnosoft on Twitter




Читайте также:


Комментов: 0

Отправить комментарий