Разберитесь с долгами
Расплачивайтесь по долгам вашего кода и дизайна
Мы обычно говорим о долгах в денежном выражении, но долги могут принимать и другие формы. Вы можете быстро обрасти долгами кода и дизайна.
Наваяли блок кода, который функционален, но все еще неопрятен — вот вы и набрали долгов. Набросали дизайн по принципу «и так сойдет» — ваши долги выросли опять.
Время от времени так поступать можно. Часто такая техника помогает поскорее довести проект в стиле Get Real до конца. Но все равно нужно признать эти долги и рано или поздно расплатиться с ними — вычистить неопрятный код, переделать ту страницу, которая была сделана так себе.
Точно так же, как вы откладываете часть дохода, чтобы заплатить налоги, регулярно выделяйте время на то, чтобы расплатиться с долгами по коду и дизайну. Если этого не делать, придется платить проценты (исправлять кривой код), вместо того, чтобы платить основную сумму (и двигаться вперед).
Открытые двери
Выпустите данные в мир через RSS, API и т.п.
Не пытайтесь запереть ваших клиентов. Позвольте им получить принадлежащую им информацию когда они хотят и как они хотят. Для этого вам придется отказаться от идеи запечатать данные. Выпустите их. Дайте людям доступ к их информации через RSS. Обеспечьте API, позволяющие другим разработчикам подсоединяться к вашей программе. Поступая так, вы облегчаете жизнь клиентам и расширяете возможности своей программы.
Раньше к RSS-фидам относились как к хорошему способу следить за обновлениями блогов и новостных сайтов. Но у них есть и другие сильные стороны. Они также позволяют клиентам быть в курсе изменяющегося контента приложения без того, чтобы постоянно в него входить. С фидами Basecamp пользователи могут ввести адрес в новостную ленту и быть в курсе того, что делается с проектом: сообщения, списки задач, этапы — без того, чтобы постоянно проверять все это на сайте.
API позволяют разработчикам создавать добавки к вашим продуктам — которые, в свою очередь, могут оказаться неоценимыми. Например, Backpack предоставляет API, которыми Chipt Productions воспользовался для построения программы Mac os x Dashboard. Программа позволяет добавлять и редактировать напоминания, списки и другое на рабочем столе. Клиенты с большим одобрением оценили эту программу, многие даже сказали, что благодаря ей они стали пользователями Backpack.
Вот еще примеры компаний, выпускающих данные наружу и получающих в результате эффект бумеранга:
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])
Слова
В функциональной спецификации нет ни грамма функциональности
Не составляйте функциональных спецификаций
Эти черновые документы обычно не имеют почти ничего общего с конечным продуктом. И вот почему:
Функциональные спецификации — это фантазии
Они не отражают реальности. Приложение не является реальностью до тех пор, пока строители не начнут его строить, дизайнеры — оформлять, люди — использовать. Спецификации — это только слова на бумаге.
Функциональные спецификации как средство умиротворения
Они для того, чтобы каждый почувствовал себя вовлеченным и счастливым. Приятное чувство, но не такое уж полезное. Спецификации никогда не говорят о принятии неприятных решений и не открывают истинных затрат — а это как раз то, что нужно для построения хорошего приложения.
Функциональные спецификации создают лишь иллюзию соглашения
Какое-то количество людей, согласных с текстом — это не есть соглашение. Каждый может читать тот же самый текст и думать о разном. Это безусловно всплывет позже, когда станут говорить: «Обождите, это не то, что я подумал», «Что? Да это же не так, как мы описали», «Да, это именно так, и мы все согласились с этим, тут даже есть ваша подпись». Вы знаете, как это обычно бывает.
Функциональные спецификации заставляют вас принимать наиболее важные решения именно тогда, когда у вас меньше всего информации
Вы меньше всего знаете о приложении, когда вы начинаете его строить. Чем больше вы его строите, чем больше используете — тем больше вы его знаете. Вот когда вам стоит принимать решения — когда у вас больше информации, а не когда меньше.
Функциональные спецификации ведут к перегруженности функциями
В стадии спецификаций вас ничто не ограничивает. Ничего не стоит просто писать и добавлять все новые и новые пункты. Вы можете уступить кому-то надоедливому тем, что добавите его любимую функцию. Потом вы будете разрабатывать с тем, чтобы удовлетворить эти пункты, а не людей. Именно так получаются перегруженные сайты с 30 кнопками по верху экрана.
Функциональные спецификации не дают вам развиваться, меняться и пересматривать
Вот функция программы подписана и согласована. Даже если вы поймете в процессе разработки, что эта идея была плохой, вы на ней застряли. Спецификации нет дела до действительности, когда как только вы начинаете что-то строить, все меняется.
Так что же вы должны делать вместо написания спецификации? Найдите более короткую альтернативу — такую, которая продвигает вас по пути создания. Напишите рассказ в одну страницу о том, что именно приложение должно делать. Используйте простой язык и сделайте это быстро. Если вам потребуется более одной страницы, значит, вы очень усложняете. Этот процесс не должен занять более одного дня.
