В Makers Academy вы учитесь разными способами — в парах, наставничестве, семинарах — но кривая обучения, вероятно, наиболее крутая, когда вы выполняете один из более длительных групповых проектов в последние недели.

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

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

гоооооооооооооооооооооооооооооооооооооооооооо

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

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

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

Поэтому, когда на неделе 2 нам дали новые требования к клиенту (несколько новых функций и переход на новый стек с использованием Express и React), несмотря на большое искушение погрузиться в React, наши четкие цели означали, что сосредоточиться на них не составило труда. создание новых функций в Rails.

Вот как заставить цели работать на вас:

  • Написание хороших целей занимает больше 10 минут. Начните с понимания вашего брифа: какие наиболее важные элементы или критические факторы успеха вам необходимо учесть, чтобы добиться успеха? Когда это станет ясно, попытайтесь понять индивидуальные мотивы людей в команде. Обсудите это в группе и исследуйте — если кто-то говорит: «Я хочу научиться работать в команде», выясните, почему, как выглядит «хорошо», как они измеряют эту цель?
  • Напишите свои цели в виде твердых утверждений, которые вы хотите сказать в конце проекта, это сделает их более реальными. «Я хочу улучшить рецензирование кода» — это нормально. «Я даю конструктивную обратную связь, которая помогает члену моей команды стать лучшим разработчиком» — лучше.
  • Держите их простыми. Держите список коротким.
  • Старайтесь не упускать их из виду, когда дела пойдут в гору. Покажите их в начале встречи по планированию, чтобы напомнить людям о том, что было согласовано. Вещи всегда будут меняться, поэтому убедитесь, что они по-прежнему имеют смысл, когда вы продвигаетесь по работе.
  • Когда вам неизбежно нужно расставить приоритеты или найти развилку на дороге, используйте их, чтобы направлять процесс принятия решений и двигаться вперед с четким направлением.

Как перед чем

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

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

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

Другие вещи, которые нужно решить заранее:

  • Когда ты будешь работать? Есть ли у людей обязательства утром/вечером/в течение дня? Когда люди уезжают? Когда люди лучше всего?
  • Как вы будете париться? Будете ли вы держать двух человек над функцией, пока она не будет завершена (даже если это займет пару дней), или будете менять по одному каждый день? Каждые полдня?
  • Какова ваша стратегия на случай, если один человек или пара застревают в задании? Будете ли вы все вниз инструменты, чтобы помочь? Вы хотите установить ограничение по времени для заблокированной активности, прежде чем что-то менять? В какой момент вы попросите помощи извне?
  • Насколько все открыты для обратной связи? Есть ли у людей предпочтительный способ предоставления и получения обратной связи?
  • Как кто-то получает от вас лучшее? А остальные в команде? Фреймворки, такие как Myers Briggs, могут быть действительно полезным способом сообщить друг другу, что можно и чего нельзя делать во время групповой работы.

Делиться заботой

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

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

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

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

Ретро круто

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

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

Слушай свою интуицию

Я считаю, что работа над проектом может быть немного похожа на свидание с кем-то — если это кажется слишком трудным, это, вероятно, потому, что это неправильно!

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

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

Итак, мы вызвали аварийную ретро-службу и довольно откровенно поговорили о том, что идет хорошо, а что можно было бы улучшить. В конце концов, мы приняли действительно смелое решение полностью изменить наш проект на 3-й день (из 10). Хотя мы потеряли время, мы работали намного лучше, и, оглядываясь назад, это было абсолютно правильно.

Есть ли какие-нибудь другие советы для отличной групповой работы? Не стесняйтесь добавлять свои мысли в комментариях ниже — и спасибо за чтение!