Как создать продающий сайт с нуля | страница 22

Кто должен писать ТЗ? Заказчик или исполнитель? На мой взгляд – вместе. В главе 2 мы сформировали ядро требований. Мне кажется, будет разумным предложить исполнителю такую схему: вы отправляете набор своих требований исполнителю, а он оформляет его в виде ТЗ, затем вы согласуете ТЗ, и, если все удовлетворены результатом, можно приступать к работе.

В чем плюсы такого подхода?

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

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

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

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

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

Рис. 4.1 Конус неопределенности – оценка проекта уточняется по мере движения проекта к финальной точке.

Как видно из рисунка, в начале проекта разброс может составлять от 0.25х до 4х, т.е. диапазон составляет 16х.

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