Важка артилерія за soft skills: чому інженерам-початківцям важливо розвивати м’які навички

Усім привіт. Мене звати Аня. Я випускниця Binary Studio Academy, нині працюю QA-інженером. Під час навчання в академії наша команда розробляла проєкт для навчальних цілей (аналог Plurasight), де, власне, мені й випала нагода вперше спробувати себе у ролі 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, про який говорити мені найважче, тому що я визнаю його цінність, але не є його прихильницею. Багато в кого адаптивність асоціюється з безініціативністю, проте на неї можна подивитися з позитивної точки зору. Гнучкість варто проявити тоді, коли ви зробили все можливе, щоб змінити ситуацію в кращий бік, але це не вдалося.

Думаю, багато початківців мають свіжий погляд та чимало ідей і одразу хочуть втілити їх у життя. Але часто стикаються з реальністю, де треба враховувати обмеження в часі, стек технологій та цілі замовника. Отже, потрібно бути готовим до того, що не всі ідеї будуть реалізовані й змінювати доведеться багато й постійно.

Нерідко мої пропозиції брали в роботу, але потім їх повністю змінювали або заміняли іншими. У такі моменти я просто переконувалася, що правильно донесла свої думки, аргументувала їх та продовжувала працювати. Головне — не сприймати це як щось негативне і розуміти, що розробка — процес, який потребує змін для досягнення спільного доброго результату.

Загалом, зізнаймось чесно, нерідко ми опиняємося в ситуаціях, на які з тих чи інших причин впливу не маємо. Тому адаптація під вимушені обставини все ж допоможе зберегти нерви.

Навичка, якої мені бракує

Розповідати про позитивний досвід завжди набагато легше, але про негативний — корисніше. Донедавна я навіть не знала про існування такого поняття, як self-менеджмент. Точніше не знала, що ця навичка має саме таку назву. Саме цього мені бракувало під час навчання в академії та й, чесно кажучи, бракує досі. Тому що за постійними думками про роботу в команді, проактивністю та емпатією я забуваю подумати про себе.

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

Потрібно враховувати важливість задач і те, як вони вплинуть на проєкт загалом. Наприклад, не дуже доцільно займатися дизайном сторінки профілю, якщо не працює аутентифікація. Це грубий приклад, але він показує, що найважливіше — розв’язати основні проблеми, а потім займатися другорядними. Тому що здебільшого хочеться встигнути все, але час насправді обмежений, на все його точно не вистачить.

Для цього і є пріоритетність завдань. Це добре демонструє один з принципів тестування про те, що вичерпне тестування неможливе. Тобто як би багато часу не витрачали, якими б продуктивними не були, встигнути все не вдасться.

Зараз, працюючи QA-інженером, я досі вчуся прислухатися до власних емоцій і оцінювати свої сили та роботу належним чином. Думаю, кожен хоче працювати з людьми, які будуть правильно ставити задачі, реально оцінювати час на них і мотивувати. Але чи потрібно очікувати цього зовні? Навряд чи хтось допоможе нам краще, ніж ми самі, тому варто почати менеджити самого себе.

Отже, self-менеджмент — це про вміння стати для себе ефективним менеджером, який правильно розставляє пріоритети, успішно делегує задачі, вчасно мотивує. І я рекомендую зважати на свої відчуття і не плутати лінь з вигоранням. Звичайно, наша ефективність дуже важлива, але деколи варто перейти на темну сторону з печивком і серіалом і все ж таки відпочити, коли цього потребуєте.

Як розвивати soft skills і не погіршувати стосунки з командою

М’які навички тісно переплітаються між собою, і наявність одного з них може допомогти розвинути ще кілька. Можна бути проактивною людиною, але якщо в команді тебе не хочуть чути, донести ідеї буде суперважко. Проактивним бути складно не тільки для самої людини, тому що вона завжди ризикує бути непочутою, а й для тих, хто працює з нею.

Наприклад, під час проєкту в академії я була дуже вимоглива до UI/UX, можливо, розробники тихенько мріяли, щоб у мене завис Zoom і я нарешті перестала розповідати про те, як важливо змінити кнопку, колір фону чи тексту або додати бордер. І тут головне не переборщити.

Я розуміла розробників, адже вони витратили багато часу на таску, а їм сказали її переробити. Часто мені доводилося пропонувати змінити навіть власні ідеї, тому що вони не працювали, як я очікувала. Тут потрібно віддати належне розробникам у моїй команді, тому що їхній гнучкості позаздрить кожен. Тільки уявіть собі, що ви не спали до третьої ночі, а вам кажуть, що верхній бордер у кнопки затовстий. І вони спокійно все це слухали, переробляли і, самі того не усвідомлюючи, нарощували м’язи гнучкості. Якби в команді не хотіли реалізовувати мої ідеї або будь-кого іншого учасника, жодна проактивність тут не допомогла б. Якщо дивитися на продукт з багатьох сторін, це сприятиме гарному результату.

Що дали мені soft skills

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

