Процесс разработки узла привлекает к себе множество квалифицированных работников, которые приносят свои способности на жертвенник проекта. В идеальном мире они могли бы выполнять свои задачи изолированно, а затем принести готовый продукт,  который был бы полностью совместим с результатами работы других членов команды. К сожалению, сложность процесса разработки узла переместила такую концепцию в разряд утопического идеализма.
Такие навыки членов команды, как программирование, обработка изображений, дизайн и пр., могут быть названы производственными (hard skills). Речь идет о работниках, результатом работы которых является материальный продукт. Но управление такой командой требует особого набора талантов, которым редко отдается должное внимание. Среди них — способность сплотить команду, создать мотивацию выполнения работы каждым членом команды в срок, ясно донести цели проекта до всех членов команды, а также собрать в команде именно таких людей, работа которых способна удовлетворить потребности и ожидания клиента. Это — организаторские навыки (soft skills) Web-разработки. Они вступают в игру, когда состав работ проекта уже определен, и не менее важны, чем основные навыки, необходимые для создания продукта. Организаторские навыки можно разбить на три широкие области: планирование проекта, управление проектом и обеспечение взаимодействия.
Так что же делает эти три области такими интересными, несмотря на то, что они просто связаны с ответственностью за создание и сдачу конечного продукта? Они подразумевают одновременную ответственность каждого члена команды.
Описание проекта
Перед тем как члены команды нажмут кнопки включения питания на своих компьютерах, каждый из них должен ознакомиться с параметрами проекта. Среди этих параметров — бюджет, сроки, манифест и технические характеристики узла. Все вместе это называют описанием проекта (project scope). В нем также определяются цели проекта и конечный продукт.
Проводя аналогию с процессом строительства, каждый уложенный кирпич требует увеличения размера фундамента. Сам фундамент, с определенной точки зрения, определяет размеры и расположение всех комнат в здании. Начните использовать другие материалы или передвигать элементы в комнатах в другое место — и цена проекта подскочит. Это может произойти из-за того, что заказчик потребует изменить конструкцию или подрядчик согласует с заказчиком рекомендуемые изменения. В любом случае результат не будет тождествен оригиналу, в связи с чем и цена его всегда будет выше, чем у исходного проекта.
В современной динамичной среде существует опасная ловушка — постоянно добиваться предельной насыщенности узла новшествами, всякими там каскадными меню и вращающимися глобусами, которые не были включены в исходный план. Web-дизайн часто ассоциируют с фактором внешней эффектности, который гласит, что дизайнеры и клиенты всегда будут стремиться делать то, что кажется им обоим более привлекательным, даже если это не несет в себе полезной нагрузки. Давление со стороны клиента, заставляющее добиваться максимальной крутизны узла, приводит к обороне на двух фронтах — от клиента и от команды. Почему бы не заменить кнопки JavaScript, которые планировались изначально, на анимированные картинки Flash, созданные на кадрах из видеоклипов? Внезапно работа, которая в бюджете планировалась как одночасовая, становится трехчасовой, и при этом приходится задействовать в ней еще одного сотрудника. В общей схеме такое изменение может показаться незначительным. На самом же деле при этом увеличивается количество создаваемых элементов, что приводит к разрастанию бюджета. Все это называется искажением проекта (project creep).
Искажения проекта чем-то напоминают китайскую пытку водой. Одна капля воды, упавшая на голову, не доводит вас до сумасшествия. Однако постоянное капание в течение дня может добиться своей цели. Искажения могут коснуться всех проектов, которыми вы занимаетесь. Проблема состоит в том, что такие мелкие изменения всегда выглядят незначительными, но они имеют тенденцию накапливаться. Учтите это в плане искажения проекта. Разъясните членам команды и самому заказчику, какие дополнительные финансовые затраты и смещения сроков готовности проекта могут быть вызваны даже самыми незначительными изменениями в проекте. Наибольшая опасность искажения проекта исходит от мелких поправок и дополнений. Они могут запросто выбить вас из графика и растворить общую концепцию узла.
Итак, как избежать искажений проекта? Создайте отдельный детальный документ, фиксирующий то, что вам предстоит создать. Заставьте клиента подписать его. Некоторые агентства имеют специальный документ, называемый общим рабочим соглашением (General Working Agreement). Это соглашение, содержащее оценку всех затрат, подписывается клиентом и агентством и узаконивает рабочие взаимоотношения между заказчиком и подрядчиком. В этом документе один из главных пунктов посвящен именно искажениям проекта. Подпись клиента на рабочем соглашении гарантирует, что он ясно осознал факт, что вещи, не входящие в описание проекта, будут требовать дополнительных капиталовложений. Только из-за того, что работа выполняется на компьютере, не следует предполагать, что она не занимает времени. Некоторые агентства в дополнение вписывают в это соглашение предварительную оценку изменений. Вы даже удивитесь, как быстро клиент сменит свою позицию, когда речь зайдет о деньгах. Всегда убеждайтесь, что клиент понимает, что исключение работ из описания проекта также займет дополнительное время. У клиентов, не способных вовремя предоставить материал для размещения на узле, существует тенденция просто удалять целый раздел. Такие события ведут к перестройке проекта, что также занимает время. Если вы уже проделали часть работы над некоторым разделом, а клиент его вдруг закрывает, он должен знать, что все равно должен оплатить фактически выполненную работу.
Планирование производства Web-узла
Существует поговорка: "Планируйте работу, а затем выполняйте свой план". Часто разработка большого плана производства является далеко не творческим процессом — она требует квалификации менеджера или администратора. Хотя некоторые творческие личности ненавидят структурирование, игнорирование этой части процесса может привести к опасным последствиям.
Планирование вытекает из принятия клиентом предложений группы постановки задачи. Обычно эта группа включает менеджера продаж и члена группы управления агентства. Команда постановки задачи, возглавляемая руководителем проекта, должна провести с клиентом достаточное время, чтобы понять его потребности и ожидания. На этой стадии проект переходит из туманных идей и концепций в форму конкретики, обычно воплощенную в формализованный документ плана проекта. Этот документ затем передается клиенту на согласование и подпись.
После получения подписи первым делом нужно установить бюджет, так как он, образно говоря, определяет содержимое каждой комнаты дома и состав лиц, участвующих в строительстве. Бюджет обычно исходит из тех средств, которые клиент согласен вложить в проект. Но не совсем. Вы часто будете сталкиваться с тем, что клиент не представляет себе реальной стоимости создания узла, и его оценка всегда оказывается значительно ниже той, на которую указывает ваш практический опыт. Хотя разработка бюджета может быть достаточно сложной, концепция, стоящая за этим процессом, проста: стоимость базируется на фактически затраченных часах работы. Если создание одной Flash-кнопки занимает 1 час, а работник получает 50 долларов в час, — математика проста.
План должен содержать метод отслеживания времени, так как в процессе Web-разработки время — деньги. Для расчета существует множество программ: от электронных таблиц до специализированных пакетов. Если член команды имеет конкретную задачу, доведите до его сведения, сколько времени отводится на выполнение этой задачи, и согласуйте с ним эту цифру. В случае привлечения к проекту подрядчиков и субподрядчиков это особенно критично. Если их оценки выглядят чересчур оптимистичными, чтобы быть правдой, не бойтесь поправлять их в своих оценках.

