Что мы учитываем при приемке проекта на техническую поддержку
Почему задачу по новому проекту нельзя взять в работу уже сегодня? И что значит вам нужно время и ресурсы, чтобы принять проект в работу?
Отвечаем на эти вопросы и показываем наш процесс приёмки проекта на техническую поддержку и развитие.
Привет! Меня зовут Андрей Фролов, вместе с партнером Антоном Носковым уже 10 лет руковожу бутик-агентством Metalcode. Мы занимаемся разработкой на PHP и Битрикс, развиваем ecom-проекты и помогаем увеличить прибыль компаний.
Чтобы начать работать с проектом, недостаточно просто получить доступы. Которые, кстати, никто не предоставит без подписания NDA и прочих документов.
Здесь не будем разбирать юридические аспекты, перейдем сразу к практическим. Какие работы нам нужно выполнить, чтобы принять проект на сопровождение и развитие:
1. Изучаем имеющуюся документацию, вот что она может из себя представлять в идеальном случае:
- схема бизнес-процессов с кратким описанием;
- схема архитектуры проекта – отражает е-ком систему в целом, где сам сайт только часть (обычно витрина + бэк для мобилки и других сервисов);
- техническая документация с описанием нюансов реализации (тут может быть и авто-документирование, но в идеале все же иметь документ с описанием нюансов);
- тест-кейсы и чек-листы для тестера;
- описание API-шек (если в проекте реализован бэк для мобильных приложений или headless, любой другой интерфейс).
Но как известно документация есть далеко не всегда. И еще реже она поддерживается в актуальном состоянии. Поэтому на практике изучаем то, что есть =)
2. Разбираемся с продовыми / тестовыми контурами и процессами поставки.
В базовом варианте у проекта есть:
- prod – основной контур, где все самое живое и реальные пользователи;
- cтейдж (staging) - тестовый контур, куда сливаются все изменения, от всех команд и тестируются
Они связаны между собой системами контроля версий, миграциям БД, в идеале с настроенным CI/CD.
Если стейджа нет – надо его поднять. Также надо развернуть dev-копии для разработчиков, они могут быть урезанными относительно стейдж/прод. Здесь стоит не забыть про обфускации данных, чтобы в копии проектов не попали реальные пользовательские данные и в тоже время копии не были пустыми.
В итоге: разбираемся с тем что есть, поднимаем копии, настраиваем то чего не хватает (условно без CI/CD жить можно, без контроля версий никак).
Важную часть этого этапа составляют встречи с инфраструктурными командами при их наличии (сисадминами, девопсерами, безопасниками).
3. Уточняем про бекапы
Именно уточняем. Нам давно не приходилось сталкиваться с полным отсутствием бекапов на проекте. Это лежит в области сервера и системного администрирования.
Но всегда уточняем частоту создания резервных копий, их полноту и прочие нюансы.
4. Прогоняем тест-кейсы
Подключаем к проекту тестировщика и делаем пользовательское тестирование. Надо понять что работает, а что не работает.
Все фиксируем в виде чек-листов, тест-кейсов и баг-репортов.
Это не будет исчерпывающим покрытием проекта тестами. Но даст представление о состоянии сайта с пользовательской точки зрения.
5. Проводим технический аудит
Самый сложный и наиболее важный этап. Надо посмотреть на проект изнутри.
Непосредственно на код, библиотеки, компоненты, модули, админку, базу. Составляем свои краткие заметки по проекту. Иногда сразу формируем бэклог по проблемным участкам.
Не строим иллюзий, что за полтора дня разработчик поймет и изучит проект. Но совместными усилиями с лидом, команда сможет сделать выводы о состоянии проекта. И сформировать список вопросов.
Обычно ведем эти работы параллельно с тестами.
6. Разбираемся с лицензиями
Проверяем актуальность лицензий Битрикса и платных модулей.
Выводы:
Что мы хотим получить от такой масштабной приемки проекта?
Понимание об устройстве и состоянии проекта. Настроенную инфраструктуру для старта разработки. Понимание о составе смежных команд, с которыми нам потребуется взаимодействовать.
И конечно же прощупать узкие места. По итогам приемки проекта у нас формируются документы с вопросами и баг-репорты. Почти все вопросы обычно удается решить сразу, взаимодействуя с другими командами: 1С, мобильная разработка, системные администраторы.
Что получает заказчик?
Команду, которая погрузилась в проект.
Это не может полностью исключить ошибки и неверные решения, но значительно сокращает их количество.
Моё мнение, что это хорошо показывает отличие профессионалов от халтурщиков, которые с наскока берут задачи в работу, а потом разгребают последствия.
Если вам интересно узнать больше о том, как работает наша команда, как мы сотрудничаем с разными ecom-проектами, какие решения придумываем и внедряем, подписывайтесь на телеграм-канал Metalcode.
Надо отметить, насколько важным для команды-подрядчика является онбординг в проект силами заказчика. Ответственного менеджера или руководителя направления.
Понятно, что умные ребята и сами во всем разберутся. Но можно им сильно облегчить работу – если будет человек, который расскажет как все устроено, передаст инструкции и сделает акценты – что могло устареть, что точно актуально и тд.
Добавит в рабочие чатики и даст контакты всех нужных спецов, кому можно задать вопросы по инфре и проекту.
Идеальная ситуация. Это работает и в строну заказчика. У него также должен быть процесс ввода нового подрядчика.
Вспоминаются времена лет эдак 10 назад, когда всё, что мог передать нам потенциальный заказчик по сайту – это доступ к хостингу (легко до подписания договора, а про NDA вообще никто не знал) и список задач в виде “Не работает интеграция с 1С” – бросает в холодный пот.
Современный е-ком сильно сложнее. И чтобы принять проект – нужно попотеть)