Getting Real
Шрифт:
Слова
В функциональной спецификации нет ни грамма функциональности
Не составляйте функциональных спецификаций
Эти черновые документы обычно не имеют почти ничего общего с конечным продуктом. И вот почему:
Функциональные спецификации — это фантазии
Они не отражают реальности. Приложение не является реальностью до тех пор, пока строители не начнут его строить, дизайнеры — оформлять, люди — использовать. Спецификации — это только слова на бумаге.
Функциональные
Они для того, чтобы каждый почувствовал себя вовлеченным и счастливым. Приятное чувство, но не такое уж полезное. Спецификации никогда не говорят о принятии неприятных решений и не открывают истинных затрат — а это как раз то, что нужно для построения хорошего приложения.
Функциональные спецификации создают лишь иллюзию соглашения
Какое-то количество людей, согласных с текстом — это не есть соглашение. Каждый может читать тот же самый текст и думать о разном. Это безусловно всплывет позже, когда станут говорить: «Обождите, это не то, что я подумал», «Что? Да это же не так, как мы описали», «Да, это именно так, и мы все согласились с этим, тут даже есть ваша подпись». Вы знаете, как это обычно бывает.
Функциональные спецификации заставляют вас принимать наиболее важные решения именно тогда, когда у вас меньше всего информации
Вы меньше всего знаете о приложении, когда вы начинаете его строить. Чем больше вы его строите, чем больше используете — тем больше вы его знаете. Вот когда вам стоит принимать решения — когда у вас больше информации, а не когда меньше.
Функциональные спецификации ведут к перегруженности функциями
В стадии спецификаций вас ничто не ограничивает. Ничего не стоит просто писать и добавлять все новые и новые пункты. Вы можете уступить кому-то надоедливому тем, что добавите его любимую функцию. Потом вы будете разрабатывать с тем, чтобы удовлетворить эти пункты, а не людей. Именно так получаются перегруженные сайты с 30 кнопками по верху экрана.
Функциональные спецификации не дают вам развиваться, меняться и пересматривать
Вот функция программы подписана и согласована. Даже если вы поймете в процессе разработки, что эта идея была плохой, вы на ней застряли. Спецификации нет дела до действительности, когда как только вы начинаете что-то строить, все меняется.
Так что же вы должны делать вместо написания спецификации? Найдите более короткую альтернативу — такую, которая продвигает вас по пути создания. Напишите рассказ в одну страницу о том, что именно приложение должно делать. Используйте простой язык и сделайте это быстро. Если вам потребуется более одной страницы, значит, вы очень усложняете. Этот процесс не должен занять более одного дня.
Потом начните строить интерфейс — он и будет альтернативой функциональной спецификации. Нарисуйте несколько эскизов на бумаге. Потом начните кодировать это в html. В отличие от текста, который могут понять по-разному, дизайн интерфейса будет представлять то общее, с чем все могут согласиться.
Двусмысленность уходит, когда все начинают видеть на экране одно и то же. Постройте интерфейс, на который каждый может смотреть, пользоваться им, кликать мышкой, почувствовать его — до того, как начнете беспокоиться о внутреннем коде. Встаньте на передний край пользовательского опыта, насколько это возможно.
Забудьте о подписанных раз и навсегда спецификациях. Они заставляют вас принимать крупные, ключевые решения слишком рано в процессе разработки. Обойдите стороной стадию спецификации, и вам удастся быть гибкими и сделать изменения дешевле.
Спецификация по большей части бесполезна. Я никогда не видел спецификации настолько большой, чтобы быть и одновременно и полезной, и точной.
В то же время я встречал много раз полную туфту, которая была основана на спецификациях. Это наиболее плохой способ писать
33
http://www.linux.org/
34
http://kerneltrap.org/node/5725
Я обнаружил, что люди, настаивающие на подробных описаниях требований к программе до того, как начать разработку, в действительности являются создателями препятствий, пытающимися замедлить процесс (и которым обычно нечего сказать по поводу дизайна или инновационного мышления).
Все наши лучшие работы начинались с небольшого количества идей о том, как улучшить сайт, быстрого создания прототипа (статического), небольшого изменения дизайна и затем построения реального прототипа с реальными данными. После этого настоящий проект быстро набирал обороты и выполнялся с хорошим результатом.
— Марк Галлахер (Mark Gallagher), разработчик корпоративных интранет-сайтов (из Signal vs. Noise)
Не рождайте мертвых документов
Уберите ненужное бумаготворчество
Избегать функциональных спецификаций хорошо, но этого мало. Предотвращайте ненужное бумаготворчество везде, где можете. Если только документ не собирается воплотиться во что-то реальное — не создавайте его.
Стройте, а не пишите. Если вам нужно что-то объяснить, попробуйте это изобразить и сделать в качестве прототипа, вместо того чтобы долго документировать. Реальный интерфейс или прототип уже находятся на пути воплощения в реальный продукт. А лист бумаги, напротив, — лишь на пути в мусорную корзину.
Вот пример. Если документу-каркасу предназначено застыть и никогда не перерасти в настоящий продукт — не тратьте на него время. А если, начав с каркаса, вы строите на его базе настоящий проект, тогда да, начните с каркаса.
Документы, живущие отдельной от приложения жизнью, ничего не стоят. Они не ведут никуда. Все, что вы делаете, должно воплощаться в реальность. Если документ останавливается до того, как воплотиться в реальность, — он мертв.
Я не могу сосчитать, как много многостраничных спецификаций лежало мертвым грузом, непрочитанными, собирало пыль, тогда как мы кодировали, обсуждали проблемы, задавали вопросы и тестировали. Приходилось даже иметь дело с разработчиками, которые потратили часы на написание длинных посланий по электронной почте или документов о стандартах программирования — которые тоже никто не читал.
Сетевые приложения не растут благодаря документации. Разработка программ — постоянно меняющийся, итеративный процесс, который включает в себя взаимодействие, принятие мгновенных решений и непредвиденные темы, которые приходят в процессе. Ничего из этого не представляется возможным (либо нужным) закрепить на бумаге заранее.
Не теряйте время на то, чтобы заполнить текстом длинные тома; никто не будет их читать. Утешайте себя тем, что если продукту оставить достаточно места для самостоятельного роста, он вырастет так, что в любом случае не будет похож на то, что вы про него напишете.
35
http://www.lifehacker.com/