Workspace Digital Awards 2025 — престижнейшая международная премия в сфере диджитал. Принять участие!
Назад
#Веб-разработка

Как принять проект на техническую поддержку? Делимся нашим процессом входа в новый проект.

47 
 

Почему задачу по новому проекту нельзя взять в работу уже сегодня? И что значит вам нужно время и ресурсы, чтобы принять проект в работу?

Отвечаем на эти вопросы и показываем наш процесс приёмки проекта на техническую поддержку и развитие.

Как принять проект на техническую поддержку? Делимся нашим процессом входа в новый проект.

Привет! Меня зовут Андрей Фролов, вместе с партнером Антоном Носковым развиваю студию заказной IT-разработки Metalcode. Мы занимаемся разработкой на PHP и Битрикс, развиваем ecom-проекты и помогаем увеличить прибыль компаний.

Чтобы начать работать с проектом, недостаточно просто получить доступы. Которые, кстати, никто не предоставит без подписания NDA и прочих документов.

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

1. Изучаем имеющуюся документацию, вот что она может из себя представлять в идеальном случае:

  • схема бизнес-процессов с кратким описанием;
  • схема архитектуры проекта – отражает е-ком систему в целом, где сам сайт только часть (обычно витрина + бэк для мобилки и других сервисов);
  • техническая документация с описанием нюансов реализации (тут может быть и авто-документирование, но в идеале все же иметь документ с описанием нюансов);
  • тест-кейсы и чек-листы для тестера;
  • описание API-шек (если в проекте реализован бэк для мобильных приложений или headless, любой другой интерфейс).

Но как известно документация есть далеко не всегда. И еще реже она поддерживается в актуальном состоянии. Поэтому на практике изучаем то, что есть =)

2. Разбираемся с продовыми / тестовыми контурами и процессами поставки.

В базовом варианте у проекта есть:

  • prod – основной контур, где все самое живое и реальные пользователи;
  • cтейдж (staging) - тестовый контур, куда сливаются все изменения, от всех команд и тестируются

Они связаны между собой системами контроля версий, миграциям БД, в идеале с настроенным CI/CD.

Если стейджа нет – надо его поднять. Также надо развернуть dev-копии для разработчиков, они могут быть урезанными относительно стейдж/прод. Здесь стоит не забыть про обфускации данных, чтобы в копии проектов не попали реальные пользовательские данные и в тоже время копии не были пустыми.

В итоге: разбираемся с тем что есть, поднимаем копии, настраиваем то чего не хватает (условно без CI/CD жить можно, без контроля версий никак).

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

3. Уточняем про бекапы

Именно уточняем. Нам давно не приходилось сталкиваться с полным отсутствием бекапов на проекте. Это лежит в области сервера и системного администрирования.

Но всегда уточняем частоту создания резервных копий, их полноту и прочие нюансы.

4. Прогоняем тест-кейсы

Подключаем к проекту тестировщика и делаем пользовательское тестирование. Надо понять что работает, а что не работает.

Все фиксируем в виде чек-листов, тест-кейсов и баг-репортов.


Разместите
тендер бесплатно

Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.

Заполнить заявку 12276 тендеров
проведено за восемь лет работы нашего сайта.


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

5. Проводим технический аудит

Самый сложный и наиболее важный этап. Надо посмотреть на проект изнутри.

Непосредственно на код, библиотеки, компоненты, модули, админку, базу. Составляем свои краткие заметки по проекту. Иногда сразу формируем бэклог по проблемным участкам.

Не строим иллюзий, что за полтора дня разработчик поймет и изучит проект. Но совместными усилиями с лидом, команда сможет сделать выводы о состоянии проекта. И сформировать список вопросов.

Обычно ведем эти работы параллельно с тестами.

6. Разбираемся с лицензиями

Проверяем актуальность лицензий Битрикса и платных модулей.

Выводы:

Что мы хотим получить от такой масштабной приемки проекта?

Понимание об устройстве и состоянии проекта. Настроенную инфраструктуру для старта разработки. Понимание о составе смежных команд, с которыми нам потребуется взаимодействовать.

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

Что получает заказчик?

Команду, которая погрузилась в проект.

Это не может полностью исключить ошибки и неверные решения, но значительно сокращает их количество.

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

Если вам интересно узнать больше о том, как работает наша команда, как мы сотрудничаем с разными ecom-проектами, какие решения придумываем и внедряем, подписывайтесь на телеграм-канал Metalcode.





Выскажите мнение
Авторизуйтесь, чтобы добавить свой комментарий.




47

Лучшие статьи

Поделиться: 0 0 0