І я працюю над тим, щоб доносити свої думки ясніше та швидше, більше слухати інших та знаходити точки дотику. Якщо постаратися, практично з усіма можна знайти спільну мову, навіть якщо на перший погляд здається, що ви з різних планет. Проте це виходить не завжди. Якщо не вдається, я просто згадую про адаптивність і приймаю ситуацію. Як показує досвід, гнучкість — це суперкорисне вміння.

Загалом soft skills — це абстрактне поняття, до нього може належати все що завгодно: від креативності до стресостійкості. У статті я намагалася виділити ті навички, які, на мою думку, дали мені змогу розпочати кар’єру QA-інженера.

Я пам’ятаю наше перше знайомство з командою в академії. Ми були невпевненими інженерами-початківцями, які до кінця не уявляли, що їх чекає на проєкті і якою є розробка зсередини. І я впевнена, що, якби кожен з нас виконував роботу ідеально в технічному плані, але взагалі не застосовував soft skills, проєкт вдалось би завершити. Проте якість результату та атмосфера в команді були б значно гіршими.

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


Ілюстрація Аліни Самолюк

Підписуйтеся на Telegram-канал редакції DOU, щоб не пропустити найважливіші статті.

👍НравитсяПонравилось17
В избранноеВ избранном6
Подписаться на автора
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


22 комментария

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

Чесно кажучи, підвищена увага до т.з. soft skills останнім часом дратує. Це виглядає як спроба на додаток до «профессиональные навыки в управлении легковыми и грузовыми автомобилями, троллейбусами, трамваями, поездами метрополитена и фуникулера, экскаваторами и бульдозерами, спецмашинами на гусеничном ходу, боевыми машинами пехоты и современными легкими/средними танками, находящимисяна вооружении стран СНГ и НАТО» викрутити з тих інженерів щось ще, таке що інженірінгу взагалі не стосується.

Цікаво чи soft skills встановлюють якусь межу, коли їхнє застосування стає нераціональним.
Буває, людина просто зроблена з гі%на і до неї постійно треба «знаходити підхід» для досягненння адекватного результату.

На жаль, не завжди доводиться спілкуватись з однодумцями, але саме розвинені soft skills допомагають вирішити непорозуміння.

Особисто ви і не «знайдите підхід». «Зроблена із гімна» — це із вашої особистої думки і враховуючи ваші особисті інтереси. Цілком може бути що з точки зору іньшої сторони — ви самі не дуже добре пахнете і заважаєте жити. Це все в загалі про пасивну агресію (toxic behaviour). Такий конфлікт може вирішити тільки третя сторона — посередник, або дуель.

Дякую за ілюстрацію.
Прозвучало слово «особисто» — за моїми спостереженнями це і є частою причиною для потреби у soft skills — коли людина сприймає повернутий баг або коментар до пулл реквесту як «особисте» — тут і «конфлік» Ваш на рівному місці.
«Інтереси» насправді мають бути лише одні — технічна або користувацька необхідність. І їх легко підтвердити посиланням на технічну документацію, або умови завдання. А коли замість цього лунають звинувачення хто чим пахне, тоді робота зупиняється.

Зависит от того, насколько для вас важен этот человек и общение с ним.
Если это ваш начальник/коллега/подчиненный, то достаточно сменить компанию вместо того, чтобы «терпеть». С другой стороны, если там какая-то уникальная вакансия/проект/зп, то все может оказаться не так просто.
Аналогично и для ситуаций с отношениями (девушка/жена) или близкими родственными связями (родители/дети). Иногда имеет смысл терпеть и находить подход, выжимая из своих софт скиллов максимум. Иногда — наоборот, решительно разорвать связь и сжечь все мосты.
Жизнь — сложная штука и какого-то универсального рецепта для вашего вопроса не существует.

Я человек простой и люблю цифры.
Есть ли какая-нибудь шкала для EQ (по аналогии с IQ, где 100 — средний человек) и корреляция между уровнем EQ и уровнем дохода?
Ну например, кому вероятнее дорасти до зп 6к:
1) IQ 120, EQ 80
2) IQ 100, EQ 100
3) IQ 80, EQ 120

Угу есть такие шкалы. Это шкала IELTS или шкала TOEFL. На практике прямая корреляция. С 9-ю или C2 (115-120) шансы весьма высоки. Правда не все native обладают таким словарным запасом и грамотностью.

Важка артилерія за soft skills: чому інженерам-початківцям важливо розвивати м’які навички

Хороший вопрос, Анна! Я тоже долгое время над этим задумался, пока не пришел к очевидной мысли — потому что особое состояние IQ, которое требуется для работы программистам, формирует специфический EQ. А по скольку все исследования в этой сфере касались в основном представителей гуманитарных направлений — менеджеров, продавцов итд, то стало совершенно очевидно, что гуманитарный подход совершенно не подходит для IT-специалистов!

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

Так уж вышло, что буквально на днях я получил регистрацию своей методологии: www.linkedin.com/...​-6763490124979339265-NVpM

