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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Уникальный дизайн, если есть — ссылка на фигму. Если используете шаблон, то напишите какой и приложите ссылку.

2. Pipeline задача — ссылка. Это таблица с задачами по технической поддержке.

3. Инструкция к сайту — ссылка.

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

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

Со стороны DS:

1. Иван Иванов (Тг — @Login) — руководитель проекта (писать по любому вопросу проекта, если не смогли решить или не поняли, к кому обратиться).

2. Иван Иванов (@Login) — тимлид отдела разработки (смотрит фоново, не тегаем).

3. Иван Иванов (@Login) — разработчик (пишем, чтобы что-то починил или сделал новое на сайте или сервере).

4. Иван Иванов (@Login) — дизайнер (пишем, чтобы сделал красивый визуал).

5. Иван Иванов (@Login) — контент-менеджер (поможет с контентными задачами или копипастом).

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

1. Иван Иванов (@Login) — COO (лучше не тегать, просто наблюдает за процессом).

2. Иван Иванов (@Login) — директор по digital marketing (по общим организационным вопросам).

3. Иван Иванов (@Login) — менеджер диджитал-маркетинга (к нему по вопросам контента на основных страницах сайта).

4. Иван Иванов (@Login) — бухгалтер (общаемся по вопросам счетов и закрывающих документов).

5. Иван Иванов  (@Login) — руководитель отдела редакции (идем с вопросами по блогу).

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

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

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

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

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

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

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

1. Заходим в административную панель сайта — site.ru/bitrix.

2. В правом навигационном меню переходим в раздел «Контент».

3. В открывшемся меню — выбрать вкладку «Справочники». В этой вкладке можно управлять главной страницей. 

4. Главную страницу редактируют по блокам.

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

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

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

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

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