Также не забывайте о документации. Сразу определите набор документации. Для оператора системы, для администратора, для программиста, который будет поддерживать проект.
Документацию можно сделать в формате видеоинструкций или кратких текстовых инструкций. Не нужно делать увесистые тома. Помните, что главное качество хорошей документации – это скорость внедрения человека в систему. Если она слишком сложна, то пользователь инстинктивно будет пробовать работать в системе наугад. Хороший вариант для документации – это презентации или комиксы. Расписывайте типовые процессы в комиксах. Это увлекательно и доступно для всех.
Следующий момент – рекомендую проверить быстродействие вашего веб-приложения в Google Page Speed. Это очень удобный сервис, который позволяет даже новичкам значительно оптимизировать загрузку вашего сайта.
Как лучше вводить пользователей? Правильный ответ: постепенно.
Если у вас система для внешнего пользования, например, интернет-магазин, то сначала дайте небольшую рекламу и посмотрите на активность пользователей через аналитику. Тем самым вы на небольшом объеме сможете понять – есть ли ошибки на сайте.
Если у вас система для внутреннего пользования, например, CRM, то сначала дублируйте процессы в новой системе и в старой (например, это может быть Excel) + переводите не всех пользователей, а только 1-2 человек. Таким образом, вы сможете в миниатюре начать работу системы, постепенно подключая новых пользователей и со временем отключив старый метод работы.
Очень большая ошибка сразу одним махом вводить всю систему – делая это, вы закладываете риски получить крайне негативные результаты:
Будут потеряны деньги, например, на массовую рекламу.
Будет утрачена лояльность вследствие критических ошибок.
Возникнет напряженность в отношениях заказчика и разработчика. Заказчик в этом случае будет винить в неудаче разработчика. Частично он будет прав, но лишь частично: на стадии эксплуатации риск возникновения ошибок очень велик, и заказчик должен заранее обработать этот риск. Постепенное внедрение в эксплуатацию – и есть мера по борьбе с этим риском. Это уменьшает критичность этого риска.
Мы обсудили первый из специальных этапов, которые завершают проект. Рассматривайте ввод в эксплуатацию именно как отдельный этап со своей последовательностью действий, иначе могут возникнуть проблемы, о которых мы говорили в начале главы.
Переходим к последней главе – к завершению проекта. Честно признаюсь, мы очень часто упускаем этот момент в виду быстрого перехода на следующие проекты. Правильно завершить проект – это значит повысить качество будущих проектов. Об этом мы и будем говорить в следующей главе.
Глава 8. Завершение проекта
Самое важное, что вам нужно сделать на этапе завершения проекта – это ретроспектива. По сути, ретроспектива – это взгляд в прошлое. Обычно, – это небольшое совещание между участниками проекта, на котором обсуждаются следующие вопросы:
Что было сделано хорошо?
Что можно улучшить?
Анализ метрик проекта.
С какими проблемами мы столкнулись и как решили?
Какие практики надо сделать постоянными?
Получение обратной связи для каждого члена команды в плане участия в проекте.
Результаты подобного совещания лучше документировать для последующей оптимизации ведения проектов. Ретроспектива вам помогает расти как команде и повышает общую культуру ведения проекта и понимание этого вопроса всей команды, а не только менеджера.
Какие метрики можно документировать:
Оценочные часы / Фактические часы. Насколько мы отклоняемся от оценки?
% брака по задачам.
Вклад в проект исполнителей (количество часов/задач).
% выхода за сроки.
Соблюдение параметров проекта (сроки, объем, бюджет).
Следующий момент – это освобождение ресурсов, связанных с проектом. В первую очередь, – это разработчики. Обычно они перекидываются на другой проект, поэтому, чем быстрее вы это сделаете, тем лучше будет для других проектов. Также вы освобождаете тестовую площадку – сайт, базу, пул в IIS, чтобы не расходовать ресурсы тестового сервера. При этом обязательно уведомите всех участников проекта об этом, чтобы не было недопонимания. Например, заказчик будет и дальше взаимодействовать с разработчиком, который уже перешел на другой проект.
Очень важной частью завершающего этапа является определение режима поддержки проекта после ввода в эксплуатацию. Очень мало проектов, которые один раз разработали, и они так и работает в неизменном виде. Уже по ходу проекта возникают новые идеи, как можно улучшить проект. В период эксплуатации системы реальными пользователями таких идей будет гораздо больше. Поэтому необходимо выделить некоторые ресурсы на развитие проекта. В первую очередь надо определиться с программистами, которые будут ответственны за сопровождение проекта. Также надо иметь договоренности с клиентом о режиме, в котором будет проходить поддержка. Очень часто бывает так, что проект закончили, программист переходит на новый проект, и не хватает временных ресурсов на доработку существующего проекта. Необходимо сразу предвидеть, какой объем доработок будет у проекта в период эксплуатации.