И снова здравствуйте! Мы продолжаем наш цикл научно-развлекательных статей про проектирование в веб-разработке.

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

Та моя статья получила много отзывов — как положительных, так и отрицательных. Помимо очевидных комментариев вида «да как вы смеете руку на святое поднимать! Наш менеджер писал, пишет и будет писать ТЗ, а вы вообще неизвестно откуда взялись!!!» там присутствовали вполне справедливые упреки в некотором дартаньянстве: дескать, других ругать мы горазды, а о себе ничего толком рассказать не можем.

И правда: мы редко рассказываем о своих ошибках, падениях и провалах, и я сам здесь не исключение. Я хочу исправиться и рассказать вам другую историю — на этот раз глубоко личную. Она будет про меня, мою команду — и многострадальную проектную документацию.

Пролог. Жизнь без документов

Свою историю я начну издалека — с небольшой страшилки.

Когда-то давно я работал на стороне клиента, и мне поручили важную задачу: полностью переделать корпоративный сайт. Срок мне выделили, как казалось, достаточный — что-то около 5 месяцев, — и я рьяно кинулся в бой.

Начал я с небольшого документа, в котором я выразил все свои идеи по новому сайту, гордо назвав это творение «техническим заданием». Документ этот являл собой стандартный клиентский бриф, который на многое намекает, но ничего толком не определяет, и содержал разные солидные штуки вроде списка целевых действий пользователей на сайте и описания шаблонов страниц (аж двух штук — главной и второстепенной).

В качестве исполнителя была выбрана одна уважаемая ныне контора, занимающая хорошее место в двадцатке одного хорошего интернет-рейтинга. Работа закипела! «Проект у вас простой, — сказал мне менеджер исполнителя, — так что будем работать без ТЗ».

И в этот момент у нас всех под ногами разверся настоящий ад.

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

Масла в огонь подливали наши внутренние согласования — будущий сайт я и мои коллеги представляли совершенно по-разному и расхождение результата с ожиданиями сорвало некоторым из них крышу: так, обсуждение с коллегой животрепещущего вопроса, делать нам или нет меню в стиле сайта Apple, заняло порядка часов 4 и завершилось примерно ничем.

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

Ближе к концу проекта все стало совсем плохо — мы вдрызг разругались с коллегами, на меня волком смотрел разработчик, который уже устал переделывать одну и ту же страницу по миллиону раз, а мои нервы пошатнулись настолько, что я уже склонялся к конструктивной идее «а гори оно все синим пламенем». Не знаю, чем закончилось бы дело, если бы коллег не отвлек очередной аврал и я под шумок не смог протащить целую охапку идей без согласования, быстро завершив сайт. Что характерно, финальный сайт был единодушно одобрен собственниками компании и моя шкура была счастливо спасена.

Эта история, преисполненная боли, научила меня одному: не ввязываться в разработку без четко прописанных, подробных требований.

Акт I. Карго-культ

Прошло время. Я начал менять профиль деятельности и стал потихоньку заниматься проектированием для клиентов — а именно писать технические задания.

Когда я впервые столкнулся с этой задачей, я не стал мудрствовать лукаво, вбил в Гугл какой-то позорный вопрос типа «Шаблон ТЗ на сайт» — и мне повезло наткнуться на довольно вменяемую статью на «Хабре»: http://habrahabr.ru/post/138749/

Поскольку в опыте автора сомневаться причин не было, я взял его формат ТЗ, подрезал в паре мест — и у меня получился документ следующего содержания:

1. Общие слова про разрабатываемый сайт;

2. Эксплуатационное назначение — под этим грозным термином подразумевался общий смысл разрабатываемого продукта;

3. Функциональное назначение — общее функциональное описание;

4. Термины и определения;

5. Данные и списки — описания информационных сущностей, используемых на сайте — и описание списков, в которых они отображаются на сайте;

6. Описания страниц — текстовые описания шаблонов страниц;

7. Технические требования — поддерживаемые браузеры, разрешения и прочие важные штуки.

 

Надо сказать, что этот формат документа производил весьма солидное впечатление — например, именно благодаря ему я ухитрился попасть на должность ведущего аналитика в одно интернет-агентство, которое тоже входит в двадцатку одного уважаемого рейтинга.

Вскоре, правда, выяснилось, что документ совсем не идеален (что, впрочем, отмечалось и самим автором этого формата ТЗ). В числе проблем значилось следующее:

