Сохраняйте спокойствие и переходите в новую команду разработчиков

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

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

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

Передача факела: адаптация новой команды разработчиков

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

Но что, если вы не заменяете всю команду? Стоит ли вам утруждать себя чтением этого?

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

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

Итак, без лишних слов, давайте погрузимся!

Соберите документацию

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

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

Хорошая документация должна охватывать как минимум следующие темы:

• Настройка среды разработки . Первая задача любого новичка — настроить и запустить приложение на своих компьютерах. Процесс для этого зависит от технологии. Как правило, для этого требуются такие задачи, как получение исходного кода, настройка базы данных, установка зависимостей, настройка среды с ключами API и учетными данными, импорт демонстрационных данных и т. д. Разработчики имеют хорошее представление обо всем, что связано с этим процессом в своих областях, и должны иметь возможность соответствующим образом скорректировать детали.
• Запуск набора автоматизированных тестов . Прохождение тестов приложения гарантирует, что все настроено правильно и будущие изменения не нарушат какие-либо из ваших существующих функций.
• Развертывание на промежуточном и рабочем серверах . Обновление работающего приложения с учетом последних изменений — это процесс с четким сценарием, и порядок этих операций должен быть описан шаг за шагом и как можно более подробно.
• Любая другая информация, имеющая отношение к недавно присоединившемуся разработчику . У каждого приложения есть свой набор особенностей. Записывая их, будущие команды избавляют будущие команды от множества ненужных усилий по отладке проблем, с которыми предыдущая команда уже выяснила, как с ними справиться.

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

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

Если написание не является их сильной стороной, попросите их записать один или несколько скринкастов, демонстрирующих настройку среды разработки, развертывание и т. д. Сегодня даже существуют такие инструменты, как Vagrant и Docker, которые позволяют упаковывать целые среды разработки и распространять их среди других. По сути, вместо того, чтобы давать кому-то указания, как построить молот, дайте ему сам молот.

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

Поймите свой продукт

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

Следующие вопросы являются общими, и вы должны знать ответы без необходимости их искать:

• Какой стек технологий использует ваше приложение? - Существует много общих сред приложений для серверной и внешней части, и любая новая команда разработчиков должна быть знакома с теми, которые использует ваше приложение. Некоторыми примерами серверных веб-технологий являются Ruby on Rails, Node.js и Django. Некоторыми примерами интерфейсных веб-технологий являются React.js, Angular.js и Ember.js.
• Где он размещен? - У разных веб-хостов разные процессы развертывания, которые требуют разного уровня опыта. В последние годы облачные технологии создали ряд новых вариантов хостинга, и вам необходимо определить, какой именно вы используете, и объяснить, почему он был выбран среди других.
• Каков процесс разработки? — Использует ли ваша команда определенный инструмент управления исходным кодом, такой как Git? Если да, то каков процесс разработки, тестирования, утверждения и развертывания новой функции? Процесс должен быть стандартизирован, должным образом задокументирован и легко воспроизводим новичками.
• Какие сторонние сервисы использует ваше приложение? - Некоторые приложения построены на сторонних сервисах, таких как Shopify. Имейте в виду, что зависимость от сторонних сервисов постепенно растет, и даже если вы в настоящее время не используете какие-либо дополнительные сервисы, ваш проект может решить использовать сторонние сервисы через некоторое время.
• На каких платформах может работать ваше приложение? – Является ли ваше приложение настольным приложением, веб-приложением, адаптивным мобильным веб-сайтом, родным приложением для iOS, родным приложением для Android или чем-то еще? Он работает на нескольких разных платформах? Какая платформа является для вас приоритетной в любой момент времени? На какой платформе ваш продукт сильнее и слабее всего? Обязательно узнайте все подробности о текущих платформах вашего приложения и даже о том, на какие из них оно может быть расширено.

Стать владельцем

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

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

Ниже приведен список различных внешних инструментов или служб, которые может использовать ваше приложение:

• Управление системой контроля версий — GitHub, Bitbucket, Gitlab
• Веб-хостинг - Heroku, EngineYard, Digital Ocean, Bluehost, Amazon Web Services
• Файловый хостинг — Amazon Web Services (S3)
• Поставщик DNS — GoDaddy, DNSimple, Hover
• Услуги по разработке — NewRelic, FileStack, Segment, Bugsnag (и множество других)
• Платежные сервисы — Stripe, Braintree, PayPal
• Услуги по ведению блогов — WordPress, Tumblr, Ghost
• Решения для электронной коммерции - Shopify, Squarespace
• Аналитика/отслеживание – Google Analytics, Mixpanel, Kissmetrics
• Электронный маркетинг: MailChimp, постоянный контакт

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

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

Предоставление доступа

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

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

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

Управление передачей

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

Входящая команда

• Установите ожидания . Новая команда должна знать, каковы ваши самые важные цели, чтобы они могли сосредоточиться в правильном направлении. Не менее важно управлять своими собственными ожиданиями относительно того, чего новая команда может достичь сразу.
• Чаще проверяйте . Не оставляйте новую команду на произвол судьбы. Вы хотите часто проверять, чтобы убедиться, что у них есть все, что им нужно, и не чувствовать, что они должны постоять за себя. Попробуйте сделать это без микроменеджмента. Убедитесь, что они знают, что вы готовы поддержать и помочь, если они в этом нуждаются, но не оказывайте на них ненужного давления.
• Будьте терпеливы — разработчикам требуется время, чтобы привыкнуть к новой кодовой базе. Поймите, что потребуется некоторое время для обучения, прежде чем новая команда сможет соответствовать темпам предыдущей.

Уходящая команда

• Соберите весь ожидающий код . Убедитесь, что весь исходный код зарегистрирован в основном репозитории, и что вы знаете статус того, что было или не было развернуто. Новой команде нужно будет точно знать, с чего начать работу. Я сам столкнулся с ситуацией, когда я взял на себя команду, которая развернула код, не помещая его в основной репозиторий. Это привело к ошибкам, дублированию работы и головной боли, которых можно было бы легко избежать, если бы уходящая команда оставила исходный код в согласованном состоянии.
• Обновите их уровень доступа . Если вы расстались на хороших условиях, вы можете оставить им доступ к вашему коду и/или развертыванию. Многие команды рады помочь на переходном этапе, пока новая команда не сможет полностью взять на себя управление. Если нет, рассмотрите возможность понижения или отзыва доступа, чтобы предотвратить любые случайные проблемы или конфликты с новой командой.
• Поблагодарите их за работу — переходы могут быть беспокойными. Пока вы заняты работой с новой командой, не забудьте поблагодарить уходящую команду за их вклад в ваш проект.

Заключение

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

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

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

Итак, давайте рассмотрим ключевые моменты, которые должны предшествовать любой передаче права собственности на ваш программный продукт:

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