Документируйте идею, чтобы она воплотилась в жизнь

За свою жизнь я усвоил один по-настоящему жестокий урок: никакое проектирование, даже самое лучшее, не будет иметь смысла, до тех пор пока не воплотится в жизнь. А этого не случится, пока оно не будет описано в мельчайших конкретных деталях, в концепциях, понятных программистам. Описывать идеи проектирования нужно в письменном виде, максимально подробно, приводя примеры и неопровержимые доказательства пользы. Этот документ должен быть напечатан и размножен многократно. Его следует собственнолично представить всем участникам команды, ответственным за продукт. На этом собрании непременно нужно присутствовать вице-президенту по разработке, который в это время должен кивать и улыбаться. А лучше, чтобы это был сам президент компании.

Проектировщики должны писать, рисовать раскадровки, создавать анимации и прототипы своих решений максимально полно и с большим количеством деталей, чтобы программисты могли руководствоваться этими документами как планами и создавать код прямо по ним. В документе должно быть подробно описано достаточное количество примеров, чтобы вселить в программистов уверенность, что это решение действительно надежно и способно выдержать этап реализации.

Задокументированный план проектирования подобен плану военных действий. Каждый знает свою зону ответственности и осведомлен обо всех критических и важных аспектах. Теперь все будут действовать согласованно и сообща, создавая продукт под пользователя с конкретными потребностями.

Программисты обычно используют весьма действенную тактику, называемую «пассивно-агрессивной». Они не будут вступать в конфронтацию для решения какого-либо вопроса, а вместо этого начнут избегать привлекать внимание к этой проблеме и втихомолку сами будут действовать – или бездействовать, словно пассажир каноэ, который легонько наклоняется то влево, то вправо, тем самым задавая направление движения. Одна из моих самых любимых аксиом в бизнесе – это «Если чего-то не существует на бумаге, значит, этого не существует в принципе». В мире разработки программного обеспечения эта аксиома становится особенно справедлива. Если что-либо не было задокументировано, очень велики шансы, что идею истолкуют неверно или вовсе проигнорируют, поскольку внутренние мотивы программистов и пользователей различаются самым кардинальным образом. Просто не описывать диалоговое окно в документе нельзя – проектировщик обязан невероятно четко указать, где этого диалогового окна быть не должно, чтобы программисты не добавляли лишние окна по собственной инициативе. Программисты считают диалоговые окна отличной вещью и думают, что делают пользователям огромное одолжение, когда, улучив свободную минутку, вставляют в программу еще пару-тройку диалоговых окон. Для пользователей же эти диалоги – вещь крайне ненавистная, они изнуряют и снижают производительность работы пользователя.

Проектировщики взаимодействия, подобно архитекторам, подготавливают планы, которые описывают будущий продукт. Однако, несмотря на схожесть архитектурных планов и документации по разработке ПО, есть между ними и существенные различия. На архитектурных планах информация представлена в более сжатой форме. Одна линия на чертеже может подразумевать стену из 100 000 кирпичей. Когда же речь заходит о проектировании взаимодействия, сжатый формат подачи допускается лишь минимально. Описание поведения ста страниц кода может занять сто страниц в документации к программе. Я шучу лишь отчасти, когда говорю, что тщательно описанная спецификация совершенно не отличима от кода, который ее реализует. В идеальном мире разработки программного обеспечения проектировщикам бы даровали не менее года на подготовку плана продукта, а затем только три месяца дали бы программистам на его реализацию. В реальном же мире все ровно наоборот.

Все вышеописанное подразумевает, что в проектировочной документации по продукту должны быть опущены некоторые аспекты. Проектировщик должен обладать не только ощущением качества в отношении проектирования, но также уметь отличать действительно важные на текущий момент вещи. Он должен решить, какие части программного продукта подлежат тщательному проектированию, а какие можно оставить на волю программистов.

Я составляю проектировочную документацию, применяя методику «спирали», характерную для газет. В заголовке новости отражается вся важная информация о событии. В первом абзаце событие описывается снова, с чуть большим количеством подробностей. Следующие три абзаца повторяют важные моменты и сообщают дополнительную информацию. Оставшаяся часть текста может занимать несколько полос, в ней событие описывается с максимально возможной детализацией. Такая структура позволяет читателю узнать, что ему требуется, без погружения в излишние подробности.