Как проконтролировать процесс разработки сайта при работе с подрядчиками

Себя, сайт и целый бизнес можно обезопасить. Пусть хоть все перевернется вверх дном — есть волшебная кнопка «Сохранить». И называется она «Паспорт проекта». О нем и поговорим 😏

Что такое паспорт проекта и зачем он нужен

Паспорт проекта — документ, в котором зафиксированы технологический стек, описываются его технические параметры и основные сведения, инструкции и аспекты разработки. Это как паспорт вашего устройства, например смартфона.

Паспорт можно вести в удобном формате: Google или Яндекс Документах, ворде или где угодно еще. Главное — сохраните и держите под рукой, чтобы всегда можно было обратиться к нему и дополнить.

→ Эта статья — буквально большой чек-лист для проверки работы подрядчика.

Сейчас по порядку: какие разделы должны быть в паспорте проекта, чтобы на любом этапе даже новый специалист смог разобраться, что же ему делать.

Конфигурация сервера или хостинга

В разделе «Конфигурация сервера или хостинга» можно попросить вашего разработчика написать:

где ваш сайт хранится, — желательно в формате «ссылка + доступы»;
какая конфигурация стоит на вашем сервере и хостинге, описать мощности;
сколько стоит сервер или хостинг в год, когда пополнять баланс.

📍 Важно актуализировать информацию по мере обновления доступов и тарифов.

Типовой сайт обычно содержит в себе плюс-минус одинаковые данные, поэтому подготовили для вас небольшие подсказки. Вот что обычно включают в описание сайта:

1. Доступ к серверу. Сервер — то, где хранятся файлы вашего сайта. Обычно сервер арендуется у хостинг-провайдера. Доступ нужен, чтобы пополнять счета и верхнеуровнево управлять сайтом. Например, так может выглядеть описание доступа:

Сервер: timeweb.com;
Логин: login;
Пароль: pass.

2. Доступ к консоли позволяет точечно и гибко управлять самим сервером:

IP: 127.0.0.1;
Port: 22;
login: root;
Password: 12345678;
Доступ к консоли с помощью SSH-соединения.

3. Конфигурацию сервера — то, что помогает поддерживать производительность всей системы сайта. Например:

4 CPU;
8 Гб RAM;
80 Гб NVMe (UPD 27.06 увеличили до 120 Гб NVMe);
Ubuntu 22.04;
php 8.1.27 (тюнинг настроек, увеличены лимиты);
memcached (увеличены лимиты);
nginx (тюнинг настроек, число воркеров переведено из 8 в auto, добавлено gzip-сжатие).

4. Бэкапы — резервная копия данных, которая хранится отдельно, чтобы можно было восстановить утерянное. Например:

2 бэкапа по понедельникам перезаписывают друг друга;
1 бекап раз в месяц на сервер, каждое 16 число в 0:17 — директория, куда заливается «скриншот»;
ежедневный бекап базы данных с пн. по вс., перезаписывают друг друга.

Доступы к серверу, консоли, конфигурацию сервера и бэкапы надо фиксировать, чтобы не потерять накопленные данные. Благодаря этому можно легко подключить к работе нового спеца.

Технологический стек сайта

Технологический стек — это набор технологических решений, используемых для создания приложения или веб-сайта. Технологический стек также может называться стеком решений, технологической инфраструктурой или экосистемой данных.

Тоже подключаем разработчика, чтобы помог заполнить раздел паспорта. Выглядеть может вот так:

Bitrix лицензия «Бизнес»;
Верстка сделана на Vue.js;
Если используете шаблон, то напишите какой. Например, Aspro next;
Интеграция с «1С Склад»;
Используется эквайринг Альфа Банка;
Используется модуль расчета доставки СДЭК;
Если используются самописные интеграции, то обязательно напишите об этом тут.

В целом в раздел вносим все данные о жизненно важных бизнес-процессах, модули или интеграции и самописные решения.

Ссылка на самые популярные проектные документы

В этом блоке обычно кладем ссылки на различные важные документы. Например:

Уникальный дизайн, если есть — ссылка на фигму. Если используете шаблон, то напишите какой и приложите ссылку.
Pipeline задача — ссылка. Это таблица с задачами по технической поддержке.
Инструкция к сайту — ссылка.

Если вы — агентсво, можно добавить договор, коммерческое предложение, гант работ и прочее. В целом этот блок можно использовать для дальнейшей навигации по всем документам.

Команда проекта

Важно перечислить всех участников команды — дизайнеров, контент-менеджеров, маркетологов, тимлида, руководителя и прочих. Также важно указать роль на проекте каждого участника. Это поможет всем легко поддерживать связь и без лишних выяснений обратиться с возникшей проблемой адресно. Участников команды можно перечислить со стороны заказчика и со стороны агентства, например:

