Полезные советы, которые можно применить в проектах с несколькими командами
Непросто быть частью проекта, требующего совместной работы нескольких команд. В случае неправильного управления это может стоить вам и вашей организации ценных человеко-часов и ресурсов.
На протяжении всей моей карьеры в качестве старшего инженера-программиста и технического менеджера мне выпала честь руководить разработкой среднего и крупного программного обеспечения, которое требует координации между несколькими командами и заинтересованными сторонами. Взлеты и падения, которые я испытал на этом пути, научили меня многому в отношении ведения межкомандных инициатив - и я делал заметки и записывал в дневнике то, что узнал. Я подумал, что было бы хорошо поделиться общими темами и тем, что мы сделали, чтобы свести к минимуму вероятность задержек и неудач проекта.
Советы здесь не ограничиваются командами внутри одной компании. Они также могут применяться для работы со сторонними командами; например, вашей команде необходимо работать над интеграцией API с командой поставщика программных услуг.
Необязательно следовать всем приведенным здесь советам. Выбирайте то, что вам нужно, в зависимости от характера вашего проекта. Кстати, в этой статье слово «проект» может относиться к новой функции продукта, сторонней интеграции или любой большой работе, которую несколько команд в компании должны выполнить в течение определенного периода времени. Давайте начнем.
1. Проведите стартовое совещание.
В начале каждого проекта соберите всех участников и официально «запустите» проект. Я знаю, что вы, наверное, сейчас кричите в голове: «Еще одна встреча ?!»
Это не просто «очередная встреча».
Стартовое собрание - хорошее время, чтобы все представились, поставили лица перед именами. Это важно, особенно когда команды работают удаленно. Это помогает сломать лед для тех, кто никогда раньше не работал вместе.
Во время введения попросите всех рассказать несколько интересных вещей о себе - своих увлечениях, чем они занимались на выходных, что они ели на ужин вчера вечером… Это избавляет от неловкости, рассказывая о том, как все выглядят как личности.
Это также возможность для владельца продукта, лида (ов) и заинтересованных сторон рассказать о целях, задачах, дорожной карте, KPI, «почему» или о чем-либо еще, что вдохновит команду.
Это возможность для каждого высказать свое мнение: вопросы, предложения и опасения. Эти данные помогут вам решить возможные проблемы, которые могут возникнуть, учитывая различный опыт, который команды имели в прошлом.
Обсуждение должно вестись на высоком уровне. Если вам нужно углубиться в конкретные темы, отключите их.
2. Предоставьте ключи API и данные для входа в систему заранее
Мы все были в ситуации, когда мы собирались протестировать RESTful API или хотим получить доступ к панели отчетов только для того, чтобы узнать, что у нас нет доступа. Получение доступа заранее имеет решающее значение, в первую очередь, если команда может предоставить его нам из другого места или другого часового пояса.
Отсутствие паролей или секретных ключей для доступа к важной информации может отложить принятие важного решения. Если мы заранее получим необходимые данные для аутентификации, это сэкономит нам и нашей команде драгоценное время.
Надежно делитесь своими секретами и паролями с помощью таких инструментов, как LastPass и Vault.
3. Делитесь актуальной документацией
Удаленная работа научила нас важности асинхронной связи, а также важности ведения соответствующей документации. Хорошо написанная и актуальная документация помогает привлечь новых членов команды и соавторов. В хорошей документации должны быть ответы еще до того, как мы задумаемся о том, чтобы их задать.
Задавать вопросы следует поощрять. Однако надлежащая документация может сэкономить время наших команд, не позволяя им возвращаться и возвращаться в цикле вопросов и ответов. Вместо встречи могло быть отправлено электронное письмо. Несколько предложений или диаграмм сэкономят человеко-час ответов на вопросы.
Confluence, Google Docs и Draw.io - полезные инструменты для документирования. Конечно, вам также следует постоянно обновлять файл Readme.md своего репозитория.
4. Настройте среду песочницы для тестирования API.
Помимо документации, критически важна среда песочницы, в которой команды могут безопасно возиться с API, особенно на ранних этапах межгруппового проекта.
Одного чтения документации недостаточно. Инженеры должны будут понять, как работают API-интерфейсы, и сформулировать, как они будут писать свой код или разрабатывать свое программное обеспечение на основе этих API. API-интерфейсы песочницы также удобны для подготовки прототипов и тестирования локальной среды разработки.
5. Настройте выделенный канал связи.
Создайте общедоступный канал в Slack (или другом средстве обмена сообщениями, который вы используете), посвященный вашему межкомандному проекту. Канал может быть временным, в зависимости от того, как долго вам нужно сотрудничать с другой командой в одном проекте. Сделайте канал общедоступным, чтобы информация была видна всем в организации. Это поможет релевантным людям найти ваш канал и присоединиться к нему.
Используйте этот канал, чтобы делиться информацией, например документами и важными объявлениями, а также задавать вопросы и делиться идеями. Лучше всего задавать вопросы о проекте в вашем общем канале и попросить кого-нибудь ответить на него напрямую в этой ветке. Это позволяет вам легко поделиться ответом, если кто-то задаст тот же вопрос. Избегайте задавать вопросы, связанные с проектом, в личных сообщениях. Если кто-то случайно отправит вам вопрос, связанный с проектом, в частном порядке, напомните ему опубликовать вопрос на вашем общем канале. На канале может быть другой человек, который сможет ответить на этот вопрос, и этот ответ может быть полезен другим членам команды на канале.
6. Вести проектную документацию
У сотрудничающих команд должен быть общий план того, как различные компоненты системы работают вместе, и согласовываться этот план. Подготовьте проектный документ, содержащий подробную информацию о технической архитектуре вашего проекта или конструкции системы. Получите отзывы команд, внесите некоторые изменения в план и доработайте документ.
Этот документ станет планом для сотрудничающих команд при создании проекта. Инженеры должны вернуться к этому документу при написании кода и прояснить любые сомнения относительно проектных решений.
7. Создайте документ терминологии или глоссария.
Были ли у вас когда-нибудь такие встречи, на которых казалось, что все разговаривают друг с другом? Как насчет того, чтобы застрять в одной теме, потому что используемая терминология кажется согласованной, но позже вы узнали, что существуют разные интерпретации? Однажды я был участником проекта, и позже мы выяснили, что две команды использовали одно и то же имя для каждой из своих соответствующих веб-сервисов, что делало разные вещи.
Чтобы избежать подобных ситуаций, ведите живой документ, содержащий терминологию, жаргон и акронимы с определениями, которые имеют отношение к контексту вашего проекта. Так что в следующий раз, когда будут обсуждения, все будут знать, что вы имеете в виду, когда используете определенные слова. Называть вещи уже достаточно сложно; Давайте также заранее проясним значения этих имен.
8. Вести журнал решений.
Вы и ваша команда будете принимать микро- и макрорешения на протяжении всего проекта, от определения стандартов кодирования до выбора технологического стека или принятия архитектурных решений высокого уровня.
Иногда командам необходимо пересмотреть эти решения, чтобы в будущем сделать их лучше. Или нам может потребоваться отменить отдельные решения и изменить курс. Журналы решений дают нам контекст того, почему мы приняли определенные решения в первую очередь, что может помочь в формировании нашего будущего принятия решений. Вы можете представить эти журналы решений в виде таблицы или электронной таблицы в Confluence или Google Docs.
9. Заключите контракт API.
Межкомандные проекты вводят зависимости между командами. Например, группа A владеет клиентом X, а группа B владеет веб-службой Y. Для поддержки новой функции, необходимой для проекта, группе A потребуется помощь группы B для создания новой конечной точки API в веб-службе Y, которую может использовать клиент X. Это означает, что команде A и группе B необходимо будет согласовать, как должны выглядеть запрос и ответ между клиентом X и веб-службой Y.
Прежде чем создавать что-либо в клиенте или веб-службе, договоритесь о контракте API. После согласования контракта API обеими командами - и при условии, что веб-служба Y вернет ответ после получения запроса, указанного в контракте API, - команда A может начать работу над функцией клиента X. Команда A будет издеваться над ответом, пока новая конечная точка на веб-сервисе Y находится в разработке. Используйте буферы протокола, спецификацию JSON или псевдокод для документирования и совместного использования контракта API.
10. Настройте повторяющуюся синхронизирующую встречу.
Совместное использование обновлений с помощью Slack или Jira может работать для обновлений статуса, чтобы указать, находится ли задача «в процессе» или «выполнена». Тем не менее, такие обсуждения, как устранение препятствий, согласование объема переговоров или согласование более быстрого решения, возможно, потребуется обсудить на встрече.
Используйте синхронизирующую встречу для завершения обсуждений или ответов на вопросы, которые сложнее решить с помощью асинхронной связи. Если нет открытой проблемы, для решения которой требуется собрание, пропустите ее. Частота этих синхронизаций будет зависеть от предпочтений, динамики и ситуации команд. Я участвовал в межкомандных проектах, где синхронизация происходила всего один или два раза в неделю. В других случаях, когда проект откладывается, они могут быть такими же частыми, как каждый день.
Заключение
Не ограничивайтесь только приведенными выше советами. Измените эти советы в соответствии со своими потребностями. Придумайте собственный набор действий. Собирайте отзывы, повторяйте эти наборы действий и продолжайте делать то, что работает, в зависимости от результатов. Еще лучше, если результаты можно будет измерить и подкрепить данными.
Если вам понравилась эта статья, ознакомьтесь с этой статьей о гибких командах:
