Принимайте участие в зарплатном опросе! Уже собрано почти 8 000 анкет.

Нельзя просто взять и договориться, или Истории о сложных людях

Привет! Меня зовут Эллина Азадова, я одинадцать лет в IT, более семи из них работаю тестировщиком. Координатор сообщества QA talk Kherson, лектор в QA School в Херсоне и Софии.

Эта статья посвящена работе с людьми. Все люди разные, каждый со своим настроением, желаниями, целями и характером. Собрать идеальную команду для конкретного проекта — большое счастье и большая редкость. Обычно что-то обязательно пойдет не так.

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

Тотальный контроль

Я попадаю в новый проект как QA Lead. Стандартная команда: ВА, QA, команда разработки с девлидом. Все бы ничего, но, как оказалось, практически каждое действие в проекте обсуждалось и выполнялось только с одобрения девлида, которого для удобства мы назовем, допустим, Петровичем. Он же выполнял роль проджект-менеджера, напрямую общаясь с клиентом.

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

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

После новогодних праздников Петрович решил взять отпуск на... месяц. Клиент был против, отпускать ключевого специалиста так надолго он совсем не хотел. Мы переживали, как быть дальше, кто будет принимать решения, ведь были явные риски, если надолго оставлять команду работать самостоятельно. С другой стороны, все прекрасно понимали, что нужно попытаться разорвать сложившуюся связь. Это могло вывести команду на более независимый уровень и обезопасить нас от эффекта грузовика. Отпуск Петровича оказался прекрасной возможностью попробовать, тем более что убедить девлида сократить сроки не удалось (то ли это было невозможно, то ли другие участники плохо пытались).

Наконец девлид ушел в отпуск. И как ни странно, ничего не развалилось. У меня было достаточно знаний о системе, которые я еще раньше получила в командировке при непосредственном общении с клиентом. Наш ВА тоже имел к нему доступ и постоянно с ним созванивался. А в команде разработки проявился новый лидер, который с нашей помощью смог взять на себя ответственность и продолжить работать над продуктом.

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

Тем временем команда еще теснее сработалась. Участники всегда приходили на помощь друг другу, если кто-то обнаруживал пробелы в знаниях или сомневался в решении. К слову, с ребятами до сих пор общаемся, даже помимо работы.

Опыт, который мы вынесли:

  • Не нужно создавать ботлнеков. Делитесь тем, что знаете, не старайтесь быть уникальным носителем знаний.
  • Людей надо обучать, чтобы знания и навыки оставались в команде, даже если вы возьмете отпуск или выйдете из проекта.
  • Тесная работа в команде сплачивает людей, делает коллектив по-настоящему дружным.
  • Пусть как можно больше людей из вашей команды общается с клиентом. Обсуждение без посредников позволит максимально глубоко понять его нужды.

Негативный настрой

Этот случай произошел в другом проекте, где у нас было несколько небольших команд, каждая из которых занималась отдельным компонентом единой системы. Я была QA-лидом одной из этих команд.

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

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

Потом менеджеров и лидов проекта собрали на тимбилдинг (мы все были из разных городов Украины, и не только). Познакомившись лично, мы значительно изменили мнение друг о друге. Юра понял, что другие команды действительно готовы помочь интегрировать компонент, за который он отвечал. Никто не ставит ему палки в колеса — наоборот, подсказывают детали и вместе ищут пути решения возникших вопросов. Разговаривая в кафе об управлении эмоциями в команде, мы поняли, что у нас есть общие интересы и общая боль.

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

Опыт, который мы вынесли:

  • Эмоции (как позитивные, так и негативные) любого члена команды, а тем более руководителя, сильно влияют на всю команду.
  • Люди рано или поздно узнают о том, что вы о них говорите или говорили.
  • В большинстве случаев нужно просто лучше узнать человека и его мотивы. Возможно, у вас общие проблемы и вместе вы скорее найдете решение. Или просто поможете друг другу.
  • Нужно поддерживать друг друга. Многие не любят жалость, а вот поддержка единомышленников всегда придает сил.

Проблема онлайн-коммуникации

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

Представьте обычный командный стендап. Мы говорим о статусе задач и обсуждаем текущие проблемы — стандартная ситуация. Очередь доходит до Васи, и тот, услышав свое имя, начинает рассказывать, как все плохо, поскольку в приложении есть блокер. Который мы только что подробно обсудили.

Бизнес-аналитик дружелюбно откликается и говорит, что обязательно поможет. Он действительно находит всю необходимую информацию и отправляет Васе письмом, поставив в копию всю команду, на случай если им решение тоже понадобится. У меня отлегло от сердца: мой тестировщик разблокирован и может продолжать работу.

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

