Тяжелая артиллерия за soft skills

Всем привет. Меня зовут Аня. Я выпускница Binary Studio Academy, и сейчас я работаю QA-инженером. Во время обучения в Академии наша команда разрабатывала образовательный продукт (аналог Pluralsight), где мне и представилась первая возможность попробовать себя в роли QA.

Именно там мне удалось расширить свои знания, усовершенствовать навыки и применить их на практике, а также прокачать свои soft skills и понять, насколько это важно для специалиста. Это помогло мне успешно устроиться в компанию на позицию Junior QA-инженера. И “мягкие навыки” сыграли в этом не последнюю роль.

В этой статье я хочу поделиться приобретенным опытом, собственными наблюдениями и показать, что такое soft skills и зачем их нужно развивать. Материал будет интересен в первую очередь начинающим разработчикам и тестировщикам, которые только на старте своей карьеры.

Думаю, вы неоднократно замечали, что этой теме уделяют много внимания. Но стоит признать, что есть некая нотка недоверия, ведь инженеры - технические специалисты, и на первый взгляд кажется, что тема “мягких навыков” их не касается. Честно признаю, что до проекта в Академии у меня было схожее мнение. Что программирование и soft skills сложно применять одновременно.

На фото я (в центре) с однокурсниками Binary Studio Academy

Soft skills для инженеров

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

Для меня это было почти как в шутках об ожидании - реальности. Я открыла для себя, что разработка требует очень много общения: ежедневные созвоны с командой, обсуждение проекта, еженедельные демо для Product Owner-а. Поэтому, опираясь на собственный опыт, я выделила основные soft skills, которые важны для инженера: работа в команде, гибкость/адаптивность, проактивность, эмпатия, self-менеджмент.

Как “мягкие навыки” влияют на работу в команде

Для меня работа в команде - это то, что лучше всего дает возможность почувствовать ценность soft skills. Думаю, всем интересно, какой видит командную работу «тот, кто мечтает найти как можно больше багов и вернуть как можно больше тасок». Наверное, примерно таким вырисовывается образ QA-инженера в воображении других (особенно, людей без опыта). Мне хотелось развенчать этот миф и построить хорошие отношения с командой.

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

У меня было так: в течение первых нескольких дней работы над веб-приложением в Binary Studio Academy мы знакомились с командой, проектом, и все это было очень увлекательно и интересно. Мы, тестировщики, занимались своей работой, разработчики - своей. Кроме меня, на проекте было еще два QA-инженера.

В течение первой недели мы с QA team много общались, советовались и делали многие вещи вместе, и это положительно повлияло на результат. По моему мнению, работать каждому отдельно было бы значительно сложнее. Все, вроде, шло по плану, Acceptance Criteria писались, Mind map рисовался, и работа, казалось, наладилась. Как вдруг... Появилась она - первая тасочка, которую нужно протестировать. Дрожащими руками я начала внимательно все проверять... И нашла баг. Казалось бы, вот он - звездный час QA-инженера. Сейчас оформлю баг и с ощущением, что мир спасен, запишу это в свой воображаемый список ачивок. Открываю Trello и создаю карту с багом. Но если бы все было так просто.

В тот момент в голове возникают мысли: «Возможно, я что-то плохо проверила?», «Возможно, так и должно все работать?». И тут вспоминается хорошая фраза - to be a part of the team. Напечатала сообщение в Slack и моментально нашла ответы на все вопросы. А потом таких переписок были сотни: с разработчиками, QA-инженерами, менторами. Мы коммуницировали как могли: переписывались, созванивались, «шарили» экраны друг другу и совместно принимали множество решений. И этот опыт дал понять, насколько умение работать в команде может помочь, повлиять на качество и облегчить жизнь каждого специалиста.

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

При разработке проекта в Binary Studio Academy мы тратили немало времени на общение, но это не было зря потраченное время. Зачастую мы часами решали вопросы дизайна одной страницы, но это ничто по сравнению с тем, сколько потратил бы на это разработчик сам, у которого на тот момент вообще не было никаких идей.

После окончания Академии я пришла к выводу: можно по 20 раз передумывать и создавать в голове кучу проблем, а можно просто говорить и спрашивать - это на 100% эффективнее.

Эмпатия, проактивность и гибкость

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

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

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

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

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

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

Гибкость, или адаптивность - это тот soft skill, о котором говорить мне сложнее всего, потому что я признаю его ценность, но не являюсь его поклонницей. У многих адаптивность ассоциируется с безынициативностью, однако на нее можно посмотреть и с положительной точки зрения. Гибкость стоит проявить тогда, когда вы сделали все возможное, чтобы изменить ситуацию в лучшую сторону, но это не удалось.

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

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

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

Навык, которого мне не хватает

Рассказывать о положительном опыте всегда намного легче, но об отрицательном - полезнее. До недавнего времени я даже не знала о существовании такого понятия, как self-менеджмент. Точнее не знала, что этот навык имеет именно такое название. Это как раз то, чего мне не хватало во время учебы в Академии и, честно говоря, не хватает сейчас. Потому что за постоянными мыслями о работе в команде, за проактивностью и эмпатией я забываю подумать о себе.

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

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

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

Получается, self-менеджмент - это об умении стать для себя эффективным менеджером, который правильно расставляет приоритеты, успешно делегирует задачи, вовремя мотивирует. И я рекомендую учитывать свои ощущения и не путать лень с выгоранием. Конечно, наша эффективность очень важна, но порой стоит перейти на темную сторону с печенькой и сериалом и все же отдохнуть, когда вы в этом нуждаетесь.

Как развивать soft skills и не ухудшать отношения с командой

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

Например, во время проекта в Академии я была очень требовательна к UI/UX, возможно, разработчики даже тихонько мечтали, чтобы у меня завис Zoom и я наконец перестала рассказывать о том, как важно изменить кнопку, цвет фона или текста, или добавить бордер. Поэтому здесь главное - не переборщить.

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

Что мне дали soft skills

Помогли ли soft skills лично мне? Безусловно. Буду ли я их развивать дальше? Несомненно. Для моего развития сейчас важны гибкость, self-менеджмент и эмпатия. Мне всегда нравилось чувствовать себя частью команды, видеть свой вклад в нее.

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

В общем, soft skills - это абстрактное понятие, к нему может принадлежать все что угодно: от креативности до стрессоустойчивости. В статье я пыталась выделить те навыки, которые, по моему мнению, дали мне возможность начать карьеру QA-инженера.

Я помню наше первое знакомство с командой в Академии. Мы были неуверенными начинающими инженерами, которые до конца не представляли, что их ждет на проекте и какова разработка изнутри. И я уверена, что если бы каждый из нас выполнял работу идеально в техническом плане, но вообще не применял soft skills, проект удалось бы завершить. Однако качество результата и атмосфера в команде были бы значительно хуже.

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