Асинхронный режим - это когда работа одного разработчика не зависит от доступности его коллег и наоборот. Если вы хотите работать автономно, то вы должны стремиться к асинхронной работе. В условиях асинхронности легче и свою нагрузку планировать, и на Бали улететь работать с пляжа, и никто не ждет тебя, говоря на дэйлике, что заблокирован.
Так ли легко прийти к такому режиму? Технически нет ничего сложного. В статье я дам несколько практик и советов. Однако одному нельзя построить вокруг себя атмосферу асинхронности в то время, когда остальных хлебом не корми, а дай только созвониться “на пять минут по маленькому вопросу”. Придется учить асинхронности и коллег тоже, хотят они этого или нет. Ниже я поделюсь парой рекомендаций и аргументами, с помощью которых стоит попробовать убедить коллег в их пользе.
Работа с Jira
1. Храните информацию в Jira
Всю информацию по задачам пишем в Jira: критерии приемки, пояснения, линковка с другими задачами. Помимо бизнес-описания, я веду собственные заметки по задаче в любом редактируемом поле, например, комментарии или дополнительные поля. Обычно я записываю полезную информацию по задаче, примененные SQL команды, скриншоты выходных таблиц, если требуются. Когда я вернусь к задаче, мне не нужно вспоминать все те действия, что я проделывал - все уже записано.
Привычка вести заметки поможет, когда вы вернетесь к задаче спустя время или когда нужно посоветоваться с коллегой. При подготовке вопроса или созвона у вас уже есть вся справочная информация, и коллега сможет тоже с ней ознакомиться.
Как убедить коллег
Покажите на примере пользу записей - напишите заметки по задаче в джиру и скажите коллегам: “Смотрите что придумал! Так я не забуду спустя время, что делал для решения задачи”. Если в вашей команде только продакт-менеджер пишет задачи, а другим запрещает, то попробуйте так убедить его так: “А что будет, если вы в отпуске или заболели? Зачем мне дергать вас, хотя я могу сам создать багрепорт в джире и описать шаги для воспроизведения? Так ведь вам будет спокойнее, что и баг или задача будет зафиксирована, и вы сможете спокойно отдохнуть. А если мой текст недостаточно точный, то дополните уже потом сами”.
Во время презентации подхода рассказывайте о той пользе, которую получит ваш собеседник, а не вы, и тогда будет больше шансов его убедить.
2. Задавайте вопросы в Jira
Письменное общение по проекту - корень асинхронной работы. Без этого не достичь асинхронности никогда. Суметь задавать вопрос - это все равно что пройти больше половины пути навстречу решению. Если кажется, что голосом рассказать легче что-то, то насильно себя остановите и попробуйте задать вопрос: “почему на звонке будет легче?”. Уметь передать мысль лакончино и структурировано - навык, который стоит развивать с самого начала карьеры. Хочется созвониться с коллегой и рассказать ему идеи тогда, когда в тексте передать информацию лакончино никак не получается. Учитесь краткости.
Беда в том, что подобный звонок - неуважение ко времени собеседника. Вы уверены, что вам легче обсуждать что-то голосом, но уверены ли вы в том, что коллеге тоже легче воспринимать вашу идею “здесь и сейчас” на звонке? Нравится ли вам самим, когда отвлекают от задачи “срочными вопросами”?
Как убедить коллег
Пишите вопросы в мессенджеры и Jira. Прикладывайте скриншоты, если текста недостаточно. Пишите, даже если не хочется писать. Пишите, даже если “легче голосом объяснить”. Пишите, даже когда коллега сидит за соседним столом в офисе. Чем больше будете писать, тем быстрее научитесь лаконично формулировать мысли.
Когда коллега спрашивает о свободном времени на колл, то спросите в ответ, по какому вопросу нужен созвон. Скажите, что прямо сейчас нет возможности, но вы обязательно отпишетесь в Jira или в мессенджере. На ближайших ретро отмечайте, что общение в комментариях в Jira помогло вспомнить о критериях приемки, которые забыли. Пусть коллеги увидят, как написанная информация помогает вам и им.
3. Ставьте задачи в Jira
Ставьте задачи другим
Продакт-менеджер - не единственный, кто имеет право ставить задачи. Любой разработчик - от джуна до лида - тоже должны уметь делать это. Наткнулся на баг? Зарегистрируй баг-репорт и напиши шаги для воспроизведения. Нужна помощь девопса? Поставь задачу, напиши там что требуется. Знаешь, как разбить крупную фичу на несколько задач? Создавай подзадачи со собственными критериями приемки. Умение объяснить письменно то, что хочешь от других - важный навык, который пригодится всем. Емейлы, письменное общение, документация - все это требует умения лаконично выразить мысль, и постановка задач другим - отличный тренинг.
Когда задача поставлена в Jira, вам не нужно ждать коллегу, когда он начнет рабочий день. Не нужно ждать и свободный таймслот продакта или тимлида, чтобы обсудить проблему. Если уверены, что поведение системы неправильное - опишите в задаче ожидаемое. Если не уверены, то пишите черновик задачи в личку тимлиду или продакту и попросите совета, стоит ли регистрировать проблему в бэклоге. Таким образом, вы не только научитесь эффективно передавать информацию, но и сэкономите время себе и коллегам. Помимо прочего, вы покажете себя проактивным членом команды, что точно отметят на пересмотре зарплаты.
Просите ставить задачи вам
Представим ситуацию, что вы - бэкендер, а коллега - фронтендер. Вдруг он пишет в слак о том, что не работает какой-то эндпоинт или ответ бэкенда не такой, каким он его ждет. Напишите коллеге, что ждать ответа не стоило, можно просто создать багрепорт и сразу назначить на вас. Создавать багрепорты несложно, я описан необходимое тут. Создав задачу для вас, фронтендер может смело ставить свою задачу в блок и приступать к другой задаче.
Таким образом, у вас будет список задач, которые нужно сделать. Никто не ждет вас, чтобы созвониться и показать. Показать можно и в скриншотах, и в записи экрана, и звонок для этого не нужен. Коллеге польза от задачи в том, что он создает баг-репорт в удобное для себя время и не ждет свободный таймслот у вас, у проектного менеджера или тимлида. Даже если фронтендер что-то делает неправильно, то вы, когда возьмете его задачу в работу, в комментарии напишите, в чем его ошибка была. Все довольны, вы с фронтендером работаете асинхронно.
Как убедить коллег
Если нет прав создавать задачи в Jira, то с тимлидом требуйте у продакт-менеджера такое право. Мотивируйте тем, что хотите регистрировать баг-репорты и подзадачи фич. Пробуйте сами создавать задачи для других и скидывайте тимлиду и/или продакту на аппрув - пусть просмотрят ваш текст и подтвердят задачу как есть или помогут подкорректировать.
4. Ведите документацию
Схема взаимодействия модулей в системе, список используемых библиотек, какие-то глобальные фичи приложения - все это стоит перенести из головы в документацию. Писать можно в Confluence или в markdown-файлах в репозитории. Чем меньше рассказываете устно коллеге о проекте, тем лучше. Пусть читает документацию и задает уточняющие вопросы. Обязательно в комментариях, чтобы было легче дополнить документацию.
Когда описаны модули, спускайтесь к фичам и описывайте уже их. Например, вы пишете импорт пользователей на бэке. По завершению работы дайте всю информацию в Jira: какие события возникают в процессе работы, структура входящего запроса эндпоинта, что-то полезное коллегам. Если добавите пример запроса в Postman-коллекцию, то тиммейты скажут вам спасибо. Если узнали какой-то хак, с помощью которого можно протестировать задачу - тоже добавьте, пусть все о нем знают.
Чем больше информации сразу вынесите в Jira, тем меньше тиммейты будут от вас зависеть, а значит и отвлекать будут меньше. Зависеть коллеги должны от информации, а не от людей.
Как убедить коллег
Начинайте с себя - ведите записи по модулям, которых коснулась ваша рука. Изучили модуль - опишите его назначение и внутреннее устройство. Обсудили с коллегой архитектуру - запишите выжимку в вики или в Jira. Покажите коллегам, как документация вам помогает.
Заключение
Полностью асинхронный режим работы построить не получится, но стремиться к этому нужно. Митинги для синхронизации статусов нужны, а нетривиальную проблему объяснить действительно проще на созвоне, особенно когда нужен совет нескольких экспертов. Когда возникнет необходимость что-то спросить у коллеги или рассказать ему, то в первую очередь подумайте о письменном формате, а не устном. Уточняющие вопросы будут, но пусть лучше собеседник сначала ознакомится с информацией, может что-то сам поищет дополнительно, а уже потом поспрашивает вас. Если, конечно, вопросы еще останутся.
В стремлении установить асинхронный режим работы главное - не забыть про принципы. Стойте на своем до конца. Если вы сами отступитесь от них, то и коллеги не будут серьезно относиться к ним.
Обдумайте формат текущих встреч и порассуждайте, а можно ли заменить их емейлами и комментариями в Jira? Позовите тимлида, заведите с ним дискуссию. Пусть он тоже задумается над этой идеей. Вдвоем менять формат работы будет проще. Здесь точно можно сказать, что один в поле - не воин.