Как создать продающий сайт с нуля - [11]

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

Примечание. Если вам сложно выбрать один из вариантов, то вы можете попробовать установить для своих критериев числовые веса и поставить оценки веб-студиям по каждому критерию. Затем посчитайте общий рейтинг: это сумма произведений веса критерия на оценку по этому критерию. Например, у нас может быть три критерия: цена с числовым весом 3, студия должна быть из моей области с весом 5, и чем старше студия тем лучше с весом 2. Допустим, вы поставили оценки соответственно: 6,8,3. Тогда итоговый рейтинг для студии составляет: 3х6 + 5х8 + 2х3 = 64.

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

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

Начало взаимодействия

Вы выбрали поставщика услуг. Что делать дальше?

Переходим к этапу написания технического задания – ТЗ.

В голове может возникнуть мысль о том, а нужно ли оно вообще. Хорошо бы, если вслед за этой мыслью промелькнет “Нужно”. И вот почему: если вы скажете исполнителю: “Сделай, пожалуйста, сайт, и чтобы там все было красиво и удобно”, то результат вас практически на 100% не устроит. Потому что у поставщика услуг может быть совсем другое видение вопроса. ТЗ позволяет сгладить эту разницу и прояснить тонкие моменты реализации сайта.

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

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

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

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

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

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

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

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

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

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

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