Трехглавый проект WooCommerce: ваше агентство, фрилансер и разработчик вашего клиента

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

Если вы подошли к этапу, когда необходимо вызвать специалиста, на что следует обратить внимание? Как сделать новые «дополнения» максимально плавными? Но также: что, если у вашего клиента уже есть несколько собственных разработчиков?

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

Давайте углубимся в то, как вы можете справиться с таким сложным рабочим сценарием и превратить его в свое преимущество!

У вас должно быть хорошее общение, иначе ничего хорошего не будет.

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

Для этого многие агентства и разработчики используют Slack для групповых обсуждений из-за его многочисленных функций. Важность наличия общей точки зрения, при которой общение между всеми вовлеченными сторонами продолжается, далее уточняется экспертом WooExpert и Codeable Митчеллом Каллаханом из SAU/CAL, который говорит:

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

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

У вас должен быть надежный процесс для кода

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

Объясняет Митчелл:

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

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

Каждый должен знать, за что он отвечает

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

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

Это гарантирует отсутствие конфликта полномочий в отношении проекта и, конечно же, беспрепятственное выполнение процесса.

Инструменты управления проектами: выберите один и поделитесь им со всеми

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

Когда вы работаете с разработчиками-фрилансерами и штатными разработчиками вашего клиента над одним из ваших проектов, ваша цель состоит в том, чтобы все стороны были вовлечены в тот инструмент управления проектами, который вам наиболее удобен. Я знаю, это звучит довольно сложно, потому что у каждого есть свои предпочтительные инструменты. Но вот как Митчелл и ребята из SAUCAL могут завоевать расположение клиентов и разработчиков:

Например, многие люди используют Jira, а мы используем вместо нее Breeze. Некоторые люди, впервые увидев это, говорят нам: «О, это не кажется слишком мощным». И вот тут-то и вступает в действие образовательный компонент. Мы объясняем им, что делаем это годами для их одной и той же цели (создание сайтов WooCommerce). А для тех, кто действительно хочет быть толстым и тонким и частью процесса — обычно это разработчики — мы потратим время на обучение их тому, как использовать нашу систему, таким образом, мы все работаем в сплоченной, общей способ.

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

Подведение итогов

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

У кого самый слабый коммуникатор, тот и будет самым слабым звеном.

Маттео Дуо — контент-стратег в Codeable.io , аутсорсинговой платформе №1, ориентированной на WordPress, которая объединяет разработчиков WordPress мирового класса с предприятиями, нуждающимися в качественной работе. Он уже много лет активно взаимодействует с клиентами и разработчиками, документируя различные тонкости их отношений и предоставляя руководство о том, как использовать WordPress в качестве эффективного бизнес-актива.