Да, иногда в день прилетает много писем. Сейчас на мой основной адрес приходит по 500 писем в день, не все они адресованы лично мне, но сортировать их необходимо.

Опыт, который мы вынесли:

  • Людям важен фидбэк о работе. Некоторые вещи кажутся очевидными только со стороны. Фидбэк — это отдельный разговор, но позволю себе добавить несколько рекомендаций. Продумайте заранее, о чем вы будете говорить и как донесете информацию. Люди по-разному реагируют на критику, но в большинстве случаев нужно готовиться к защитной реакции.
  • Негативный фидбэк нужно сообщать лично. Никогда не выносите его на общие созвоны, уважайте своих коллег.
  • Ругать или хвалить нужно только на основании фактов. Любой вывод нужно обосновать четкими примерами того, что сделал или не сделал человек. Старайтесь избегать оценочных суждений.
  • Иногда приходится доказывать коллегам, как важно обращать внимание на то, чем живет команда и разработка в принципе.
  • Фильтрация почты — вещь полезная. Не все сообщения одинаково важны: в почтовый ящик приходят потоки оповещений Jira или просто письма FYI, которые необязательно читать немедленно. Пусть они собираются в личке.
  • Если вы хотите, чтобы на ваше письмо обязательно обратили внимание, не нужно стесняться сказать об этом на общем созвоне, в личном звонке или написать в мессенджере, которым обычно пользуется ваш коллега. Найдите точку коммуникации, на которую реагирует тот, кто вам сейчас нужен.

И напоследок

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

LinkedIn

59 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Вы же там, в DataArt, работаете по Scrum. Но в статье у вас им даже не пахнет. Что ж вы на собеседованиях такие правильные и умные, а на деле — воете и описываете полный хаос на проекте?! Дайте авторше печеньку за труды, она ее заслужила🤣

Есть вопросы?
1) случай с «петровичем» — лиды напрямую общаются с заказчиком минуя BA и PM?
2) случай с Юрой — QA собирает проект из отдельных компонент и это считается нормальным?
3)QA лид отдельного небольшого проекта получает 500 в день и все письма по этому проекту?

Пусть как можно больше людей из вашей команды общается с клиентом.

скажу честно это жопа простите ))

остальное ок и без меня прекрасно комментируют чисто как иллюстративный материал ))

Впевнений що це не була ініціатива Петровича обмежувати з вами спілкуватись, просто клієнти не бажали з вами спілкуватись, бо так для них простіше. А коли він пішов, то іншого варіанту вже не було:)

Интересно, почему первый персонаж от автора идентифицируется отчеством, а два других — именем?

Видимо первый персонаж был в возрасте, а два других — молодые :) Другой вопрос, почему все персонажи — мужчины? Попахивает гендерной дискриминацией :)

Петрович и Юра. Вертикаль и горизонталь. Вертикаль съели и выбрали из своих. Горизонталь, претендентов не было — просто сделали вливание. Вертикаль мешала своим графиком и авторитарностью. Причём тут распространение знаний, не пойму. Может бы позже съели, насытившись знаниями. Как на меня тут просто борьба за доступ к телу, знание вторично, влияние первично.

Петрович це зайва ланка в сучасних комунікаціях. Коли я бачу проекти з «лідами», які зовсім не ліди, а просто зайвий «хоп» (інтерхвейс) між тобою та замовником, відразу стає зрозумілий рівень розвитку компанії в Agile :) А раз немає Agile, то немає і багато чого іншого, бо це одна з сучасних технологій роботи, десь як Devops, Automation testing чи Clouds.

вообще-то в агиле он называется продукт овнер

Статтю читайте, щоб зрозуміти, ким був Петрович (підказка з тексту:

команда разработки с девлидом

)

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

1) нет такого понятия как негативный респонс. Всмысле негативный это если сказать «иди на х**» но это не респонс а оскорбление. Если же взрослый чел обижается на то что ему сказали что он допустил ошибку, то его просто нужно увольнять (если только это не больница а вы не психиатр)
2) Хотите профита и простоты — все должно быть публично. Недомолвки и тайны это главная причина конфликтов и домыслов.
3) Ведите себя с другими так как хотите что бы вели себя с вами.

1) В оригіналі було «негаітивний фідбек», що десь поруч з «проваленим тестом» — сам тест виконався та скінчився, але він червоненький.
2) Ніхто не хоче простоти, бо в сучасному світі це все також десь поруч з крадіжкою. Напевно, малась на увазі «прозорість»? Згодний, все має обговорюватися публічно, окрім негативних фідбеків.
3) Це слабкий патерн, щоб пояснити кому-небудь, як треба себе вести.