Если интересно, можете добавляться. Вы сами удивитесь, насколько высоко развит EQ у программистов. Просто вы их не умеете понимать и не можете им правильно объяснять.

Это решение будет в ближайшем будущем, а что самое главное — вы можете быть к нему причастны и проявить себя как самый настоящий эксперт. Подробности по ссылке: rogovsky.net/...​ть-соавтором-это-выгодно

P. S. Сейчас меня могут обвинить в том, что я создал виртуала, чтоб попиариться, и никакой Анны не существуюет, а это просто мой другой аккаунт.

Десять років тому серед тестувальників софт-скіли особливо популярними не були, переважно вони заточувалися під якесь ніби протистояння з програмістами і там не було не те що синергії — до декого навіть не доходило, що ми одна команда. Смішно, але такі ж айтішники як і ти, просто іншого профілю, поводились як на моїй першій роботі менеджер з «відділу технічного контролю», коли йому (з відділу, який приймав охоронні пристрої) доручили перевірити наше пультове ПЗ, тобто наче протиставляли себе нам...
Поступово виключень з цього шаблону ставало дедалі більше, а зараз, на щастя, вже такі упороті любителі знаходити баг з криком «ага!» вже якось вивелися і це чудово :-)

В нас був один такий тестувальник. Як знайде , викрикував — «ось вам — ловіть багло». Між іньшим великим менеджером став.

Бо не боявся проявляти командний спіріт

Статья — супер, согласен на 100%.
Грустно то, что рынок найма в Украине (не знаю как на западе) работает таким образом что Soft Skills инженера никто особо не оценивает, и соответственно предложение по компенсации отражает условно только то как кандидат прошел технические собеседования. Иными словами, Soft Skills не ценятся на рынке, в компании где инженер работает несколько лет и успел себя проявить, он/она может получать добрых +30, а то и +50% именно за это — проактивность, коммуникацию, тайм-менеджмент, итд. и в такой ситуации оффер в новой компании редко будет выше или хотя бы на уровне текущей работы.
Возможно так обстоят дела по причине того что оценить soft skills на собеседованиях намного сложнее, а возможно считается в среднем что они нужны нужны только менеджерам, а инженер должен просто писать код, много и быстро, а если что перепишет.

Скажите, а токарю на заводе тоже нужно проявлять проактивность, коммуникацию, тайм-менеджмент, итд. ?...или он «Странный он какой-то, стоит там балванки свои точит»?

Конечно нужно. Если он увидел, что чертеж дали кривой, то должен пойти и поговорить — точно ли ему делать кривые детали или надо перечертить.
Токарь с низким EQ за смену нанесет приличный ущерб, с высоким EQ — спасет от ущерба.

Дякую!
Але все-таки інженер, з розвиненими soft skills, завжди матиме перевагу на співбесіді або при рості в межах однієї компанії, що прямо впливає на рівень заробітної плати.

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

Вірно, тому на ДОУ радять інженерам, що вкладаються в хард скіллс, міняти контору — інакше суттєвого підвищення зарплатні не побачиш.

Молодцом!

Относительно

люди бояться бути проактивними. Тому що проактивність — це те, що прямо породжує відповідальність

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

Ну а потом уже ответственность и всë прочее.

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

Емпатія — це про вміння подивитися на продукт очима клієнта.

Змушений вас тут виправити «Подивитися на продукт очіма кліента» це про uk.wikipedia.org/wiki/Досвід_користування Це фактично hard skill для спеціаліста з контролю якості (QA) а також безнес аналітиків. Емпатія це дещо іньше uk.wikipedia.org/wiki/Емпатія Як раз ось це

Зрозуміло, що розробник, якому QA-інженер легким порухом мишки повернув завдання в in progress, навряд чи подумає про цінність і важливість тестувальника в команді. Можливо, він писав ту тасочку дві ночі, не спав і не їв і в результаті знову має до неї повертатися. Тому завоювати довіру та авторитет у команді для QA-інженера завдання не з легких.

Ремарка

Я неодноразово помічала, що люди бояться бути проактивними. Тому що проактивність — це те, що прямо породжує відповідальність. Набагато простіше чекати чогось зовні і, якщо щось піде не так, залишатися осторонь. Проте результат, який дає проактивність, майже завжди виправдовує засоби.

нажаль насправді — ні. Тому з досвідом стаеш циніком. Проактивність це звісно добре, але не траба забувати що це все про бізнес.

Дякую за Ваш коментар. На мою думку, досвід користування та емпатія дуже тісно пов’язані. Але емпатія — це soft skill, що відноситься до теми статті, а як Ви і зазначили, досвід користування — фактично hard skill.
Щодо проактивності, то ця стаття більше розрахована на початківців і рекомендації саме для них, а вже з досвідом кожен вирішує для себе чи це йому потрібно.

Тому що проактивність — це те, що прямо породжує відповідальність.

Важливе уточнення: безоплатну (стосується не тільки грошей) відповідальність у переважній більшості випадків. «Ініціатива карає ініціативних» — цей вислів доволі давно існує.

але не траба забувати що це все про бізнес

Тож бо.

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