• Ненужные, искусственные и совершенно формальные разделы. Ну скажите, зачем это разделение на «Эксплуатационное назначение» и «Функциональное», когда как проще дать, скажем, описание задач, которые сайт должен выполнить для своего владельца — и для своих пользователей?

• Странная логика разделов. Например, в один раздел «Данные и списки» оказались слеплены описания информационной архитектуры сайта и чисто прикладные, интерфейсные описания списков, куда эти данные входят, тогда как их куда логичнее было бы объединить с описаниями страниц.

• Смысловые пробелы. Предлагаемый формат ТЗ не давал полного описания продукта — не были описаны группы пользователей, функциональные схемы, протоколы обмена данными — и много чего еще.

В итоге ТЗ хромало на обе ноги, давало только общее представление о разрабатываемом продукте и лишь имитировало конкретные описания — они не были сведены в систему, а потому были слабо применимы в реальной разработке. В довершение всех дел такой формат ТЗ никому не нравился:

• Проектировщикам из моей новой команды не нравилось, что документ очень фрагментарно и несистемно описывает продукт;

• Клиент не мог разобраться в хитрой структуре ТЗ и в итоге подписывал все не глядя, что не улучшало процесс дальнейшей разработки;

• Разработчик выражался лаконично: «Ваше ТЗ — г...о» (прошу прощения за мой французский, но эта фраза впоследствии стала настолько хрестоматийной, что я не могу выкинуть оттуда ни слова).

Акт II. Система ПЛАТОН

Нужно было двигаться дальше и разрабатывать свой формат ТЗ. При этом мы остановились на двух основополагающих принципах:

• ТЗ должно было давать полное представление о продукте (как это сделать — мы почерпнули из Карла Вигерса и его чудесных Software Requirements);

• ТЗ должно было быть предельно понятным — в первую очередь, для клиента.

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

Мы долго думали и экспериментировали, и у нас родился новый формат ТЗ, который мы назвали ПЛАТОН.

Ядром нашего ПЛАТОНа был документ следующего формата:

1. Общие положения — довольно формальная часть документа, содержащая общую информацию по разрабатываемому продукту, статус документа, перечень употребляемых терминов и т.п.

2. Назначение, цели и целевая аудитория — в данный раздел сводилась информация о том, зачем нужен продукт — и для кого предназначен.

3. Технические требования — общие технические требования — браузеры, разрешения, указания на адаптивность интерфейсов и т.п.

4. Структура сайта и шаблоны — описание общей структуры страниц — и описание отдельных шаблонов, а также их общих элементов.

5. Требования к административной части — описание того, чем должна управлять административная часть продукта.

6. Структура данных — перечень сущностей, используемых в системе.

7. Функциональные описания — детально прописанные алгоритмы функций, используемых в системе.

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

Перечень интерфейсных элементов отныне был сведен к спискам с буллетами, так что какая-нибудь шапка страницы описывалась так:

• Логотип компании:

  • Представлен изображением;

  • Клик по логотипу компании приводит к переходу на главную страницу.

• Слоган компании:

  • Представлен текстом.

• Кнопка вызова формы обратной связи:

  • Вызывает появление формы обратной связи.

• Навигационное меню:

  • Состоит из следующих пунктов...

Ну и так далее. Это оказалось крайне удобным: в отличие от традиционных ТЗ, описания и свойства разных элементов были разнесены по полочкам, их было легко отслеживать и модифицировать.

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

Можно копипастить это описание столько раз, сколько потребуется, но здесь есть один мерзкий подводный камень. Допустим, что какой-то блок используется у нас в 20 разных местах. При составлении документа мы 20 раз сделали copy-paste и отправили документ клиенту; все идет хорошо ровно до того момента, пока клиент не присылает правки, связанные с вот этим 20 раз подряд повторенным блоком — в таком случае нам приходится отыскивать этот блок по всему документу, вносить исправления и отслеживать, чтобы этот блок не оказался где-то неизмененным. Хуже всего приходилось, когда в процессе работы над документом правки в этот спорный блок вносились не в один прием, а в несколько; необходимость носиться туда-сюда по большому документу очень утомляла.

Мы придумали другое решение: мы описывали блок только в одном месте, обозначали его специальным маркером (например, заключали его в типа-теги [BLOCK] и [/BLOCK]), а во всех повторяющихся местах вставляли маркер [*BLOCK], который указывал, что он является дубликатом блока, указанного соответствующим тегом.

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

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

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

