Коммуникация в команде (это важнее, чем ваши инструменты)

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

o Каково это — перейти от работы над проектами в одиночку к работе над проектами в команде?

Или, проще говоря, каково это иметь подрядчиков? Короткий ответ: я копаю его, потому что он дает некоторые преимущества:

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

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

Как начать с чистого листа.

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

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

Командное общение

Очевидно, что эта конкретная тема широка, и я, как и многие из вас, мог бы говорить о самых разных вещах, связанных с ведением бизнеса.

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

Ваши инструменты имеют значение (но не так много)

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

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

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

Visual Studio Code стала моей любимой IDE.

Во-первых, когда вы работаете на себя, у вас, вероятно, есть любимые:

• ИДЕТ
• система контроля версий,
• инструменты для сборки,
• средства развертывания,
• среда хостинга,
• и так далее.

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

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

Но есть кое-что, что стоит выше всего этого, что никогда нельзя недооценивать, и это процесс командного общения.

Коммуникация имеет значение (и многое другое)

Я не говорю о том, чтобы проверять настроение людей каждый день (хотя это важно), и я не говорю о текстовом чате, Slack или IRC просто ради того, чтобы вы чувствовали себя продуктивно.

Коммуникация в команде — это больше, чем Slack.

Я говорю о полностью сообщающихся требованиях.

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

Проблема здесь ясна, не так ли? Он/она понятия не имеет, что нам нужно.

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

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

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

Это нельзя недооценивать.

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

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

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

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

Еще не все

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

Не поймите меня неправильно: это фантастическая вещь (и мне это нравится), но она требует корректировок на уровнях, к которым я не был полностью готов.

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