Я обнаружил, что люди, настаивающие на подробных описаниях требований к программе до того, как начать разработку, в действительности являются создателями препятствий, пытающимися замедлить процесс (и которым обычно нечего сказать по поводу дизайна или инновационного мышления).
Все наши лучшие работы начинались с небольшого количества идей о том, как улучшить сайт, быстрого создания прототипа (статического), небольшого изменения дизайна и затем построения реального прототипа с реальными данными. После этого настоящий проект быстро набирал обороты и выполнялся с хорошим результатом.
— Марк Галлахер (Mark Gallagher), разработчик корпоративных интранет-сайтов (из Signal vs. Noise)
Уберите ненужное бумаготворчество
Избегать функциональных спецификаций хорошо, но этого мало. Предотвращайте ненужное бумаготворчество везде, где можете. Если только документ не собирается воплотиться во что-то реальное — не создавайте его.
Стройте, а не пишите. Если вам нужно что-то объяснить, попробуйте это изобразить и сделать в качестве прототипа, вместо того чтобы долго документировать. Реальный интерфейс или прототип уже находятся на пути воплощения в реальный продукт. А лист бумаги, напротив, — лишь на пути в мусорную корзину.
Вот пример. Если документу-каркасу предназначено застыть и никогда не перерасти в настоящий продукт — не тратьте на него время. А если, начав с каркаса, вы строите на его базе настоящий проект, тогда да, начните с каркаса.
Документы, живущие отдельной от приложения жизнью, ничего не стоят. Они не ведут никуда. Все, что вы делаете, должно воплощаться в реальность. Если документ останавливается до того, как воплотиться в реальность, — он мертв.
Я не могу сосчитать, как много многостраничных спецификаций лежало мертвым грузом, непрочитанными, собирало пыль, тогда как мы кодировали, обсуждали проблемы, задавали вопросы и тестировали. Приходилось даже иметь дело с разработчиками, которые потратили часы на написание длинных посланий по электронной почте или документов о стандартах программирования — которые тоже никто не читал.
Сетевые приложения не растут благодаря документации. Разработка программ — постоянно меняющийся, итеративный процесс, который включает в себя взаимодействие, принятие мгновенных решений и непредвиденные темы, которые приходят в процессе. Ничего из этого не представляется возможным (либо нужным) закрепить на бумаге заранее.
Не теряйте время на то, чтобы заполнить текстом длинные тома; никто не будет их читать. Утешайте себя тем, что если продукту оставить достаточно места для самостоятельного роста, он вырастет так, что в любом случае не будет похож на то, что вы про него напишете.
Пишите рассказы, а не описывайте детали
Если вам нужны слова, чтобы описать новую функцию или изложить идею — напишите об этом короткий рассказ. Не углубляйтесь в технические или архитектурные детали, просто расскажите историю. Сделайте это на человеческом языке, как бы вы это сделали в разговоре.
Не нужно делать это литературным произведением. Просто расскажите, в какой последовательности все происходит. Если вы можете включить этот рассказ в контекст интерфейса программы, тем лучше.