Понимаю, звучит сложно, но на деле все получалось быстро и позволяло избегать бесконечных правок и выискивания несоответствий. Таким образом, мы убивали сразу двух зайцев: делали исходный документ удобным для модифицирования — и стремились к тому, чтобы презентуемый документ был по возможности прост и незамысловат.

Со временем мы планировали оснастить ПЛАТОН дополнительными фишками, но беда пришла оттуда, откуда не ждали: владелец нашей компании заявил, что наше ТЗ ему не нравится. Претензии были следующие:

• В ТЗ слишком много непонятных разделов, которые никто никогда не пишет (типа структуры данных, функциональных описаний и протоколов). Их следует убрать — разработчик сам разберется;

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

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

Акт III. Простые провалы

Ну, упрощать так упрощать! Мы смело взялись за дело и сотворили из сложно организованного ПЛАТОНа ТЗ, простое как три копейки. Вот как оно стало выглядеть:

1. Общие положения — перекочевали из ПЛАТОНа в сильно урезанном виде и уже не содержали конкретики вроде статуса документа;

2. Технические требования — сфокусировались только на упоминании разрешений и версий браузеров и то в самых размытых формулировках вроде «браузеров версий, последних на момент подписания ТЗ».

3. Структура сайта и шаблоны с требованиями к административной части. В этом разделе сконцентрировалась практически вся информация по разрабатываемому продукту — помимо древовидной структуры сайта и описания шаблонов, сюда входили даже функциональные требования, протоколы обмена данных и требования к административной системе, которые прописывались в описаниях шаблонов. Доходило до абсурда — например, какая-нибудь кнопка обратной связи с трехэтажным длиннющим описанием повторялась по 10 раз в документе.

Руководителю упрощенное ТЗ понравилось, а мы стали пожинать плоды наших трудов. Вот что мы выяснили, когда стали работать с таким супер-простым ТЗ:

• ТЗ перестало выражать суть проекта;

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

Да, такое ТЗ писалось быстро, утверждалось быстро — а толку от него не было никакого — на его фоне ТЗ первого поколения выглядело чуть ли не вершиной проектировочного гения.

Как результат, простое ТЗ никому не нравилось:

• Проектировщикам оно не нравилось, потому что было ни о чем;

• Клиенту, как ни удивительно, оно тоже не нравилось, потому что он понимал, что за немаленькую стоимость работы проектировщика он не может получить документ на 20 страниц, простой при этом как велосипед. Я насегда запомню глаза клиента, когда приехал к нему презентовать такое короткое ТЗ. «Мы так хорошо поговорили в начале, а теперь вы показываете мне всего лишь этот документ. Как так?» — спросил клиент, пожал мне руку и больше никогда не показывался.

• Разработчик, разумеется, выражался просто и емко: «Ваше ТЗ — г...о» (кто бы спорил).

Единственным исключением было, пожалуй, только наше руководство: от него мы никакого недовольства так и не услышали.

Интермеццо. Прототипы и Ко

Конечно, не все было так драматично — все-таки мы тоже не лаптем щи хлебали, а потому попытались всю эту ситуацию незаметно выправить.

Первой компенсационной мерой, которую мы приняли, было введение прототипов.

На всякий случай объясню, что это (знающие люди могут смело этот абзац пропустить). Прототипы — это схематичное изображение дизайна страницы или экрана. Проектировщик создает лучшее, на его взгляд, решение в плане интерфейса, но при этом прототип служит только иллюстрацией одного из возможных вариантов исполнения дизайна. Иными словами, прототип жестко определяет не то, КАК именно будет выглядеть та или иная страница или экран приложения, но то, ЧТО на ней будет представлено (какой набор компонентов) — и каким образом все это будет работать. Остальное в дальнейшем определит дизайнер, который будет пользоваться утвержденным прототипом как референсом.

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

Мера себя оправдала: клиентам, дизайнерам и разработчикам было намного легче разбираться с прототипами, чем с текстовым описанием, к которому они обращались за самыми непонятными моментами.

Вторая мера, на которую мы пошли — мы расширили комплект проектной документации.