Эллина, спасибо за статью. Я согласен что это (коммуникации и отношения) очень важная тема для тех кто работает в командах, хотя лично я из самих историй я не извлек ничего нового, так как сталкивался с таким, и не только с таким :)))
Но я пока еще тоже верю что к каждому можно найти подход и наладить коммуникцию :)

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

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

Я не про этот конкретный случай а взагалi

Я думаю Петрович просто свой не использованный отпуск гулял

Может и так
А может и ...

... для собеседований и получения оффера?

Может и так
Петрович умный мужик

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

не будь Петровичем! не уходи в отпуск! не подпускай ушлых КуА и БА к клиенту! реж все коммуникации и у тебя все получится. Петрович, держись там!

боюсь петрович там уже в лучшем мире только в хорошем смысле слова и вспоминает «команду с Родины» как некий далёкий как индия только ближе но во времени 146% прошедшем кошмар )) и правильно делает

А давайте обсудим клиента. Процесс, который выстроил сам клиент оказался нерабочим, т.к. при наличии руководства на этапе решений оказалось, что руководство больше не нужно, и та модель, которая работала до момент отпуска Лида, далее перестала работать. Вы когда заказываете пончик, вы хотите конкретный пончик или абстрактный? Вы профессионал в пончиках. вы в них разбираетесь. Клиент обязан быть профессионалом в своем проекте, и если он не разбирается в деталях, значит ошибка со стороны клиента. Таким образом этому Лиду надо памятник поставить, он же вытерпел все пожелания клиента и все хотелки девов и остальных в команде. На момент перехода на ручное управление, мы понимаем что клиент теряет собственное время чтобы решить все сам, ведь это оказывается дешевле сейчас. А как насчет потом? Когда команда станет не 5 человек а 100?

У мене на проекті точно така ситуація, але я працюю onsite у замовника, тобто, петровичів. Так, повністю згодний: це прольот замовника, саме замовник несе повну відповідальність за таку невдалу модель керування ресурсами, і отримує такі результати. Але хочу сказати, що Петровичу ніфіга не респект і не пам’ятник, тому що він грав в цю гру до останнього не розуміючи, що ця гра слабоефективна, неправильна, і правила гри мають бути змінені. Саме тому він (пам’ятник) і отримав такий результат, як загублене робоче місце.

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

У Петровича всё хорошо, я уверен

«зачем он нужен на проекте?»

Продовжувати керувати ресурсами, і отримувати результати. Все те, що і раніше. В сьогоденні найбільша проблема ІТ це компетентний та грамотний менеджмент. Петрович мав шанс :)

Скорее наоборот
Они имели шанс не грузить Петровича фигнёй, а дать нормально работать

А зачем, до отпуска Петровича всех все устраивало. И разговоров никто никаких не начинал. Видимо контракт у Петровича железный :D

Часто не говорят до последнего
А может Петровича попросили молчать

можливо Петрович був до цього цілком готовий, просто деякий час його влаштовувала така модель роботи

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

Можливо. Але це нечесно по відношенню до кліента — створювати «видимість» роботи замість самої роботи. Результат красномовний.

Воу-воу! Полегче! Это же модель чуть более чем всего аутсорса

А в лозунгах на сайтах пишут «Изменим мир к лучшему» наверное Греты Тунберг насмотрелись :D

А что еще писать? «Оберем как липку»?

чому пэтровича мае цивыть «рэзультат» якойись там украйининськойи команды? особливо там дэ «загублэнэ мисцэ»

Рускій язык харошая? С/С+ руйнує Ваш мозок :)

Опыт, который мы вынесли:
Делитесь тем, что знаете, не старайтесь быть уникальным носителем знаний

На что направлены ваши советы?
Ваши советы приносят пользу исключительно компании, но не конкретному специалисту.
Побуду немного Кожаевым — почему я должен стремиться быть не-уникальным специалистом? Чтобы меня было легко заменить или отказать в повышении зп?

Тесная работа в команде сплачивает людей, делает коллектив по-настоящему дружным.

Вы путаете теплое с мягким. Дружным коллектив делают адекватные люди, а не тесная/плотная/потная/усердная работа.
Если в коллектив набили асоциальных интровертов — сколько с ними тесно не работай, дружной комманды не слепишь.

Причем тут интрверты? Если работа тупая с говнопроцессами, то люди элементарно злятся и вся дружба будет максимум набухаться и поговорить на тему, как все насточертело

я вообще не пойму даже, почему интроверты ассоциируются с асоциальностью, интроверты — это люди, которые редко коммуницируют с малознакомыми людьми just for fun, они всегда общаются с конкретной целью, при наличии такой цели коммуникации (например нужно решить ту же задачу по работе) они могут быть и коммуникабельней экстравертов (которые тоже мб асоциальными)

+++++. интроверты это те кто говорят только по делу, а не треплются попусту. асоциальность тоже разная бывает. есть люди социопаты (те кто ненавидят людей) но при этом пообщаться очень даже не против — например с целью потроллить

