Небольшое эссе из книги «Getting Real», написанной сотрудниками компании 37signals. Оригинал можно прочитать здесь.
Спецификация — это абстрактный документ, в большинстве случаев не имеющий ничего общего с готовым программным продуктом. Почему? С удовольствием объясним:
1. Спецификация — это фикция
Она не имеет никакого отношения к реальности. Приложение становится реальным, когда разработчики пишут код, дизайнеры рисуют интерфейс, а люди начинают пользоваться готовым продуктом. Спецификация никак не приближает проект к завершению — ведь это не более чем слова на бумаге.
2. Задача спецификации — угодить всем
Любая спецификация обещает всё и сразу, и старается осчастливить всех. Это похвальный, но совершенно бесполезный подход. В спецификации никогда не идет речь о нахождении сложных компромиссов и выборе оптимальных вариантов, а при разработке приложений без этого не обойтись.
3. Спецификация — лишь иллюзия соглашения
Множество заверяющих подписей под несколькими страницами спецификации — это не соглашение. Ваша команда прочитала один и тот же текст, но скорее всего каждый понял его по-своему. И это обязательно всплывет в дальнейшей работе. «Подожди-ка, я вовсе не это имел в виду!», «Стоп, я понимал это совершенно по-другому!», «Нет-нет, всё именно так, и вы все под этим подписались». Вы прекрасно знаете, как это бывает.
4. Спецификация заставляет вас принимать самые важные решения тогда, когда вы меньше всего знаете о проекте
Меньше всего о проекте известно в самом начале работы над ним. Чем дольше длится проект, тем больше вы узнаете о нем. Так почему вы должны принимать самые важные решения, даже не приступив к работе?
5. Использование спецификаций приводит к обрастанию ненужной функциональностью
На момент написания спецификации вас ничего не ограничивает, кроме вашей фантазии. Нет ничего легче, чем дописать абзац текста или добавить еще один пункт в список. Вам ничего не стоит добавить в проект чью-то идею, просто чтобы сделать её автору приятное. Что мы имеем в итоге? Вашим проектом начинает руководить не здравый смысл, а абзацы текста и нумерованные списки. Именно так на свет и рождаются сайты с тридцатью горизонтальными табами в панели навигации.
6. Спецификация не позволяет вам развиваться, меняться и оценивать пройденный путь
Любой пункт спецификации трижды обсужден и закреплен кучей подписей. Даже если в процессе разработки вы поймете, что какая-то из фич бесполезна, у вас не будет пути назад. Само существование фиксированной спецификации противоречит тому факту, что требования могут меняться в процессе создания приложения.
Что же должно встать на место спецификации? Начните с более простого документа, который быстрее приблизит вас к рабочему прототипу приложения. Напишите небольшой текст, рассказывающий о том, что делает ваш продукт. Изложите свои мысли в свободной форме, не придерживаясь каких-либо шаблонов. Ограничьтесь одной страницей и не тратьте на эту задачу больше одного дня.
После этого приступайте к построению пользовательского интерфейса. Именно интерфейс послужит вам заменой спецификации. Начните с простых набросков на бумаге, а потом оформите интерфейс в статическом HTML (Getting Real в основном рассказывает о веб-приложениях — прим.перев.) Интерфейс, который можно увидеть и потрогать, понятен без объяснений и исключает любые недопонимания.
До того, как вы начнете писать основной код приложения, сделайте прототип интерфейса, который можно будет рассмотреть, покликать и обсудить. Постарайтесь как можно раньше взглянуть на ваш продукт глазами конечного пользователя.
Забудьте о фиксированных спецификациях. Они заставляют вас принимать самые серьезные решения на ранних фазах проекта. Постарайтесь обойтись без спецификации в её классическом смысле, и вам будет гораздо проще изменять требования и оставаться гибкими.
Напоследок — небольшая цитата из Линуса Торвальдса:
Спецификация — это абстрактный документ, в большинстве случаев не имеющий ничего общего с готовым программным продуктом. Почему? С удовольствием объясним:
1. Спецификация — это фикция
Она не имеет никакого отношения к реальности. Приложение становится реальным, когда разработчики пишут код, дизайнеры рисуют интерфейс, а люди начинают пользоваться готовым продуктом. Спецификация никак не приближает проект к завершению — ведь это не более чем слова на бумаге.
2. Задача спецификации — угодить всем
Любая спецификация обещает всё и сразу, и старается осчастливить всех. Это похвальный, но совершенно бесполезный подход. В спецификации никогда не идет речь о нахождении сложных компромиссов и выборе оптимальных вариантов, а при разработке приложений без этого не обойтись.
3. Спецификация — лишь иллюзия соглашения
Множество заверяющих подписей под несколькими страницами спецификации — это не соглашение. Ваша команда прочитала один и тот же текст, но скорее всего каждый понял его по-своему. И это обязательно всплывет в дальнейшей работе. «Подожди-ка, я вовсе не это имел в виду!», «Стоп, я понимал это совершенно по-другому!», «Нет-нет, всё именно так, и вы все под этим подписались». Вы прекрасно знаете, как это бывает.
4. Спецификация заставляет вас принимать самые важные решения тогда, когда вы меньше всего знаете о проекте
Меньше всего о проекте известно в самом начале работы над ним. Чем дольше длится проект, тем больше вы узнаете о нем. Так почему вы должны принимать самые важные решения, даже не приступив к работе?
5. Использование спецификаций приводит к обрастанию ненужной функциональностью
На момент написания спецификации вас ничего не ограничивает, кроме вашей фантазии. Нет ничего легче, чем дописать абзац текста или добавить еще один пункт в список. Вам ничего не стоит добавить в проект чью-то идею, просто чтобы сделать её автору приятное. Что мы имеем в итоге? Вашим проектом начинает руководить не здравый смысл, а абзацы текста и нумерованные списки. Именно так на свет и рождаются сайты с тридцатью горизонтальными табами в панели навигации.
6. Спецификация не позволяет вам развиваться, меняться и оценивать пройденный путь
Любой пункт спецификации трижды обсужден и закреплен кучей подписей. Даже если в процессе разработки вы поймете, что какая-то из фич бесполезна, у вас не будет пути назад. Само существование фиксированной спецификации противоречит тому факту, что требования могут меняться в процессе создания приложения.
Что же должно встать на место спецификации? Начните с более простого документа, который быстрее приблизит вас к рабочему прототипу приложения. Напишите небольшой текст, рассказывающий о том, что делает ваш продукт. Изложите свои мысли в свободной форме, не придерживаясь каких-либо шаблонов. Ограничьтесь одной страницей и не тратьте на эту задачу больше одного дня.
После этого приступайте к построению пользовательского интерфейса. Именно интерфейс послужит вам заменой спецификации. Начните с простых набросков на бумаге, а потом оформите интерфейс в статическом HTML (Getting Real в основном рассказывает о веб-приложениях — прим.перев.) Интерфейс, который можно увидеть и потрогать, понятен без объяснений и исключает любые недопонимания.
До того, как вы начнете писать основной код приложения, сделайте прототип интерфейса, который можно будет рассмотреть, покликать и обсудить. Постарайтесь как можно раньше взглянуть на ваш продукт глазами конечного пользователя.
Забудьте о фиксированных спецификациях. Они заставляют вас принимать самые серьезные решения на ранних фазах проекта. Постарайтесь обойтись без спецификации в её классическом смысле, и вам будет гораздо проще изменять требования и оставаться гибкими.
Напоследок — небольшая цитата из Линуса Торвальдса:
«… Они практически бесполезны. Я не видел ни одного крупного проекта, в котором спецификации полностью соответствовали реальности и при этом действительно помогали разработчикам.
Зато я видел множество неудавшихся проектов, которые слепо полагались на спецификации. Поверьте мне: разработка по спецификации — худший способ создания приложений, так как он подразумевает, что ваш проект будет делаться только по теории, без оглядки на реальность.»
