Поиск:

Web Project Management: Реальный проект

Copyright notice от переводчика: данная статья - перевод второй части книги Ashley Friedlein Web Project Management: Delivering Successful Commercial Web Sites. Данный перевод не является официальным. Он не может быть использован в коммерческих целях, а только для ознакомления с содержанием книги, которую можно приобрести на Amazon.

PDF версия всего текста (324 кб)

« Пред.стр. | След.стр. »

12.1.3. Спецификация проекта

После утверждения прототипа и предложенных решений, пришло время точно описать, как будет создан сайт. Требовалось определить объем работ, так как постоянно возникали новые идеи, а были ведь еще и другие проекты. Спецификация проекта создала основу контракта между pres.co и Channel5.

Как это было

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

Однако случились две вещи, которые в конечном счете помогли нам, заставив нас всех уделить чуть больше времени на спецификацию проекта. Во-первых, информационный отдел канала Channel5 впервые был вовлечен в процесс. Так как до этого, все переговоры шли без них (помимо подписания технической спецификации), а они привыкли использовать определенные методы разработки программного обеспечения, они пожелали увидеть спецификацию проекта. Это помогло бы им увидеть, о чем собственно мы договорились, в какой стадии находился проект, и кто за что должен был отвечать. Как всегда, было интересно наблюдать, как сталкиваются различные методы, способы мышления и интересы, когда информационный отдел оказывается в одной упряжке с маркетингом. Однако, обе стороны привнесли очень много ценного в проект. Компьютерщики помогли добиться ясности и подробности по всем креативным и рекламным идеям, которые уже лежали готовые на столе. Так родилась жизненно необходимая спецификация проекта. Которую вскоре стали называть "Библия".

Второй момент, который помог сформировать спецификацию проекта, было решение, что коммерческий договор между Channel5 и pres.co будет базироваться на спецификации проекта. Это значило, что спецификация проекта стала одним из документов, которые должен был представить pres.co, со всеми вытекающими сроками и штрафами. Ничто так не помогает сконцентрировать мысли, как подобный контракт. Он заставил нас более основательно подумать о том, что в точности мы собираемся делать, насколько хорошо мы к этому подготовлены, на каких условиях и с какими отходными путями. Все переговоры проходили в прекрасной атмосфере, но это значило, что спецификация проекта была важна в еще большей степени.

Один из моментов, который пожалуй не был достаточно четко оговорен - это критерий успеха, по которому мы могли судить о проекте. Так как сайт создавался только как затратная статья маркетингового бюджета, было трудно применить к нему какие-либо четкие критерии, как то доходы от е-коммерции или объем продаж. Так как мы не были уверены, насколько далеко маркетинговый отдел Channel5 готов пойти (в смысле, уровня дополнительных расходов, рекламы на телевидении и прочее), было трудно определить и объем входящего трафика сайта. Да, на сайте предполагалось собирать данные о посетителях, но опять-таки трудно оценивать успех проекта по тому, сколько собрано этих данных. Так как оплата за проект не была привязана с его успехом, и так как все были расположены благожелательно к проекту, на то время это не играло большой роли. Однако, по мере развития и превращения сайта в коммерческую единицу, было очень приятно продемонстрировать, как исходный сайт достиг и превысил цели, которые перед ним первоначально стояли.

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

Наконец, этот этап примечателен теми мелкими параллельными задачами, которые вдруг неизвестно откуда возникали. Это было то, что называется "распухание проекта". По мере того, как проекту подключались другие отдела канала Channel5, возникали новые идеи и пожелания (многие из которых были очень дельными), которые включались в составную часть проекта. Например, на рис. 12.4 показана страница, с которой журналисты набрав пароль, получали доступ к специальной информации. Хоть это и не входило строго в рамки спецификации проекта, эта идея нам понравилась и на ее реализацию ушло не так уж много дополнительных ресурсов. Для акционеров Channel5 понадобилась также видеоперезентация прототипа сайта. Для этого понадобились актеры-дикторы, оператор, сценарист и так далее. А так как это нужно было делать для акционеров, это вдруг стало первостепенной (и незапланированной) задачей. Тем не менее, на подходе к Рождеству необходимость в этой презентации отпала также неожиданно, как и возникла.

Вместо того, чтобы с порога отметать все эти дополнительные задачи, мы давали им определение "следующие проекты" (incremental projects). Благодаря этому мы смогли оценивать и описывать каждый проект по отдельности. Также удобнее было распределять приоритеты между этими проектами. Клиенту гораздо проще принять решение, когда ему показывают сметы и сроки, и предлагают самому расставить приоритеты.

