Нормы общения и взаимодействия в команде - atls/convention GitHub Wiki

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

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

Как вести обсуждение в Issue, Чатах, Войсчатах

Что бы обсуждение было наиболее эффективным, следует соблюдать несколько простых правил и рекомендаций.

Используй цитирование

В Github не предусмотрена система тредов внутри Issue из-за этого в обсуждениях может происходить путаница.

Что бы не запутаться мы используем инструмент цитирования — ">".

Это позволяет сохранять нить обсуждения и «не распыляться» в обсуждении.

Пиши грамотно

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

Если сделал ошибку в своём сообщении и позже её заметил, поправь. В GitHub есть редактирование.

Старайся четко формулировать вопросы и мысли

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

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

Вот некоторые рекомендации по теме:

Используй Markdown

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

Сдерживай себя

Если хочется едко (или как говорят — токсично) пошутить в чей-либо адрес. Либо сделать едкое замечание. Процесс совместной работы тоже труд. А как известно труд нужно уважать. Поэтому едкости и токсичности здесь не место.

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

Другие важные рекомендации

Асинхронность в работе

Простой пример из рабочих будней:

  • У тебя есть задача: [feature] Bankcard Template — примерное время решения 4-6 часов
  • Рядом другая задача: [question] Deploy to GKE — примерное время на поиск ответа до 2 часов

Ответить на вопрос быстрее и он позволит запустить в работу ещё одну задачу и займёт это на порядок меньше времени чем разработка шаблона для банковских карт.

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

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

Если испытываешь сложности, зови на помощь

Очень часто, попросить помощи в какой-то части работы намного проще, а самое главное быстрее, чем пытаться решить её самостоятельно. Многие новички так делают и это плохо. Намного эффективней попросить помощи и решить проблему быстрее. Ты сэкономишь своё время и как ни странно чужое. Profit!

Не бойся задавать вопросы

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

Поэтому лучше спросить, а если не уверен переспросить.

Если выполняешь задачу совместно с коллегой

Кооперируйтесь, созванивайтесь, обсуждайте проблемы и задачи. Но самое главное — документируйте итоги своих взаимодействий. Иначе говоря, если вы созвонились и договорились о чём-то, зафиксируйте итог созвона в issue.

Как правило хватает одного списка, описанного тезисно.

Все обсуждения по работе ведутся строго в рабочих инструментах

Github, Discord, Рабочие каналы Telegram. Лучше всего, когда бо́льшая часть информации оседает в Issue.

Отписывайся в дейлик после его создания

Дейлик, он же Daily Standup Meeting — это настроенный репозиторий, в котором каждый день утром создаётся issue. А вечером этот issue закрывается.

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

Дейлик нужен для всеобщего понимания того, кто чем занят сегодня и над какой задачей трудится. А также над отслеживанием сложностей у коллег.

Шаблон того, как надо писать в теле issue дейлика.

Находи время развиваться

Работа разработчика, инженера, дизайнера, менеджера и любого другого человека в IT сфере, не может обходиться без постоянного самообучения. Иначе есть риск «остаться в прошлом». Поэтому находи время развиваться.

Читай тематические каналы и ресурсы. Конечно же у тебя должен быть аккаунт на Хабре :)

Находи время на перерывы

Удалённая работа — это сидение перед экраном часами. Это не очень хорошо для здоровья. Поэтому находи время на перерывы.