О том как мыть слонов и делать настоящие вещи
Дата публикации: 29/04/2010Собственно говоря, речь сейчас пойдет о двух книгах, которые стараются сделать жизнь удобнее. По крайней мере жизнь web-разработчика, хотя принципы изложенные в них вполне подходят и для других видов деятельности.
Первая книга называется "Как мыть слона" и написана Владом Головачевым. Со слонами какая проблема? Неизвестно с чего начать процесс мытья и как определить момент когда он уже вымыт. Эту цитату я взял из первого абзаца книги в которой данный вопрос применяется и по отношению к созданию удобных сайтов. Но что значит удобный? Это такое достаточно растяжимое понятие о котором у каждого может быть собственное мнение. Гораздо продуктивнее говорить о составляющих юзабилити, таких как время решения задачи или скорость ввода данных, например. Об этих вещах, а главное об определенных методиках и ведет разговор автор книги.
Книга издана в PDF-формате и свободно выложена на одноименном сайте для всех желающих. Книга не очень большая - чуть меньше 100 страниц в формате экранных слайдов. И при вдумчивом чтении у вас вряд ли уйдет на нее больше пары часов, но это стоит того.
Вторая книга это перевод английского издания книги "Getting Real", которая написана сотрудниками команды "37signals", известной в первую очередь своим фреймворком для создания сайтов "Ruby On Rails", а также рядом популярных web-приложений. Авторы этой книги придерживаются сходной концепции по распространению информации, что и предыдущий автор. Поэтому можно купить бумажную книгу, если вы любите читать таким образом, но сам текст полностью доступен он-лайн и поощряется ее перевод на другие языки. Благодаря последнему обстоятельству и появилась русская версия. Правда должен сказать, что в некоторых местах перевод достаточно корявый, но содержание искупает перевод.
Авторы "Getting Real" излагают свою философию создания web-приложений направленную на быстрое достижение результатов. Сравнение происходит с традиционным "коробочным ПО" и показывается основное его отличие от динамических web-приложений. В данном случае под словом "динамические" понимается скорее возможность очень быстро изменяться. Если в классическом приложении требуется ждать новой версии программы или обновления, чтобы появилась нужная вам возможность или была исправлена найденная ошибка, то в web-приложении это можно сделать гораздо быстрее.
Подход "Getting Real" призывает запускать проект с минимум функциональности и смотреть как люди им будут пользоваться. Лучше сделать хорошо всего несколько важных функций и выпустить приложение сейчас, нежели пытаться предусмотреть все что только возможно и выпустить его через год. Разница между двумя этими подходами заключается еще и в том, что в первом случае вы быстрее узнаете реальные потребности пользователей и увидите свои ошибки. А это значит, что и исправить их можно будет быстрее или даже пересмотреть некоторые концепции своего web-приложения.
Основной достигаемый выигрыш здесь - вы не тратите свое время и силы на реализацию тех возможностей, которые в конце-концов никому не будут нужны. Точнее говоря, не будут нужны вашей аудитории и об этом тоже идет речь в книге. В конце-концов, не нужно пытаться угодить всем - это еще никому не удавалось, а попытки сделать это приводят обычно к раздутому ПО, которое посредственно реализует каждую из предлагаемых функций. Гораздо лучше четко определить свою аудиторию и сделать простое приложение которое будет очень хорошо решать одну, но важную задачу.
Небольшое приложение гораздо проще освоить, а значит и больше людей захотят им воспользоваться. И если вы угадали с потребностями, то к моменту достижения определенной популярности, пользователи сами подскажут вам что именно им не хватает. Но самое важное, что к тому моменту вы сами уже будете иметь собственное видение и знать что делать дальше.
В подходе "Getting Real" важно принять аксиому, что в конце-концов все придется переделывать. Просто по той простой причине, что когда вы только начинаете создавать проект, вы обладаете минимум информации и ваши решения не будут идеальными. Иногда проще и быстрее создать черновой прототип и посмотреть его в работе, нежели подробно разрабатывать сложное техзадание и устраивать многочасовые встречи. Это не значит, что не нужно проектировать приложение, но это значит, что не нужно решать множество несущественных проблем прежде чем будет создано основное функциональное ядро.
Начните с интерфейса - возьмите лист бумаги, карандаш и попробуйте нарисовать как может выглядеть ваше web-приложение. Это просто и быстро, а кроме того идея перенесенная на бумагу способствует дальнейшему ее развитию. Идею уже можно будет показать коллегам и обсудить ее. Пока что-то находится в вашей голове никто точно представить ее не может - другое дело эскиз. И если вы уже примерно знаете что нужно, то сверстайте макет, используя HTML и CSS. Пока не нужно никакого программирования - просто создайте два-три базовых экрана, но которыми уже можно будет пользоваться. В конце-концов, люди будут видеть именно этот интерфейс и оценивать приложение будут основываясь на нем. Если что-то будет неудобно и непонятно, то переделать интерфейс на уровне статической страницы будет гораздо проще. И не придется переписывать уже созданный программный код. Согласитесь, что это более продуктивный подход.
Решайте проблемы пользователей, но имейте свой взгляд на вещи. Пишите программы для себя - это более важно, чем кажется на первый взгляд. И умейте говорить "нет" различным пожеланиям и улучшениям, которые предлагают пользователи. По крайней мере, вы должны сказать "нет" на первое предложение и на второе тоже, если это только не совпадает с вашим видением и вы не планируете реализовать эту функциональность в будущем. Стоящая идея не потеряется и если функция действительно будет востребована, то люди будут вам напоминать об этом.
Далеко не все идеи равнозначны, а некоторые возможности могут быть полезны всего 0.1% ваших пользователей. При этом затрачиваемое время на реализацию функции одинаково и для той, что принесет пользу 80% пользователей и для той, что будет полезна только 5%. Это значит, что нужно правильно расставлять приоритеты и тратить свое время на реализацию тех возможностей, что принесут больший эффект. Разумеется, это не значит, что функциональность нужная 5% людей будет лишней, но вероятно вначале стоит решить проблему затрагивающую 80%. А как появится свободное время и ресурсы, то их можно потратить на шлифовку деталей.
Заметка на этот раз у меня получилась достаточно большая, вероятно по той причине, что я очень интересуюсь этой темой. И почему бы вам сейчас не пойти и не прочитать оригиналы этих текстов, избранные идеи из которых я только что изложил? Уверяю, это будет одно из лучших ваших вложений времени.