Когда мы возились с достопамятным ПЛАТОНом, мы поняли, что дизайнеру крайне неудобно работать с ТЗ. По большому счету, дизайнеру плевать и на структуру данных, и на функциональные схемы, и единственное, что его реально интересует — это описание интерфейсов без технических подробностей, целевая аудитория, преследуемые ей цели, сценарии использования и пожелания заказчика к внешнему оформлению.

В свою очередь, программисту плевать на красочные описания целевой аудитории и внешнее оформление — ему куда важнее внутренние процессы и архитектура.

Очевидным образом напрашивалось следующее решение: исходное ТЗ заточить под нужды программистов, а дизайнерам давать другой, более простой и специализированный документ — художественное задание, или ХЗ. Структура ХЗ получилась следующей:

• Общие положения;

• Общие требования и замечания, важные с точки зрения дизайна. В данный раздел сводились общие пожелания клиента, а также всякая мелочь вроде списка референсов с комментариями и т.п.;

• Целевая аудитория и ее задачи;

• Пользовательские сценарии использования;

• Описание структуры и шаблонов сайта.

Жить сразу стало легче — дизайнер получал на руки прототипы и ХЗ и мог спокойно рисовать дизайн.

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

Специально для них мы разработали контетное задание (КЗ) следующего вида:

• Общие положения;

• Общие требования и замечания, важные с точки зрения контента — данный раздел касался, как и ХЗ, разнообразных требований заказчика к контенту, но при этом касался и других важных моментов вроде общей тональности контента, его стиля и т.п.;

• Целевая аудитория и ее задачи;

• Пользовательские сценарии использования;

• Описание контента — описывал контент на конкретных страницах, при этом касаясь в основном трех вещей: общего смысла контента, его стиля и объема.

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

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

Акт IV. Назад в будущее

Неизвестно, чем закончилась бы эта история, если бы я не перешел с командой в другое интернет-агентство (Artektiv). Здесь у меня появилось огромное преимущество: мне сразу же дали полный карт-бланш на формат проектной документации, и поэтому мы смогли провести разбор полетов и понять, что на месте ТЗ у нас зияет огромная дыра.

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

В какой-то момент мы даже отказались от слов «техническое задание» и стали называть документ спецификациями продукта, поскольку он не представлял собой задание в чистом виде, описывая не только условия задачи, но и добрую половину ее решения. Кроме того, термин «спецификации продукта» позволил нам дистанцироваться от ТЗ по ГОСТ — этого жуткого мутанта, который не является проектной документацией (но об этом ближе к концу статьи).

Вот как стал выглядеть этот документ:

• Общие положения — это по-прежнему была формальная часть документа, содержащая общую информацию по разрабатываемому продукту, статус документа, перечень употребляемых терминов и т.п.;

• Технические требования — как и раньше, раздел содержал общие технические требования — браузеры, разрешения, указания на адаптивность интерфейсов и т.п., но теперь включал в себя требования к верстке и прочие мелочи, важные для разработки;

• Группы пользователей — раздел содержал описание целевой аудитории с точки зрения пользовательских задач, а также описание их возможностей в системе;

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

• Используемые компоненты — как описывалось выше, данный раздел содержал подробные описания компонентов, из которых строятся интерфейсы сайта. По своему виду эти описания были аналогичны нашим предыдущим ТЗ — все те же буллеты, все та же древовидня структура.

• Структура данных — данный раздел был представлен набором сущностей, используемых в системе, где к каждой сущности относится таблица с перечнем атрибутов и прочей информацией. Например, для интернет-магазина одной из сущностей является товар, его атрибутами — название, цена, категория и т.д. Для каждого атрибута задавался тип данных (например, «дата» для «даты добавления» товара), принимаемые значения («только цифры» для «цены»), для некоторых сущностей также указывались конкретные данные, которые должны были быть изначально «зашиты» в систему (например, справочник городов). Важно, что этот раздел служил описанием общей структуры данных, но не описанием базы данных — это решение оставлялось на усмотрение разработчика, проектировщик же описывал набор данных, используемых в системе.

• Функциональные описания — данный раздел был представлен общим списком функций с указанием условий их активации, а также подробными функциональными схемами на каждую из них.

• Протоколы обмена данными — данный раздел содержал все необходимые подробности взаимодействия с внешними системами — выгружаемые и загружаемые данные, их формат и прочее.

• Требования к административной системе — данный раздел содержал описание того, чем может управлять административная система — и как она может это делать.

