Провести анализ сайта в различных SEO сервисах, например, cy-pr.com.
Проверить ваш сайт в сервисе валидации HTML и CSS http://validator.w3.org/.
Мы не рассматриваем каждый пункт подробно. Пусть это будет просто чек-листом для вас перед запуском. Более подробную информацию вы сможете узнать у SEO-мастера, который занимается вашим сайтом.
Также не забывайте о документации. Сразу определите набор документации. Для оператора системы, для администратора, для программиста, который будет поддерживать проект.
Документацию можно сделать в формате видеоинструкций или кратких текстовых инструкций. Не нужно делать увесистые тома. Помните, что главное качество хорошей документации – это скорость внедрения человека в систему. Если она слишком сложна, то пользователь инстинктивно будет пробовать работать в системе наугад. Хороший вариант для документации – это презентации или комиксы. Расписывайте типовые процессы в комиксах. Это увлекательно и доступно для всех.
Следующий момент – рекомендую проверить быстродействие вашего веб-приложения в Google Page Speed. Это очень удобный сервис, который позволяет даже новичкам значительно оптимизировать загрузку вашего сайта.
Как лучше вводить пользователей? Правильный ответ: постепенно.
Если у вас система для внешнего пользования, например, интернет-магазин, то сначала дайте небольшую рекламу и посмотрите на активность пользователей через аналитику. Тем самым вы на небольшом объеме сможете понять – есть ли ошибки на сайте.
Если у вас система для внутреннего пользования, например, CRM, то сначала дублируйте процессы в новой системе и в старой (например, это может быть Excel) + переводите не всех пользователей, а только 1-2 человек. Таким образом, вы сможете в миниатюре начать работу системы, постепенно подключая новых пользователей и со временем отключив старый метод работы.
Очень большая ошибка сразу одним махом вводить всю систему – делая это, вы закладываете риски получить крайне негативные результаты:
Будут потеряны деньги, например, на массовую рекламу.
Будет утрачена лояльность вследствие критических ошибок.
Возникнет напряженность в отношениях заказчика и разработчика. Заказчик в этом случае будет винить в неудаче разработчика. Частично он будет прав, но лишь частично: на стадии эксплуатации риск возникновения ошибок очень велик, и заказчик должен заранее обработать этот риск. Постепенное внедрение в эксплуатацию – и есть мера по борьбе с этим риском. Это уменьшает критичность этого риска.
