Разработчик о командной работе в it⁠⁠

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

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

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

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

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

Писать инструкции. Если с одним вопросом сталкиваются многие сотрудники, эффективнее будет закрепить порядок его решения в текстовом виде. Когда лень писать инструкцию самому, хорошим решением будет заставить написать инструкцию того, кто обратился с вопросом.

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

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

Буду рад, если эти приемы пригодятся и в вашей работе, удачных проектов и команд!