Важнейшей особенностью нового документа стала жесткая перелинковка всего и вся — все разделы были пронумерованы и весело ссылались друг на друга. Например:

• Если в описании шаблона упоминался какой-либо компонент — обязательно ставился номер раздела с его описанием;

• Если в описании компонента фигурировала какая-нибудь функция (например, описывалась кнопка обратной связи) — обязательно ставился номер раздела с ее описанием;

• Если в описании функции упоминалась какая-то сущность (например, изменялся статус товара) — тут же ставился номер раздела с ее описанием;

• Если сущность была связана с другой сущностью — тут же ставился номер раздела с ее описанием.

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

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

Чтобы разобраться с этой проблемой, мы выбрали следующую тактику: вместо того чтобы подстраивать по определению сложный и многоярусный документ под клиента, мы стали презентовать наш жесткий формат клиенту. Мы, по сути, обучали клиента работать с нашими документами и прототипами — и проговаривали с ним буквально каждую мелочь. Да, это не избавляло клиента от необходимости самостоятельно просматривать спецификации продукта, но он уже знал, куда надо смотреть, мог сверяться с прототипами и давал конструктивный отклик.

Другие части проектной документации, меж тем, остались практически неизменными — ХЗ было переименовано в «художественные спецификации», КЗ — в «контентные спецификации», прототипы остались как есть. Что характерно, художественные и контентные спецификации не перешли на сложную систему компонентов — шаблоны страниц описывались, как и во времена ПЛАТОНа, целиком текстом, чтобы дизайнеру и контент-специалисту не нужно было метаться по сложному документу в процессе работы (общая архитектура проекта, напомню, их особо не волновала).

Мы начали работать по новому формату, но тут на нашу голову обрушился новый удар судьбы: первый же по-настоящему сложный проект показал, что мы в своем увлечении сложными документами непростительно забыли очевидную, казалось бы, вещь.

Интермеццо. Сказочка о потерянном времени

Дело было так. Мы работали над проектом поистине адской сложности, написали большие спецификации продукта на две сотни с гаком страниц, сделали красивые интерактивные прототипы — и пошли утверждать это с клиентом.

Клиент был в целом всем доволен, но у него начали появляться правки — сперва небольшие, потом более крупные, потом стали появляться свежие идеи, потом клиент начал править архитектуру проекта... Каждая правка отражалась на спецификациях продукта, которые, будучи жестко связаны друг с другом, начинали ходить ходуном и требовали корректировки — и в итоге каждая новая идея клиента вызывала настоящий паралич в проектировании. Самое ужасное в этом было то, что идеи клиента не выходили за рамки изначальных договоренностей, и мы не имели права ему отказать — плюс нами все-таки двигало желание сделать по-настоящему качественный продукт.

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

Каким-то чудом вывернувшись из этой ситуации, мы глубоко задумались. Необходимо было придумать способ избежать таких казусов в дальнейшем — и мы его придумали.

Акт V. Индустриализация.

Мы поняли, что наша ошибка заключалась в самих процессах работы над проектной документации — мы сразу кидались на сложный документ и слушали мнение клиента только после его завершения; расхождение ожиданий клиента и результата нашей работы было высоким, и переделки отнимали невозможное количество времени.

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

Вот как стала выглядеть последовательность нашей работы:

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

2. На основании концепта мы договаривались с клиентом о схеме оплаты и стоимости проектирования

3. Уже после заключения договора мы составляли и согласовывали функциональные требования — по сути, предельно конкретизированный концепт, дающий общую характеристику проекту и указывающий желаемый список его функций.

Эти действия составляли, по сути, этап аналитики — на этом этапе мы очерчивали условия задачи, которую нам предстояло решить. Далее наступал этап собственно проектирования — составления решения задачи:

4. На основе функциональных требований мы составляли комплект документов, которые мы назвали «Бумажный тигр». Он состоял из следующих документов:

   • Основные пользовательские сценарии;

   • Структура данных;

   • Эскизы интерфейсов;

   • Функциональные схемы;

   • Протоколы обмена данными.

Все эти документы были приблизительными и предварительными; что очень важно, они составлялись исключительно на бумаге. На бумаге же они показывались клиенту: это давало возможность буквально на коленке разобрать всю архитектуру проекта, сразу же внести в нее правки — и договориться о критических для продукта вещах прямо на встрече с клиентом. По большому счету, «Бумажный тигр» представлял собой прототип всей последующей проектной документации и позволял сверить часы с клиентом и подготовить его к работе над проектом. Далее было вот что:

