Страница 9

ТЗ позволяет управлять ожиданиями, как заказчика, так и исполнителя. Писать ТЗ стоит максимально конкретно. В моей практике был такой случай, когда в ТЗ было написано: “Обеспечить синхронизацию данных между базой данных сайта и 1С”. Что здесь не так? Дело в том, что 1С содержит сотни таблиц, и обеспечить полную синхронизацию крайне трудозатратно, причем в большинстве случаев это не является необходимым. Гораздо лучше было бы указать, что именно будет синхронизироваться между двумя системами.

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

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

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

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

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

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

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

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

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

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

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

Сужайте основание конуса неопределенности как можно быстрее.