20 июля 2011 г.

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

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

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

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

7 июля 2011 г.

Книга месяца: «Исповедь оратора», Скотт Беркун

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

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

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

Итак, о чем же она?