Создание сайтов: точка зрения заказчика и разработчика
В ходе разработки обязательно информируйте заказчика о ходе работы (гораздо хуже, когда он пытается это выяснить всеми доступными способами – вы теряете доверие, а что значит доверие я писал выше). Если готов дизайн, покажите ему дизайн, лучше, когда у вас готово несколько видов дизайна, когда заказчик получает возможность выбора – он становится ближе к народу, то есть к вам. Поясняю момент, когда заказчик выбирает, он выбирает как правило окончательно, в случае же если вы предоставляете один вариант, у заказчика часто появляется желание что-то корректировать, а это чревато. В ходе информирования, у заказчика могут возникнуть идеи, это очень плохой момент, потому как воображение заказчика штука ненужная в данной ситуации. Часто его идеи не имею никакого смысла, часто они имеют смысл, но уже не вписываются в придуманную вами архитектуру. В общем, это еще один
сложный момент, свести все инновационные идеи заказчика к доступным для вас требованиям, делать это надо так же, как и в случае согласования плана. Не надо инициативы – она наказуема. Если вы сделаете что-то, что заказчик не ожидал увидеть, у него появляются вопросы, а вопросы – это плохо в данной ситуации. Делайте только то, о чем достигнута 100% договоренность. Очень неплохо, если была бы возможность демонстрировать заказчику, что сделано (тестовые директории на сайте, тестовые логины и пароли), когда заказчик реально видит, как работает в жизни то, что было задумано, он начинает больше доверять.
В итоге, когда готово все, главное для вас намекнуть заказчику, что главное для вас даже не деньги, а хорошая память о вас, когда он будет кому-то из друзей рекомендовать делать сайт.
Теперь пару слов о технологиях. Вообще, когда заказчик объясняет свои требования – это ситуация нормальная, но встречающаяся далеко не всегда. Часто вопрос стоит так: «А что вы можете предложить»? Очень тонкий момент, с одной стороны вам надо доходчиво произвести впечатление на заказчика, с другой стороны не слишком его погружать в дебри. Мне это удавалось не всегда, поэтому внимательно наблюдайте, каков эффект того, что вы говорите.
О возможностях. Я сторонник той ситуации, когда ваша поддержка сделанного сайта сводится лишь к более или менее глобальным его изменениям, когда же вы занимаетесь публикацией новостей, вставкой изображений, это, во-первых, достает вас, во-вторых (что более важно), заказчика. Поэтому при формировании плана надо стараться разумно объяснить заказчику преимущество такого подхода («даже ваша секретарша сможет обновить информацию»)с точки зрения цена/качество, мне это удавалось всегда, вообще идея, что сторонний человек минимально участвует в жизни сайта в дальнейшем, очень заказчику по душе. Такая технология далеко не всегда прозрачна, потребует от вас усилий, но лучше так... Вообще, не стесняйтесь писать некоторые дополнительные вещи, которые упростят вам жизнь, заказчик никогда не полезет в код разбираться что там к чему, поэтому лишняя пара функций
в классе, лишняя пара служебных функций на тот случай, если заказчик что-то хочет и готов за это заплатить, а вам это окажется проще простого, очень поможет. Для этого, разумеется, надо заранее прогнозировать, что может быть на сайте изменено, что добавлено. Плохо такое советовать, но иногда, если вы видите дырку в разработке, которая не была учтена при обсуждении, не спешите ее латать, как я говорил, инициативу надо ограничивать. Пусть лучше о ней вспомнят потом и заплатят деньги. Но свой труд на будущее старайтесь упрощать. Ну и конечно посмотрите следующую главу, где все объясняется с точки зрения заказчика.