На мою думку, унікальність людини це не лише знання. Це також досвід і персональні якості (софт-скіли). Knowledge sharing дозволяє працювати більш ефективно в команді, і досягати результатів. Комусь хочеться бути самим розумним в команді, де йде процес і відсутній результат? Сильних командних гравців не змінюють, якщо говорити про нормальну компанію. Тому зовсім незрозумілі побоювання «унікальних» спеціалістів :)

Тут дело не в том, что я против ноулидж шеринга или обучения, нет.

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

И у меня вопрос — если я такой весь из себя незаменимый спец, и у меня есть не-незаменимые подчиненные — для чего мне все менять, если ситуация меня устраивает?

У автора статьи нет другой мотивации для шеринга, чем благо работодателя?

Вывод автора из этой истории вообще притянут за уши.

>>> Knowledge sharing дозволяє працювати більш ефективно в команді, і досягати результатів

Це загальне благо всіх в команді. Це лише потрібно зрозуміти — дивлятся не на кожного окремо, а на результати команди в цілому.

Та навіть розгрібати завали з завдань після відпустки або отримувати купу повідомлень підчас неї не дуже приємна справа

Побуду немного Кожаевым — почему я должен стремиться быть не-уникальным специалистом? Чтобы меня было легко заменить или отказать в повышении зп?

Сколько я написал статей? Десять! Сколько ты? Так отож! Получается ты больше Кожаев, чем я!
Что касается знаний, вопрос стоит по другому: как объяснить владельцам, что грамотные работники это их прибыль, а работникам что знания — их повышение зарплаты? Большинство тупо не хочет ни учиться — ни оплачивать учебу. И мне нет никакого смысла приставать к ним с моими знаниями.

Сколько я написал статей? Десять! Сколько ты? Так отож! Получается ты больше Кожаев, чем я!

Красиво зашел :))

как объяснить владельцам, что грамотные работники это их прибыль

А это, имхо, далеко не всегда так.

Побуду немного Кожаевым — почему я должен стремиться быть не-уникальным специалистом? Чтобы меня было легко заменить или отказать в повышении зп?

Потому что делитесь вы не опытом, а просто финальной точкой. Часто финальная точка какого-то результата — она лично ваша и только вы в курсе, как до нее дойти.
Поэтому делиться знаниями полезно. Потому что повышает вашу ценность (именно вашу) как специалиста. Учтите, я тут говорю не о знаниях уровня «как сделать string_reverse в languange_name», а более сложных вещах типа выбора архитектуры, применение конкретных методов (или паттернов, как многие любят) в конкретных случаях. Т.е. тот уровень знаний, когда даже просто совет непосвященному вызовет больше вопросов чем ответов.

Ваши советы приносят пользу исключительно компании, но не конкретному специалисту.

не приносят они пользу компании )) ровно свежее письмо дословно «thank you for your proactivity»

только тут конкретная фишка в том что (по крайней мере в американском варианте) эта «польза» как раз не компании но конкретному сотруднику включая такой себе включенный сигнал «надо валить!» (к) (тм)

читай это конкретно таки путь «стремиться быть уникальным» ))

в коллектив набили асоциальных интровертов — сколько с ними тесно не работай, дружной комманды не слепишь

а зачем а) с ними тесно работать б) лепить с них дружную команду?

что вообще такое «дружная команда» в рамках бизнеса и зачем?

обращаясь ко всё тому же ж варианту американскому я наблюдаю его 20 лет и в т.ч. уже на своём опыте могу сказать что в американском варианте на самом деле нет никакой «дружной команды» есть просто «рабочие профессиональные отношения» (коим уделяется такая куча ресурсов на compliance что курсы по тому как не надо хватать других сотрудников за попу включая себя самого проводятся так вообще раз в год на постоянной основе а не только для ньюкамеров и всё равно прецеденты там и сям) и есть уже конкретно совсем персонально личные отношения т.е. вообще вся система «персональных бизнес ценностей» строится исключительно вокруг а) персональной личности б) персонально личных контактов

отсюда как следствие рекомендации отсюда как следствие перетягивание личных связей к себе в команду или компанию

ещё конечно существуют системы разных «братств» но это уже совсем другая история и снова же ж к «дружной команде на работе» не имеющая прямых отношений

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

С точки зрения бизнеса уникальных специалистов — следует увольнять первыми)

И после банкротится. Ну, тоже путь.

кстати да киношечка годная «дьявой носит прада» я постоянно пересматриваю таки там тема раскрыта более чем годно ))

Полезная статья. Вот бы все это понимали, многим такие простые вещи не очевидны.

Спасибо за хорошую статью :-)

Подписаться на комментарии