5. Мы составляли и согласовывали прототипы — как ни парадоксально, но работа над ними предшествовала работе над продуктовыми спецификацийями Это позволило нам согласовывать продукт не на примере описательных текстов, а на примере иллюстраций — и, как показала практика, это оказалось фантастически эффективным! Для проектировщика же составление прототипов не составляло больших трудностей, поскольку общие архитектурные моменты утверждались еще на этапе «Бумажного тигра».

6. Вслед за прототипами мы составляли и согласовывали спецификации продукта. Как уже упоминалось выше, этот сложный документ обязательно презентовался клиенту — и он, подготовленный «Бумажным тигром» и прототипами, уже знал, куда смотреть, и возникающие у него правки были в основном незначительны.

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

Схема получилась многоступенчатой и более затратной в плане временных ресурсов, но это позволило добиться двух важных вещей:

• Телега теперь не ставилась впереди лошади, и работа строилась от общего к частному.

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

• Клиент постоянно был в курсе работы проектировщиков, и на каждом этапе производилась «сверка часов», позволяющая удостовериться, что все идет как надо — и добиться получения качественного продукта.

Проектная документация наконец-то стала не только системной в работе, но и системной в разработке.

Все получалось интересно:

• Проектировщикам нравился новый формат документации — ее было удобно составлять, согласовывать и модифицировать, и при этом она охватывала продукт системно, во всей его полноте.

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

• Разработчики же заявили следующее: «Ваше ТЗ — г...о»

Мы, признаюсь сразу, дико огорчились и начали думать, как быть. В какой-то момент мы решили выяснить, что скрывается за этой фразой,и обнаружили, что в 95% случаев она означает следующее:

• Разработчик спецификации продукта не читал, потому что «чего это я буду в субботу время свое тратить»;

• Разработчик хочет получить на руки чуть ли не куски кода и детальное описание СУБД, что не является предметом работы проектировщика;

• Разработчику не нравятся ограничения, которые ставятся проектировщиками;

• Разработчик не привык работать по внешней документации.

И тут мы поняли одну простую вещь.

Эпилог. Основные принципы хорошей документации

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

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

Как должна выглядеть документация? А как угодно. Мы предпочитаем наш формат, но на нем не настаиваем. Конкретная форма здесь, на самом деле, не играет никакой роли; самое важное, чтобы проектная документация была:

• Системной — описывала продукт во всей его полноте, не оставляла дыр и фрагментов, которые разработчику придется додумать самому вне его сферы компетенции;

• Согласованной — ее должен знать и принимать заказчик;

• Отчуждаемой — документация не должна быть завязана на конкретного проектировщика и должна быть понятна в отрыве от своего составителя;

• Читабельной — поскольку мы говорим о сложных документах, они должны быть по возможности облечены в понятную (но не упрощенную!) форму — с кросс-ссылками, схемами и прочим.

Если придерживаться этих несложных и логичных принципов, то документация любого формата будет полезной для разработки и позволит создавать по-настоящему качественный продукт. И сложных, но логичных документов бояться не стоит — как правило, они делают мир лучше.

Что интересно, вышеупомянутое ТЗ по ГОСТ не удовлетворяет этим признакам — оно в очень кондовой, сложной и непонятной форме дает фрагментарное представление о продукте, в лучшем случае представляя собой структурированный клиентский бриф, а в худшем — просто набор бюрокартических формулировок. Именно поэтому мы не рекомендуем пользоваться этим форматом за исключением тех случаев, когда над вами навис Дамоклов меч государственного тендера.

И это еще не все

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

Какую роль дать проектировщику на проекте? Как разграничить деятельность менеджера и проектировщика? Каким образом проектировщик должен общаться с разработчиком и клиентом? — все эти вопросы мы с вами рассмотрим в заключительной части нашего цикла про правильное проектирование и заодно поставим жирную точку в вопросе о том, кем же является проектировщик в разработке — специалистом или все-таки менеджером.

Оставайтесь на связи!

Иллюстрация: https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BF%D0%BE%D1%80%D0%BE%D0%B6%D1%86%D1%8B_(%D0%BA%D0%B0%D1%80%D1%82%D0%B8%D0%BD%D0%B0)