Наверняка каждый из нас хоть раз сталкивался с тем, что договаривался с человеком о каком-то деле, а человек затягивал, либо и вовсе забывал, что давал обещание. Первым же делом хочется подумать какой же безответственный человек. И вроде когда ты лид или менеджер, то все понятно, вызываешь на "ковер", увольняешь при повторах. Но можно ли как-то этого избежать? И что делать если вы из разных отделов, но задача вам все равно очень нужна?
Я работаю автоматизатором тестирования вот уже больше четырех лет и мне по специфике моей работы нужно регулярно общаться с людьми вне моей команды и просить выполнять задачи. В этой статье я постараюсь поделиться способами, которые помогают мне выстроить коммуникацию более эффективно и получить выполненную задачу в срок.
Сделайте задачу понятной для исполнителя
Для того чтобы написать хорошее описание к задаче, попробуйте представить себя на месте человека, которого просите ее сделать. С чего вы начнете решение этой проблемы? Наверняка вы можете хотя бы в общих чертах можете представить работу всех ваших коллег. Если вы пишете разработчику, то ему нужно понять место в коде, в котором ошибка. То есть это логи, описание поведения, версия приложения. Если пишете девопсу, то ему нужно понять, где произошла проблема, какого она рода сетевая или конфигурационная. В этом помогут логи, ссылки на сборки, описание условий - все что поможет найти причину проблемы. "У меня не работает" - не поможет точно.
Если можете упростить работу, то упрощайте. Прикладывайте полные ссылки, а не приписку "у нас на стенде под номером 2", человек поймет и найдет, но это время. Вспомните какие уточняющие вопросы вам задавали ранее, не ждите их, ответьте на возможные вопросы сразу. Хуже всего для выполнения задачи - неполнота. Человек садится, открывается от основных дел, тут ему приходится вас спрашивать, вы отвечаете ему спустя час, потом еще вопрос и еще - крайне неэффективно. И если у человека будут еще 3-4 задачи той же важности, что и от вас, но более понятные, то он скорее всего переключится на их выполнение, а к вашей задаче вернется, ну... когда-нибудь.
При этом не нужно писать как вы видите решение своей проблемы, вы не специалист в этой области и не можете знать решит это на самом деле вашу проблему или нет. Могут быть детали о которых вы не знаете и ваша проблема либо решится частично, либо вовсе не решится, а человек сделает что-то абсолютно бесполезное. Обозначьте какую пользу для вас должна принести задача.
К примеру у нас была задача, в которой нужно было сделать страницу с благодарностью об оплате. Если бы команда не спросила "зачем", то на прод уехала бы бесполезная, а может даже и вредная задача, потому что она не решала проблемы заказчика - привязка google analytics к событию об оплате. Так как, во-первых, пользователь после оплаты может не перейти обратно в магазин, а закрыть окно сразу после оплаты. Во-вторых, подтверждение об оплате мы получаем от сервиса оплаты с задержкой, в некоторых случаях с большой, а так долго не показывать пользователю следующую страницу мы не можем, он ее закроет.
Узнайте в каком режиме работает человек/команда/отдел
Нельзя просто так ворваться в чужие процессы, у нас у всех есть наши прямые обязанности и ежедневные дела, ради которых нас наняли: командные задачи, инициативы отдела и так далее. Вы должны четко понимать по какому процессу работает человек. Уточните у него это, спросите, как вам лучше всего организовать совместную работу. Возможно вам потребуются регулярные синки для того, чтобы проверять прогресс. Решите, будет ли это общий митинг двух команд, либо вы будете приходить на их дейли, либо исполнитель от их команды будет посещать ваши.
Если задача небольшая, то достаточно понять по каким процессам она берется в команду или на конкретного человека. Если это SCRUM, то есть планирование на котором задачи берутся в спринт. Обозначьте приоритет вашей задачи, дедлайны. Jira и другие средства для совместной работы позволяют поставить отслеживание и вам будут сообщать обо всех изменениях касательно этой задачи. Это будет вам полезно для того, чтобы подсвечивать прогресс перед вашей командой. Если вы обращаетесь к сервисной команде, то у них обычно есть дежурный и SLA, сроки, в которые они должны обработать ваш запрос. Обработать запрос не равно сделать задачу. Пункт 1 поможет вам увеличить шансы того, что за время дежурства задачу успеют сделать. Если нет, то на следующий день эта задача может перейти следующему дежурному.
Если это небольшая просьба, которую вы написали в личных сообщениях и человек вам ответил "Гляну после обеда", поставьте напоминание себе через 2 часа и проверьте не забыл ли человек. Все мы люди, а после обеда тем более все может забыться. В slack есть удобная функция "remind me about this", с помощью которой на любое сообщение можно повесить напоминание.
Явно подсветите, что вы ждёте от человека выполнение этой задачи
В конце встречи по обсуждению деталей работы повторите что вы ждете от человека. Лучше всего, конечно, когда исполняющая сторона это повторяет, но ситуации бывают разные. Так вы еще раз закрепите договоренность, человек успеет среагировать, если что-то не так понял. И обязательно запишите формулировку DoD в задачу. Если этого нет, то задача будет считаться выполненной в тот момент, когда исполнитель решит, что она выполнена. И будет прав. В личных сообщениях после "хорошо, посмотрю" напишите "спасибо, буду ждать" и обозначьте сроки вашего ожидания.
Напоминайте
Да, вы уже договорились, но напомню, задача нужна Вам! И лучше напомнить сейчас, чем потом сетовать на необязательность какого-то человека из другого отдела из-за которого вы теперь завалили OKR.
Говорите "спасибо"
Даже если человек вам не смог помочь, поблагодарите за то, что он потратил на вас время. Возможно это также продвинуло вас в сторону решения вашей задачи, вы лучше ее поняли, поняли к кому теперь можно обратиться. Наверняка это не последний раз, когда вы придете к этому человеку с задачей и лучше, чтобы у него остались хорошие воспоминания от помощи вам.
И конечно же статья была бы не полной, если бы мы не взглянули на проблему с другой стороны.
Вам пишут сообщения вроде: "Привет, мне твой фикс не помог", "У меня опять все сломалось". Или скидывают кучу несвязных деталей и вы вообще ничего понять не можете. Это не повод откладывать задачу на потом.
Ответьте человеку
Даже если у вас аврал и нет ни минуты свободной, все равно ответьте и сообщите о том по каким процессам задачи попадают к вам. Добавьте его на встречу, на которой вы и ваша команда разбираете задачи и добавляете их в бэклог, либо отправьте в папку с бэклогом, либо поймите, что это задача не к вам и отправьте к тем, кто сможет с этим помочь.
Посмотрите задачу сразу и задайте вопросы
Пробегитесь по задаче. Если постановка задачи не помогла вам понять первый шаг к ее выполнению, то это плохо поставленная задача. Не стоит бояться, что кто-то вдруг усомнится в вашей компетенции. Не знать всего - нормально, вы не погружены в контекст и тем более не можете знать всех деталей. Задача должна быть понятна вам и через несколько недель, когда для нее найдется время. И об этом стоит позаботиться до того, как найдется время на ее выполнение.
Помогите описать задачу понятно для вас
Человек может не знать, что он чего-то не знает. Тем более если он далек от вашей области. Вы можете погрузить человека немного в специфику вашей работы, это поможет ему в следующий раз описать задачу понятнее для вас.
Оперируйте понятными терминами
Если к вам с проблемой пришел менеджер, то, возможно, он очень давно не заглядывал в консоль, а еще скорее всего у него не линукс. И хорошо, если вы вместо "Пришли мне свой публичный ключ", напишите команду как его сгенерировать. Да, человек в итоге справится, но ответит он только спустя минут 20. А время - деньги.
Надеюсь эта статья поможет вам начать больше доверять коллегам и меньше пугаться задач, которые требуют взаимодействия между командами. Эффективной вам работы!
