
Себя, сайт и целый бизнес можно обезопасить. Пусть хоть все перевернется вверх дном — есть волшебная кнопка «Сохранить». И называется она «Паспорт проекта». О нем и поговорим 😏
Паспорт проекта — документ, в котором зафиксированы технологический стек, описываются его технические параметры и основные сведения, инструкции и аспекты разработки. Это как паспорт вашего устройства, например смартфона.
Паспорт можно вести в удобном формате: Google или Яндекс Документах, ворде или где угодно еще. Главное — сохраните и держите под рукой, чтобы всегда можно было обратиться к нему и дополнить.
→ Эта статья — буквально большой чек-лист для проверки работы подрядчика.
Сейчас по порядку: какие разделы должны быть в паспорте проекта, чтобы на любом этапе даже новый специалист смог разобраться, что же ему делать.
В разделе «Конфигурация сервера или хостинга» можно попросить вашего разработчика написать:
📍 Важно актуализировать информацию по мере обновления доступов и тарифов.
Типовой сайт обычно содержит в себе плюс-минус одинаковые данные, поэтому подготовили для вас небольшие подсказки. Вот что обычно включают в описание сайта:
1. Доступ к серверу. Сервер — то, где хранятся файлы вашего сайта. Обычно сервер арендуется у хостинг-провайдера. Доступ нужен, чтобы пополнять счета и верхнеуровнево управлять сайтом. Например, так может выглядеть описание доступа:
2. Доступ к консоли позволяет точечно и гибко управлять самим сервером:
3. Конфигурацию сервера — то, что помогает поддерживать производительность всей системы сайта. Например:
4. Бэкапы — резервная копия данных, которая хранится отдельно, чтобы можно было восстановить утерянное. Например:
Доступы к серверу, консоли, конфигурацию сервера и бэкапы надо фиксировать, чтобы не потерять накопленные данные. Благодаря этому можно легко подключить к работе нового спеца.
Технологический стек — это набор технологических решений, используемых для создания приложения или веб-сайта. Технологический стек также может называться стеком решений, технологической инфраструктурой или экосистемой данных.
Тоже подключаем разработчика, чтобы помог заполнить раздел паспорта. Выглядеть может вот так:
В целом в раздел вносим все данные о жизненно важных бизнес-процессах, модули или интеграции и самописные решения.
В этом блоке обычно кладем ссылки на различные важные документы. Например:
Если вы — агентсво, можно добавить договор, коммерческое предложение, гант работ и прочее. В целом этот блок можно использовать для дальнейшей навигации по всем документам.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
12569 тендеров
проведено за восемь лет работы нашего сайта.
Важно перечислить всех участников команды — дизайнеров, контент-менеджеров, маркетологов, тимлида, руководителя и прочих. Также важно указать роль на проекте каждого участника. Это поможет всем легко поддерживать связь и без лишних выяснений обратиться с возникшей проблемой адресно. Участников команды можно перечислить со стороны заказчика и со стороны агентства, например:
Со стороны DS:
Со стороны клиента:
Роли могут отличаться в зависимости от проекта, но суть одна: фиксируем в документе участников команды, их роли и способ связаться. Этот блок помогает тем, что при появлении нового участника в проекте вы быстро сможете познакомить его с остальными членами команды. Также поможет избежать лишних вопросов по типу «кто этим занимается и как с ним связаться». Все могут контактировать друг с другом напрямую.
В блоке «план / факт» мы ведем хронологию проекта. Чтобы не тратить много ресурса на заполнения, лучше актуализировать блок хотя бы раз в месяц по ключевым событиями и задачам. Это проще, чем сесть в конце квартала и пытаться восстановить в памяти, что было глобально сделано.
Сюда можно добавить результаты общих созвонов, зафиксировать договоренности с исполнителем и какие-то ключевые решения.
Этот раздел обычно заполняет разработчик или проектный менеджер. В нем мы описываем, как редактировать или управлять тем или иным блоком сайта. В будущем это сильно сэкономит время при работе с сайтом.
Вначале заполнять тяжело из-за больших объемов, но потом не приходится несколько раз объяснять одно и то же.
Удобно писать инструкцию по мере работы с проектом. Появился запрос на то, как что-то сделать, — заполняем и отдаем дальше в работу. Документ можно дополнить скриншотами и комментариями.
Приведем пример, как управлять блоками на главной странице сайта. Здесь может быть любая нужная для ваших задач инструкция:
Подробное описание взаимодействия с сайтом экономит время, а еще служит шаблоном для последующих инструкций.
На выходе у вас получится паспорт проекта, в котором хранится вся важная информация о вашем сайте. Опционально из него можно убрать доступы или, наоборот, добавить все необходимые доступы от сайта.
📍 Очень важно попросить вашего разработчика документировать код, но выполнять ли такую просьбу, зависит от вашего навыка вести переговоры и договариваться 🙂
Проверить код сложно, к сожалению, только если попросить нарезать скриншоты, что очень неудобно для заказчика. Как вариант, можно организовать работы через GitHab, чтобы каждый диплой можно было развернуто комментировать, — но это уже тема для отдельной статьи.
В остальном той информации, которая указана в примерах, вполне достаточно, чтобы составить хороший паспорт проекта и при необходимости быстро включить нового специалиста в проект.
Напишите нам - разработаем сайт под ваши потребности.