Шрифт:
Вот еще примеры компаний, выпускающих данные наружу и получающих в результате эффект бумеранга:
Google Maps API положило начало интересной тенденции смешанных сайтов, когда люди получают информацию из других источников (например, объявления о квартирах) и наносят их на карту.
Linkrolls предлагает клиентам способ получить новейшие закладки del.icio.us, показанные на их сайтах.
Flickr предоставляет другим продавцам доступ к своим коммерческим API, так что клиенты могут покупать фотоальбомы, запасные хранилища данных для dvd, плакаты и марки. «Цель — открыть все по максимуму и дать вам наибольшее разнообразие выбора того, что вы можете сделать со своими фотографиями», — говорит Стюарт Баттерфилд из Flickr.
Когда компания 37signals выпустила Backpack, мое первое впечатление было...э-э.
Так что, когда Chipt Productions выпустили программку для Backpack для Tiger — и невозможно было ее не попробовать — я посмотрел на Backpack во второй раз. Результат? Совсем другое дело.
Сейчас, когда мне приходит в голову новая идея, я запускаю программку, печатаю, отправляю сообщение — готово. По электронной почте приходит нечто, что я хочу посмотреть? Запускаю программку, печатаю, отправляю — готово. Эта программка установлена — на каждом компьютере Mac, который я использую. И благодаря тому, что программка сетевая — не нужно заботиться о контроле версий или синхронизации — можно просто вводить информацию, не задумываясь, куда она пойдет или как получить к ней доступ позднее.
— Тодд Домини (Todd Dominey), основатель компании Dominey Design [31] (из Trying on Backpack [32] )31
http://domineydesign.com/
32
http://whatdoiknow.org/archives/002378.shtml
Слова
В функциональной спецификации нет ни грамма функциональности
Не составляйте функциональных спецификаций
Эти черновые документы обычно не имеют почти ничего общего с конечным продуктом. И вот почему:
Функциональные спецификации — это фантазии
Они не отражают реальности. Приложение не является реальностью до тех пор, пока строители не начнут его строить, дизайнеры — оформлять, люди — использовать. Спецификации — это только слова на бумаге.
Функциональные спецификации как средство умиротворения
Они для того, чтобы каждый почувствовал себя вовлеченным и счастливым. Приятное чувство, но не такое уж полезное. Спецификации никогда не говорят о принятии неприятных решений и не открывают истинных затрат — а это как раз то, что нужно для построения хорошего приложения.
Функциональные спецификации создают лишь иллюзию соглашения
Какое-то количество людей, согласных с текстом — это не есть соглашение. Каждый может читать тот же самый текст и думать о разном. Это безусловно всплывет позже, когда станут говорить: «Обождите, это не то, что я подумал», «Что? Да это же не так, как мы описали», «Да, это именно так, и мы все согласились с этим, тут даже есть ваша подпись». Вы знаете, как это обычно бывает.
Функциональные спецификации заставляют вас принимать наиболее важные решения именно тогда, когда у вас меньше всего информации
Вы меньше всего знаете о приложении, когда вы начинаете его строить. Чем больше вы его строите, чем больше используете — тем больше вы его знаете. Вот когда вам стоит принимать решения — когда у вас больше информации, а не когда меньше.
Функциональные спецификации ведут к перегруженности функциями
В стадии спецификаций вас ничто не ограничивает. Ничего не стоит просто писать и добавлять все новые и новые пункты. Вы можете уступить кому-то надоедливому тем, что добавите его любимую функцию. Потом вы будете разрабатывать с тем, чтобы удовлетворить эти пункты, а не людей. Именно так получаются перегруженные сайты с 30 кнопками по верху экрана.
Функциональные спецификации не дают вам развиваться, меняться и пересматривать
Вот функция программы подписана и согласована. Даже если вы поймете в процессе разработки, что эта идея была плохой, вы на ней застряли. Спецификации нет дела до действительности, когда как только вы начинаете что-то строить, все меняется.
Так что же вы должны делать вместо написания спецификации? Найдите более короткую альтернативу — такую, которая продвигает вас по пути создания. Напишите рассказ в одну страницу о том, что именно приложение должно делать. Используйте простой язык и сделайте это быстро. Если вам потребуется более одной страницы, значит, вы очень усложняете. Этот процесс не должен занять более одного дня.
Потом начните строить интерфейс — он и будет альтернативой функциональной спецификации. Нарисуйте несколько эскизов на бумаге. Потом начните кодировать это в html. В отличие от текста, который могут понять по-разному, дизайн интерфейса будет представлять то общее, с чем все могут согласиться.
Двусмысленность уходит, когда все начинают видеть на экране одно и то же. Постройте интерфейс, на который каждый может смотреть, пользоваться им, кликать мышкой, почувствовать его — до того, как начнете беспокоиться о внутреннем коде. Встаньте на передний край пользовательского опыта, насколько это возможно.
Забудьте о подписанных раз и навсегда спецификациях. Они заставляют вас принимать крупные, ключевые решения слишком рано в процессе разработки. Обойдите стороной стадию спецификации, и вам удастся быть гибкими и сделать изменения дешевле.