Со стороны DS:

Иван Иванов (Тг — @Login) — руководитель проекта (писать по любому вопросу проекта, если не смогли решить или не поняли, к кому обратиться).
Иван Иванов (@Login) — тимлид отдела разработки (смотрит фоново, не тегаем).
Иван Иванов (@Login) — разработчик (пишем, чтобы что-то починил или сделал новое на сайте или сервере).
Иван Иванов (@Login) — дизайнер (пишем, чтобы сделал красивый визуал).
Иван Иванов (@Login) — контент-менеджер (поможет с контентными задачами или копипастом).

Со стороны клиента:

Иван Иванов (@Login) — COO (лучше не тегать, просто наблюдает за процессом).
Иван Иванов (@Login) — директор по digital marketing (по общим организационным вопросам).
Иван Иванов (@Login) — менеджер диджитал-маркетинга (к нему по вопросам контента на основных страницах сайта).
Иван Иванов (@Login) — бухгалтер (общаемся по вопросам счетов и закрывающих документов).
Иван Иванов (@Login) — руководитель отдела редакции (идем с вопросами по блогу).

Роли могут отличаться в зависимости от проекта, но суть одна: фиксируем в документе участников команды, их роли и способ связаться. Этот блок помогает тем, что при появлении нового участника в проекте вы быстро сможете познакомить его с остальными членами команды. Также поможет избежать лишних вопросов по типу «кто этим занимается и как с ним связаться». Все могут контактировать друг с другом напрямую.

План / факт работы в разрезе месяца

В блоке «план / факт» мы ведем хронологию проекта. Чтобы не тратить много ресурса на заполнения, лучше актуализировать блок хотя бы раз в месяц по ключевым событиями и задачам. Это проще, чем сесть в конце квартала и пытаться восстановить в памяти, что было глобально сделано.

Сюда можно добавить результаты общих созвонов, зафиксировать договоренности с исполнителем и какие-то ключевые решения.

Общая инструкция, как пользоваться сайтом

Этот раздел обычно заполняет разработчик или проектный менеджер. В нем мы описываем, как редактировать или управлять тем или иным блоком сайта. В будущем это сильно сэкономит время при работе с сайтом.

Вначале заполнять тяжело из-за больших объемов, но потом не приходится несколько раз объяснять одно и то же.

Удобно писать инструкцию по мере работы с проектом. Появился запрос на то, как что-то сделать, — заполняем и отдаем дальше в работу. Документ можно дополнить скриншотами и комментариями.

Приведем пример, как управлять блоками на главной странице сайта. Здесь может быть любая нужная для ваших задач инструкция:

Заходим в административную панель сайта — site.ru/bitrix.
В правом навигационном меню переходим в раздел «Контент».
В открывшемся меню — выбрать вкладку «Справочники». В этой вкладке можно управлять главной страницей.
Главную страницу редактируют по блокам.

1 экран — скриншот редактируется блоке «Слайдер на главной».
Блок «Экономический эффект» — редактируется в блоке «Главная — экономический эффект».
Блок «Ваши результаты» редактируется в блоке «Ваши результаты».
Блок «Автоматизация» редактируется в «Отзывах».
Отредактировать «Ключевые продукты» —в блоке «Главная — ключевые продукты».
«Мы создали» редактируется в блоке «Главная — центр».
Блок «Какой путь мы пройдем» можно изменить в «Главная — путь к цели».
Блок «Как продукт изменит жизнь» редактируется в блоке «Главная — для кого»
«Почему site» можно изменить, перейдя на вкладку «Главная — почему site?».
Блок «Узнайте, как site» редактируется в блоке «Главная — Видео».
Блок «Нас рекомендуют» можно изменить в «Главная — нас рекомендуют».

Подробное описание взаимодействия с сайтом экономит время, а еще служит шаблоном для последующих инструкций.

На выходе у вас получится паспорт проекта, в котором хранится вся важная информация о вашем сайте. Опционально из него можно убрать доступы или, наоборот, добавить все необходимые доступы от сайта.

📍 Очень важно попросить вашего разработчика документировать код, но выполнять ли такую просьбу, зависит от вашего навыка вести переговоры и договариваться 🙂

Проверить код сложно, к сожалению, только если попросить нарезать скриншоты, что очень неудобно для заказчика. Как вариант, можно организовать работы через GitHab, чтобы каждый диплой можно было развернуто комментировать, — но это уже тема для отдельной статьи.

В остальном той информации, которая указана в примерах, вполне достаточно, чтобы составить хороший паспорт проекта и при необходимости быстро включить нового специалиста в проект.

Напишите нам - разработаем сайт под ваши потребности.