7 правил взаимодействия с аутсорс — командами

Веб-разработка на аутсорсинге всегда имеет свои подводные камни, которым свойственно скрываться за спойлерами и резко возникать в различных, неудобных ситуациях. Такие «камни» имеют вес в 10 — 30% работы от общего количества поставленных задач.

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

1. Предоставлять максимальную обратную связь

Дабы реализовать качество, нужно проводить итерации в рабочем процессе, анализировать происходящее со временем. Лучше всего, обсуждать работу каждый день, 15-20 минут оговаривать результаты кода-ревью. Данное действие поможет вам понять слабые стороны, и своевременно их устранить, пока вы не зашли слишком далеко и не наломали при этом дров.

2. Следить за валидацией кода

Тимлид команды отвечает за качество работы, тем самым, обязан проверять исправность кода. Без этих действий, архитектура продукта может значительно пострадать, а требования «расплыться». В ваших же интересах, проводить проверку на безопасность Топ-10 OWASP.

3. Внедрить стандарты PSR

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

4. Распределить задачи от каждого по способностям

Мало того, что разные разработчики специализируются в чем-то лучше других, но и целые команды могут быть успешнее только в определенной сфере. Например в промо-лендингах или только в онлайн-магазинах. Ваша задача проанализировать команду тестовым заданием, а в дальнейшем создать skype – собеседование, где, возможно, попросить команду заменить одного разработчика на более сильного кандидата. Допустимо, что при разработке у вас будет трудиться несколько команд на различных «кусках» кода, что может положительно сказаться на эффективности создания веб-страницы.

5. Подход тестирования TDD

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

6. Строго соблюдать чек-листы

Не забывайте проверять самые «узкие» места разработки на каждом из этапов. Такие ошибки могут быть чреваты последствием утраты времени и денег.

7. Реализовать матрицу автотестов преимущественного функционала

Данный пункт — это ваша парафия, вы должны позаботиться об этом. Ранжируйте самый важный функционал в проекте и оптимизируйте взаимодействие между аутсорс — командой и внутренним отделом QA. Пропишите пользовательские сценарии, которые будут объяснять действия для того или иного процесса на продуктовой странице. Автоматизация такого взаимодействия, даст вам привилегии в контроле исправности потребительского функционала.