Замечание В мире полиграфии художники и печатники привязаны к особой системе — системе сводок (docket system). В этой системе каждый час обычно разбивается на шестиминутные сегменты, называемые юнитами (units). Работа перемещается от одного работника к другому в форме большого пакета, содержащего все документы и файлы, к которому прикреплен лист учета юнитов. Если конкретная работа занимает 30 минут (5 юнитов), работник записывает на учетном листе, что работа выполнена и сколько юнитов на нее было затрачено. После того как проект завершен, юниты суммируются и выписывается счет.

После того как бюджет создан, руководитель проекта определяет, кто и какую работу будет выполнять. При этом создается график производства. В этом графике должен учитываться и клиент — для него проект разбивается на этапы, результаты которых он принимает. Документ плана проекта передается клиенту на утверждение.
Документация плана проекта должна содержать бюджет, график работ, манифест (пример будет показан далее в этой главе) и некоторые другие документы или задачи, например общее рабочее соглашение с описанием проекта.
Управление созданием Web-узла
Хотя это и придается анафеме в вольноопределяющейся среде Web-разработчиков, в современной производственной среде критически важно создание жесткой структуры управления с четко обозначенными линиями ответственности. Способность управлять командой творческих личностей и мотивировать их на достижение определенных целей в сжатые сроки является "черным" искусством, требующим навыков твердолобого бизнесмена и уступчивого дипломата.
Хотя структура управления может меняться от проекта к проекту, должны создаваться четкие линии ответственности и отчетности, с одним человеком в вершине пирамиды. Если для проекта создано несколько отдельных команд, для каждой команды в плане должен назначаться один ответственный за выполнение задач и отчетность.
Естественно, Web-разработка является таким же производством; в ней также должны использоваться стандартные механизмы управления, такие как элементы учета и финансирования, кадровые соглашения, разделение труда и т.п.
Взаимодействие в процессе работы над проектом
Если с Web снять всю мишуру и рекламу, окажется, что это — всего лишь механизм обмена информацией. Многие команды это понимают и используют Web в качестве основы своего процесса взаимодействия. Процесс взаимодействия может принимать форму "клиент-команда" или быть исключительно внутрикомандным, однако общим является то, что в этот процесс обмена информацией может быть вовлечен любой.
Критично в проекте с самого начала установить правильные линии обмена информацией. При их определении учитывается, кому позволено общаться с клиентом, а кому — нет. Было бы желательно установить такие же параметры и у клиента.
В ходе повседневного производственного процесса должны быть установлены параметры внутрикомандного и внешнего обмена информацией. Это может быть обмен электронной почтой, использование службы уведомлений (Notes) в приложениях Dreamweaver и Fireworks (будет описано в главе 2) или использование виртуальных сводок (virtual docket).
Многие проекты для обмена информацией используют узлы клиента во внешней сети (описывается в главе 3). Прелесть внешней сети заключается в том, что она экономит массу времени при обмене идеями и концепциями между членами команды и клиентом. Приложение SiteSpring от Macromedia дает хороший пример организации такого взаимодействия. Как вы узнаете в главе 3, одной из его главных функций является обеспечение обмена критическими замечаниями, если во время работы над проектом возникают расхождения во мнениях или споры.
Администрирование, обмен информацией и планирование — не обязательные части процесса; однако если они отсутствуют или используются неправильно, проект переходит в состояние хаоса. Хотя творческие люди часто пытаются избежать структурирования производственного процесса, успешными становятся только те команды, которые управляются лицами, имеющими план. Это напоминает хорошее законодательство, которое мотивирует тех, кого иногда можно сравнить с группой ковбоев. Руководитель проекта должен обеспечить выполнение проекта в назначенные сроки и в пределах бюджета, в производственной среде, основанной на полном взаимодействии членов команды, вместо использования традиционного иерархического разделения труда.