Помоги проекту - поделись книгой:
Первое, чем надо заняться, – это общее тестирование. Вы должны проверить совместную работу всех модулей, попробовать основные workflow ваших пользователей, т.е. сценарии, по которым будут действовать ваши посетители.
Также вы должны проверить корректность работы сайта в разных браузерах и на разных платформах. Конечно, проверять следует те браузеры и платформы, которыми пользуется ваша целевая аудитория.
Тестирование старайтесь вести на реальных данных и очень желательно провести тест на больших объемах данных. Со временем база данных может разрастись, и приложение, которое очень шустро работало в начале, может начать дико тормозить на больших объемах данных. Поэтому забейте программно в базу данных множество информации и посмотрите, как реагирует на это система.
При тестировании полезно выполнять параллельно ручные вычисления. Только так вы сможете понять – ошибается программа или нет.
И последний момент по тестированию – это тестирование бизнес-логики с представителями от клиента. Именно они будут использовать ваш разработанный продукт. Именно они знают, как он должен работать. Именно они знают все тонкости бизнес-процессов и могут указать на неявные ошибки в бизнес-логике приложения. Если вы закончили тестирование полностью, то дайте потестировать сайт третьей стороне или специализированной конторе. Уверен, что будут найдены еще недочеты, которые вы сможете исправить до запуска.
Следующий крупный блок – это перенос приложения на боевой сервер с предварительной настройкой этого сервера. Здесь в первую очередь следует побеспокоиться о безопасности данных приложения:
Смените все пароли в системе (SQL Server, SVN, панель управления).
Настройте правильно брандмауэр (ограничение по IP к SQL Server, закрыть все лишние порты и т.д.).
Сделайте настройки на SQL сервер (закрыть доступ к sa, можно вообще внешний доступ отключить в SQL Server).
Правильно установите настройки приложения на production среду (убрать режим отладки, отключить трассировку, настроить локальное подключение к базе, изменить ключи шифрования, поменять настройки/пароли на почте).
Обеспечьте доступ только тем лицам, которые будут назначены на сопровождение проекта на этапе эксплуатации.
Проработайте в системе создание резервных копий базы данных и файлов приложения.
Проработайте план восстановления приложения после краха базы, краха сервера или другого форс-мажора. Проработайте всевозможные риски и соответствующие меры/инструкции.
Также необходимо настроить дополнительные сервисы, а именно:
Мониторинг доступности приложения (например через UptimeRobot).
Периодическое создание бекапов (либо внутри сервера, либо через сервис хостера, который предоставляет сервер).
Мониторинг параметров сервера. Есть специальные инструменты (SNMP), которые позволяют это делать. Для этих задач вам потребуется системный администратор.
Проверка работы почты, отправки СМС. Здесь вам необходимо создать регламент периодической проверки отправок. Иначе есть риск не получать важнейшие сообщения по системе.
Следующий шаг, который вы должны сделать – это перевести все сервисы в боевой режим. Это может быть, к примеру, прием платежей на сайте, отправка СМС и др. Проверьте, что они корректно работают в боевом режиме. Вы немного потратите средств на это – это лучше, чем спустя месяц узнать, что у вас, оказывается, не работает регистрация через социальные сети или прием платежей.
Далее мы должны подключить корректно скрипты аналитики и провести первичную поисковую оптимизацию проекта, если это необходимо. Это включает в себя следующие мероприятия:
Проверить sitemap.xml
Проверить robots.txt
Зарегистрировать сайт в Google и Yandex
Проверить, что везде корректно установлены title и description в соответствии с набором ключевых слов (семантическим ядром).
Проверить работу редиректов 301, если они используются.
Проверить сайт на наличие битых ссылок.
Провести анализ сайта в различных SEO сервисах, например, cy-pr.com.
Проверить ваш сайт в сервисе валидации HTML и CSS http://validator.w3.org/.
Мы не рассматриваем каждый пункт подробно. Пусть это будет просто чек-листом для вас перед запуском. Более подробную информацию вы сможете узнать у SEO-мастера, который занимается вашим сайтом.
Также не забывайте о документации. Сразу определите набор документации. Для оператора системы, для администратора, для программиста, который будет поддерживать проект.
Документацию можно сделать в формате видеоинструкций или кратких текстовых инструкций. Не нужно делать увесистые тома. Помните, что главное качество хорошей документации – это скорость внедрения человека в систему. Если она слишком сложна, то пользователь инстинктивно будет пробовать работать в системе наугад. Хороший вариант для документации – это презентации или комиксы. Расписывайте типовые процессы в комиксах. Это увлекательно и доступно для всех.
Следующий момент – рекомендую проверить быстродействие вашего веб-приложения в Google Page Speed. Это очень удобный сервис, который позволяет даже новичкам значительно оптимизировать загрузку вашего сайта.
Как лучше вводить пользователей? Правильный ответ: постепенно.
Если у вас система для внешнего пользования, например, интернет-магазин, то сначала дайте небольшую рекламу и посмотрите на активность пользователей через аналитику. Тем самым вы на небольшом объеме сможете понять – есть ли ошибки на сайте.
Если у вас система для внутреннего пользования, например, CRM, то сначала дублируйте процессы в новой системе и в старой (например, это может быть Excel) + переводите не всех пользователей, а только 1-2 человек. Таким образом, вы сможете в миниатюре начать работу системы, постепенно подключая новых пользователей и со временем отключив старый метод работы.
Очень большая ошибка сразу одним махом вводить всю систему – делая это, вы закладываете риски получить крайне негативные результаты:
Будут потеряны деньги, например, на массовую рекламу.
Будет утрачена лояльность вследствие критических ошибок.
Возникнет напряженность в отношениях заказчика и разработчика. Заказчик в этом случае будет винить в неудаче разработчика. Частично он будет прав, но лишь частично: на стадии эксплуатации риск возникновения ошибок очень велик, и заказчик должен заранее обработать этот риск. Постепенное внедрение в эксплуатацию – и есть мера по борьбе с этим риском. Это уменьшает критичность этого риска.
Мы обсудили первый из специальных этапов, которые завершают проект. Рассматривайте ввод в эксплуатацию именно как отдельный этап со своей последовательностью действий, иначе могут возникнуть проблемы, о которых мы говорили в начале главы.
Переходим к последней главе – к завершению проекта. Честно признаюсь, мы очень часто упускаем этот момент в виду быстрого перехода на следующие проекты. Правильно завершить проект – это значит повысить качество будущих проектов. Об этом мы и будем говорить в следующей главе.
Глава 8. Завершение проекта
Самое важное, что вам нужно сделать на этапе завершения проекта – это ретроспектива. По сути, ретроспектива – это взгляд в прошлое. Обычно, – это небольшое совещание между участниками проекта, на котором обсуждаются следующие вопросы:
Что было сделано хорошо?
Что можно улучшить?
Анализ метрик проекта.
С какими проблемами мы столкнулись и как решили?
Какие практики надо сделать постоянными?
Получение обратной связи для каждого члена команды в плане участия в проекте.
Результаты подобного совещания лучше документировать для последующей оптимизации ведения проектов. Ретроспектива вам помогает расти как команде и повышает общую культуру ведения проекта и понимание этого вопроса всей команды, а не только менеджера.
Какие метрики можно документировать:
Оценочные часы / Фактические часы. Насколько мы отклоняемся от оценки?
% брака по задачам.
Вклад в проект исполнителей (количество часов/задач).
% выхода за сроки.
Соблюдение параметров проекта (сроки, объем, бюджет).
Следующий момент – это освобождение ресурсов, связанных с проектом. В первую очередь, – это разработчики. Обычно они перекидываются на другой проект, поэтому, чем быстрее вы это сделаете, тем лучше будет для других проектов. Также вы освобождаете тестовую площадку – сайт, базу, пул в IIS, чтобы не расходовать ресурсы тестового сервера. При этом обязательно уведомите всех участников проекта об этом, чтобы не было недопонимания. Например, заказчик будет и дальше взаимодействовать с разработчиком, который уже перешел на другой проект.
Очень важной частью завершающего этапа является определение режима поддержки проекта после ввода в эксплуатацию. Очень мало проектов, которые один раз разработали, и они так и работает в неизменном виде. Уже по ходу проекта возникают новые идеи, как можно улучшить проект. В период эксплуатации системы реальными пользователями таких идей будет гораздо больше. Поэтому необходимо выделить некоторые ресурсы на развитие проекта. В первую очередь надо определиться с программистами, которые будут ответственны за сопровождение проекта. Также надо иметь договоренности с клиентом о режиме, в котором будет проходить поддержка. Очень часто бывает так, что проект закончили, программист переходит на новый проект, и не хватает временных ресурсов на доработку существующего проекта. Необходимо сразу предвидеть, какой объем доработок будет у проекта в период эксплуатации.
Для этого составляется ориентировочный план развития проекта, в котором прописываются модули и подсистемы, которые будут реализованы по мере развития проекта. Сюда может войти все, что не вошло в проект по каким-то соображениям (обычно это либо бюджет, либо сроки).
Вашей обязанностью перед клиентом, как менеджера проекта, является предложение вариантов развития проекта. Вы предлагаете клиенту все разнообразие функционала и возможностей, которые можно в будущем внедрить в проект. Что ставить, а что нет – это уже дело клиента. Поэтому у вас в запасе должен быть такой список, в котором перечислены эти самые модули. Это может быть что угодно, например, чат, видеотрансляции, аудиокомментарии к задачам, дополнительный контроль целостности базы, обработка сообщений с почты и т.д.
План развития проекта очень желательно составить документально и согласовать с клиентом. Тем самым у вас будут договоренности на будущее по развитию проекта.
Немаловажная часть для вашей компании – маркетинговая. Очень желательно взять отзыв клиента, когда он максимально доволен вашей работой в эмоциональном плане. Вы можете составить отзыв в форме интервью, где вопросы закрывают какие-то возможные возражения будущих клиентов. Помимо отзыва хорошо бы получить разрешение на написание кейса по разработке. Кейсы очень полезны в плане проработки новых клиентов.
Также немаловажной частью является получение обратной связи от клиента в плане проработки качества. Составьте небольшую анкету для клиента и задайте следующие вопросы:
Вы довольны результатом проекта?
Почему выбрали именно нас?
Что больше всего понравилось на проекте?
Что больше всего не понравилось на проекте?
Что можете сказать по взаимодействию с менеджером и разработчиками?
Последнее, что вам нужно сделать на проекте – это отпраздновать коллективную победу! Проект – это долгий, непростой процесс, в котором может участвовать множество людей. Обязательно надо ставить хорошую психологическую точку в проекте. Там самым вы можете эмоционально закрыть проект и двигаться дальше – к новым, более сложным проектам!
Поделиться книгой: