Важка артилерія за 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, проєкт вдалось би завершити. Проте якість результату та атмосфера в команді були б значно гіршими.
Варто хоча б спробувати доповнити технічний бекграунд м’якими навичками. В результаті можна отримати більше фану, зрозуміліші задачі та краще збагнути розробку загалом.
Ілюстрація Аліни Самолюк
По материалам: http://feedproxy.google.com/~r/DevelopersOrgUa/~3/k1POfPc9lsQ/