Извлеченные уроки

Ниже перечислены уроки, извлеченные на данном этапе разработки спецификации проекта web-узла канала Channel5.

На написание спецификации проекта уходит гораздо больше времени, чем вы рассчитываете. А на всем протяжении выполнения проекта спецификация требует пересмотра. Так как этот документ является корнем всего проекта, ему требуется уделить очень много времени и сил. Само документ пишут в Word-е, но к нему могут прилагаться и Excel-таблицы, схемы, графики работ, описание структуры базы данных, схемы информационных потоков, сделанные в PowerPoint, и так далее. К тому времени, как вы сведете все эти многочисленные форматы фалов в единый документ, с сохранением нумерации и ориентации страниц, вы вдруг наверняка обнаружите, что весь документ нужно кардинально поменять. Не стоит убивать все свое время на этот документ, достаточно в самом начале проекта выделить несколько дней на него, а потом на протяжении всего проекта несколько часов в неделю посвящать внесению в него изменений. Если по какой-либо причине вы не сможете продолжить работу над проектом, этот документ послужит планом для того, кто займет ваше место. Шаблон спецификации проекта доступен по адресу http://www.e-consultancy.com/ book/. Пусть он послужит вам отправной точкой.

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

- на этапе D будут использоваться только материалы, созданные на этапах с A по C. Если клиент захочет что-либо изменить в материалах, весь процесс должен быть повторён с самого начала. Помимо того, что проект будет отброшен на несколько этапов назад, это приведет к увеличению общего бюджет проекта.

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

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

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

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

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

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

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

То, какими терминами вы будете пользоваться, может оказаться важнее, чем вы думаете. В примере с каналом Channel5 то, что мы все дополнительные, неоговоренные работы стали называть "следующими проектами" (incremental projects), имело гораздо большие последствия, чем я себе мог представить. Название не несло слишком сильный отрицательный оттенок (как, например, выражения "дополнительные" или "побочные проекты"); само слово "следующий" - подразумевало рост и развитие. В то же самое время, было понятно, что эта работа выполняется сверх и помимо того, что было оговорено в самом начале. Разделяя эту работу на отдельные проекты, нам становилось проще определить круг работ, их стоимость и приоритет. По мере того, как люди привыкли называть эти работы "следующими проектами", очень легко стало определять их место и порядок в общей массе дел. Не забывайте, что даже в ваше отсутствие клиент и его сотрудники будут вести разговоры о проекте, а также обсуждать его со своими начальниками, которые были вовлечены в проект не с самого начала. Если сразу установить, что в проекте какими словами называется, эффективность общения увеличится в несколько раз, а сторонам проще будет понять друг друга. "Активные точки" (hot spots), "следующие проекты" (incremental projects), "Библия", "список действий по открытию проекта" (rolling action list), и "генеральный план действий" (master plan) - все эти термины использовались нами в общении с Channel5 по вопросам проекта. Каждый из этих терминов, как монета, нес в себе определенную стоимость, а эти стоимости облегчали расчет приоритетов в проекте.

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

В качестве одной из тактических уловок можно воспользоваться ящиком для предложений (suggestion box), куда люди могут складывать свои идеи, пришедшие им на ум в середине проекта, или идеи, придуманные новыми акционерами. Объявите, что новые все идеи прекрасны, но непрактично менять из-за них весь имеющийся план. В Web-е все течет и изменяется, следовательно, после того, как текущая версия проекта будет завершена и предъявлена публике, ее практически немедленно придется обновлять. На этом этапе, свежие идеи будут на вес золота, следовательно до той поры все идеи будут как бы храниться в банке.

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

« Пред.стр. | След.стр. »

Реальный проект
12.1. История проекта и его описание: www.channel5.co.uk
12.1.1. Уточнение проекта
12.1.2. Определение решений
» 12.1.3. Спецификация проекта
12.1.4. Информационное наполнение
12.1.5. Дизайн и сведение сайта
12.1.6. Тестирование, запуск и сдача
12.2. Итоги

Самые популярные статьи:

• Элементы разработки веб-сайтов
• Анализ популярных решений в web-дизайне
• Шаблонные решения для web-сайтов
• 10 главных ошибок веб-дизайна 2003 года
• К черту плохие броузеры