Потом начните строить интерфейс — он и будет альтернативой функциональной спецификации. Нарисуйте несколько эскизов на бумаге. Потом начните кодировать это в html. В отличие от текста, который могут понять по-разному, дизайн интерфейса будет представлять то общее, с чем все могут согласиться.
Двусмысленность уходит, когда все начинают видеть на экране одно и то же. Постройте интерфейс, на который каждый может смотреть, пользоваться им, кликать мышкой, почувствовать его — до того, как начнете беспокоиться о внутреннем коде. Встаньте на передний край пользовательского опыта, насколько это возможно.
Забудьте о подписанных раз и навсегда спецификациях. Они заставляют вас принимать крупные, ключевые решения слишком рано в процессе разработки. Обойдите стороной стадию спецификации, и вам удастся быть гибкими и сделать изменения дешевле.
Бесполезные спецификации
Спецификация по большей части бесполезна. Я никогда не видел спецификации настолько большой, чтобы быть и одновременно и полезной, и точной.
В то же время я встречал много раз полную туфту, которая была основана на спецификациях. Это наиболее плохой способ писать программы, так как он по определению значит, что программа писалась, чтобы соответствовать теории, а не действительности.
— Линус Торвальдс (Linus Torvalds), создатель Linux
[33] (из: Linux: Linus On Specifications
[34])
Боритесь с создателями препятствий
Я обнаружил, что люди, настаивающие на подробных описаниях требований к программе до того, как начать разработку, в действительности являются создателями препятствий, пытающимися замедлить процесс (и которым обычно нечего сказать по поводу дизайна или инновационного мышления).
Все наши лучшие работы начинались с небольшого количества идей о том, как улучшить сайт, быстрого создания прототипа (статического), небольшого изменения дизайна и затем построения реального прототипа с реальными данными. После этого настоящий проект быстро набирал обороты и выполнялся с хорошим результатом.
— Марк Галлахер (Mark Gallagher), разработчик корпоративных интранет-сайтов (из Signal vs. Noise)
Не рождайте мертвых документов
Уберите ненужное бумаготворчество
Избегать функциональных спецификаций хорошо, но этого мало. Предотвращайте ненужное бумаготворчество везде, где можете. Если только документ не собирается воплотиться во что-то реальное — не создавайте его.
Стройте, а не пишите. Если вам нужно что-то объяснить, попробуйте это изобразить и сделать в качестве прототипа, вместо того чтобы долго документировать. Реальный интерфейс или прототип уже находятся на пути воплощения в реальный продукт. А лист бумаги, напротив, — лишь на пути в мусорную корзину.
Вот пример. Если документу-каркасу предназначено застыть и никогда не перерасти в настоящий продукт — не тратьте на него время. А если, начав с каркаса, вы строите на его базе настоящий проект, тогда да, начните с каркаса.
Документы, живущие отдельной от приложения жизнью, ничего не стоят. Они не ведут никуда. Все, что вы делаете, должно воплощаться в реальность. Если документ останавливается до того, как воплотиться в реальность, — он мертв.
Никто не будет это читать
Я не могу сосчитать, как много многостраничных спецификаций лежало мертвым грузом, непрочитанными, собирало пыль, тогда как мы кодировали, обсуждали проблемы, задавали вопросы и тестировали. Приходилось даже иметь дело с разработчиками, которые потратили часы на написание длинных посланий по электронной почте или документов о стандартах программирования — которые тоже никто не читал.
Сетевые приложения не растут благодаря документации. Разработка программ — постоянно меняющийся, итеративный процесс, который включает в себя взаимодействие, принятие мгновенных решений и непредвиденные темы, которые приходят в процессе. Ничего из этого не представляется возможным (либо нужным) закрепить на бумаге заранее.
Не теряйте время на то, чтобы заполнить текстом длинные тома; никто не будет их читать. Утешайте себя тем, что если продукту оставить достаточно места для самостоятельного роста, он вырастет так, что в любом случае не будет похож на то, что вы про него напишете.
— Джина Трапани (Gina Trapani), веб-разработчик и редактор Lifehacker
[35], the productivity and software guide
Расскажите короткую историю
Пишите рассказы, а не описывайте детали
Если вам нужны слова, чтобы описать новую функцию или изложить идею — напишите об этом короткий рассказ. Не углубляйтесь в технические или архитектурные детали, просто расскажите историю. Сделайте это на человеческом языке, как бы вы это сделали в разговоре.
Не нужно делать это литературным произведением. Просто расскажите, в какой последовательности все происходит. Если вы можете включить этот рассказ в контекст интерфейса программы, тем лучше.
Делитесь впечатлением, а не зацикливайтесь на деталях. Думайте о стратегии, а не о тактике. Тактика определится, когда вы начнете строить данную часть программы. Пока же вы просто хотите получить рассказ, который станет началом разговора и приведет вас в нужную колею.
Пользуйтесь обычными словами
Вставьте настоящий текст вместо lorem ipsum
Слова lorem ipsum dolor — признанные друзья дизайнеров. Текст-пустышка помогает понять, как будет выглядеть дизайн, когда он будет воплощен. Но текст-пустышка может быть опасным.
Lorem ipsum меняет ваш взгляд на программу. Он сводит текстовое содержание к элементу визуального дизайна — форме текста — вместо того, чем он должен быть: значимой информацией, которую кто-то должен будет вводить и/или читать. Текст-пустышка означает, что вам не удастся увидеть тех необходимых вариаций, которые безусловно появятся, когда будет введена настоящая информация. Это значит, что вы не почувствуете, как это — заполнять поля на вашем сайте. Текст-пустышка — это завеса между вами и действительностью.
Вам нужна настоящая копия, чтобы знать, какой длины должны быть поля. Вам нужна настоящая копия, чтобы видеть, как таблицы будут расширяться или сжиматься. Вам нужна настоящая копия, чтобы знать, как в действительности выглядит ваше приложение.
Как можно скорее используйте настоящие и подходящие слова. Если ваш сайт или приложение требует ввода данных, вводите реальные данные. И, собственно, печатайте текст — а не просто переносите его из другого источника. Если это имя, вводите реальное имя. Если город, вводите название существующего города. Если это пароль, ввод которого нужно повторить, введите его дважды.
Конечно, намного легче просто пробежать формы сверху вниз и заполнить поля мусором («asdsadklja» «123usadfjasld» «snaxn2q9e7»), чтобы разобраться с ними побыстрее. Но это — неправда. Это не то, что придется делать вашим клиентам. Хорошо ли идти по короткой дороге, а клиентов отправлять по длинной? Когда вы вводите в пожарном порядке, вы не знаете, как в действительности выглядит заполнение этой формы.
Делайте, как ваши клиенты — и вы станете их лучше понимать. Когда вы лучше их понимаете и чувствуете то, что чувствуют они, вы построите лучший интерфейс.
