Нельзя просто взять и договориться, или Истории о сложных людях
Привет! Меня зовут Эллина Азадова, я одинадцать лет в IT, более семи из них работаю тестировщиком. Координатор сообщества QA talk Kherson, лектор в QA School в Херсоне и Софии.
Эта статья посвящена работе с людьми. Все люди разные, каждый со своим настроением, желаниями, целями и характером. Собрать идеальную команду для конкретного проекта — большое счастье и большая редкость. Обычно что-то обязательно пойдет не так.
Хочу поделиться несколькими реальными историями из своей практики, сюжет которых закрутился именно вокруг человеческого фактора. Не факт, что в каждом случае мы приняли однозначно правильное решение, но я расскажу, как было на самом деле. В сложившихся условиях мы поступили именно так и вынесли из этого свои уроки.
Тотальный контроль
Я попадаю в новый проект как QA Lead. Стандартная команда: ВА, QA, команда разработки с девлидом. Все бы ничего, но, как оказалось, практически каждое действие в проекте обсуждалось и выполнялось только с одобрения девлида, которого для удобства мы назовем, допустим, Петровичем. Он же выполнял роль проджект-менеджера, напрямую общаясь с клиентом.
Еще один момент, который усложнял жизнь: Петрович работал из Америки, так что у нас была большая разница во времени. Иногда команда просто ждала важных решений, требующих обсуждения, и выстраивала свои запросы в приоритетную очередь.
Надо отдать должное девлиду: он действительно обладал хорошим техническим бэкграундом и продолжал удерживать ключевую роль в проекте. Я руководила тестированием, и многие технические детали мне нужно было согласовывать именно с ним. Но, к счастью, у меня дополнительно был прямой выход на клиента и я могла увидеть более широкую картину и услышать требования клиента к тестированию из первых рук.
После новогодних праздников Петрович решил взять отпуск на... месяц. Клиент был против, отпускать ключевого специалиста так надолго он совсем не хотел. Мы переживали, как быть дальше, кто будет принимать решения, ведь были явные риски, если надолго оставлять команду работать самостоятельно. С другой стороны, все прекрасно понимали, что нужно попытаться разорвать сложившуюся связь. Это могло вывести команду на более независимый уровень и обезопасить нас от эффекта грузовика. Отпуск Петровича оказался прекрасной возможностью попробовать, тем более что убедить девлида сократить сроки не удалось (то ли это было невозможно, то ли другие участники плохо пытались).
Наконец девлид ушел в отпуск. И как ни странно, ничего не развалилось. У меня было достаточно знаний о системе, которые я еще раньше получила в командировке при непосредственном общении с клиентом. Наш ВА тоже имел к нему доступ и постоянно с ним созванивался. А в команде разработки проявился новый лидер, который с нашей помощью смог взять на себя ответственность и продолжить работать над продуктом.
Было непросто, но мы справились. Прошел месяц, и мы поняли, что вполне можем работать самостоятельно. В тот день, когда наш Петрович должен был выйти из отпуска, нам сообщили, что в наш проект он не вернется. Без деталей. Кто на самом деле выступил инициатором и почему все произошло так быстро, нам осталось только догадываться.
Тем временем команда еще теснее сработалась. Участники всегда приходили на помощь друг другу, если кто-то обнаруживал пробелы в знаниях или сомневался в решении. К слову, с ребятами до сих пор общаемся, даже помимо работы.
Опыт, который мы вынесли:
- Не нужно создавать ботлнеков. Делитесь тем, что знаете, не старайтесь быть уникальным носителем знаний.
- Людей надо обучать, чтобы знания и навыки оставались в команде, даже если вы возьмете отпуск или выйдете из проекта.
- Тесная работа в команде сплачивает людей, делает коллектив по-настоящему дружным.
- Пусть как можно больше людей из вашей команды общается с клиентом. Обсуждение без посредников позволит максимально глубоко понять его нужды.
Негативный настрой
Этот случай произошел в другом проекте, где у нас было несколько небольших команд, каждая из которых занималась отдельным компонентом единой системы. Я была QA-лидом одной из этих команд.
Естественно, нашей конечной целью было собрать проект воедино и обеспечить работоспособность компонентов в целом, а не только по отдельности. Однако, к сожалению, не все коллеги способны заглянуть дальше задачи, поставленной непосредственно перед ними. В больших системах такие риски требуют особого внимания: кажется, все работают, как нужно, каждая часть соответствует заявленным требованиям, но система почему-то не взлетает.
Один из наших компонентов на тот момент считался менее важным для общей работы, из-за чего менеджер этого подпроекта — назовем его Юрой — постоянно был в плохом настроении. Любой чат с ним сводился к негативной оценке других команд или конкретных людей, что мешало сотрудничеству и настраивало как раз против самого Юры. Помогать ему не особенно хотелось даже там, где это было возможно.
Потом менеджеров и лидов проекта собрали на тимбилдинг (мы все были из разных городов Украины, и не только). Познакомившись лично, мы значительно изменили мнение друг о друге. Юра понял, что другие команды действительно готовы помочь интегрировать компонент, за который он отвечал. Никто не ставит ему палки в колеса — наоборот, подсказывают детали и вместе ищут пути решения возникших вопросов. Разговаривая в кафе об управлении эмоциями в команде, мы поняли, что у нас есть общие интересы и общая боль.
После этой командировки контакты наладились, работа пошла более продуктивно, негатива практически не осталось. Юра стал чаще улыбаться, больше рассказывать о своем компоненте, моя команда со своей стороны помогала выстроить весь сценарий пользователя и исследовала баги. В итоге даже функционал заработал лучше, а клиент выглядел еще более довольным, чем раньше.
Опыт, который мы вынесли:
- Эмоции (как позитивные, так и негативные) любого члена команды, а тем более руководителя, сильно влияют на всю команду.
- Люди рано или поздно узнают о том, что вы о них говорите или говорили.
- В большинстве случаев нужно просто лучше узнать человека и его мотивы. Возможно, у вас общие проблемы и вместе вы скорее найдете решение. Или просто поможете друг другу.
- Нужно поддерживать друг друга. Многие не любят жалость, а вот поддержка единомышленников всегда придает сил.
Проблема онлайн-коммуникации
Наверняка в большинстве проектов есть люди, которые пропускают важные сообщения в рабочем чате или по почте, а потом приходят с вопросами, которые давно решены. В один из моих проектов такой человек тоже попал, назовем его Васей. Люди технического склада ума, и правда, часто глубоко погружаются в код и стараются поменьше отвлекаться на внешние раздражители. Это нормально, пока не мешает им самим или другим членам команды.
Представьте обычный командный стендап. Мы говорим о статусе задач и обсуждаем текущие проблемы — стандартная ситуация. Очередь доходит до Васи, и тот, услышав свое имя, начинает рассказывать, как все плохо, поскольку в приложении есть блокер. Который мы только что подробно обсудили.
Бизнес-аналитик дружелюбно откликается и говорит, что обязательно поможет. Он действительно находит всю необходимую информацию и отправляет Васе письмом, поставив в копию всю команду, на случай если им решение тоже понадобится. У меня отлегло от сердца: мой тестировщик разблокирован и может продолжать работу.
Через несколько дней на очередном стендапе Вася снова сообщает, что не может работать над основной задачей. Начинаем уточнять, почему не сработало решение, которое прислал аналитик. Оказывается, письмо осталось незамеченным.
Да, иногда в день прилетает много писем. Сейчас на мой основной адрес приходит по 500 писем в день, не все они адресованы лично мне, но сортировать их необходимо.
Опыт, который мы вынесли:
- Людям важен фидбэк о работе. Некоторые вещи кажутся очевидными только со стороны. Фидбэк — это отдельный разговор, но позволю себе добавить несколько рекомендаций. Продумайте заранее, о чем вы будете говорить и как донесете информацию. Люди по-разному реагируют на критику, но в большинстве случаев нужно готовиться к защитной реакции.
- Негативный фидбэк нужно сообщать лично. Никогда не выносите его на общие созвоны, уважайте своих коллег.
- Ругать или хвалить нужно только на основании фактов. Любой вывод нужно обосновать четкими примерами того, что сделал или не сделал человек. Старайтесь избегать оценочных суждений.
- Иногда приходится доказывать коллегам, как важно обращать внимание на то, чем живет команда и разработка в принципе.
- Фильтрация почты — вещь полезная. Не все сообщения одинаково важны: в почтовый ящик приходят потоки оповещений Jira или просто письма FYI, которые необязательно читать немедленно. Пусть они собираются в личке.
- Если вы хотите, чтобы на ваше письмо обязательно обратили внимание, не нужно стесняться сказать об этом на общем созвоне, в личном звонке или написать в мессенджере, которым обычно пользуется ваш коллега. Найдите точку коммуникации, на которую реагирует тот, кто вам сейчас нужен.
И напоследок
Со своей точки зрения тяжело судить, почему человек поступил так или иначе, ведь мы не знаем всей подноготной. Всегда помните о человеческом отношении: ко всем можно найти подход, если хорошенько его поискать.
