Чому з тестувальників виходять хороші проєктні менеджери

Привіт читачам DOU, давно не бачились! Я Оля Чмир і вже два з половиною роки працюю проджект-менеджеркою у PitchBook. У проєкті наразі більше як 200 спеціалістів, я, своєю чергою, постійно взаємодію з кількома різними командами.

Зрозуміло, щоб управляти такою кількістю команд і людей, потрібна ціла менеджмент-команда. Наразі у PitchBook’у є близько 20 відповідних фахівців, серед яких Head of Project Management, Delivery Managers і Project Managers. Останні є не лише управлінцями, а й носіями культури проєкту.

За останні роки до PM-команди приєдналось кілька людей, що перейшли сюди з позиції QA Engineer (їх наразі третина).

У цій статті ми спробуємо розглянути шлях від Quality Assurance Engineer до Project Manager, найлегші задачі та типові труднощі. Маю надію, що матеріал допоможе тим тестувальникам, які задумуються про зміну свого кар’єрного шляху. І як каже наш Director of Engineering Саша Хомич, з хорошого QA можна «зліпити» кого завгодно.

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

Чому QA варто задуматися про перехід у PM

Багато професіоналів хотіли б змінити щось у своїй кар’єрі. Проте думка про те, щоб відмовитись від побудованої кар’єри та почати все спочатку, часто демотивує, тому фахівці залишаються (іноді нещасливими) на попередній позиції. Але, як зазначає Дорі Кларк у своїй книзі «Персональний ребрендинг», є способи змінити кар’єру, не відмовляючись від свого професійного статусу.

Та спершу визначмо, що робить QA Engineer’ів справді хорошими Project Manager’ами.

Бачать проєкт максимально широко. Часто Project Manager’и — це ті люди, які є носіями цілісного бачення проєкту, вони знають місце кожної фічі у великій картині.

Project Manager’и надихають фахівців і зацікавлюють їх у виконанні поставлених завдань. Однак і QA — ті, хто щодня взаємодіють із баченнями інших — змушують команду дивитись на задачі під різними кутами. А також розуміти місце кожної задачі у фінальній картинці.

Окрім того, саме QA часто виступають голосом змін у проєктних процесах і підходах.

Як зазначають наші Delivery Manager’и, що починали свій шлях в Quality Assurance, на зміни їх підштовхнуло розуміння, що на позиції проджект-менеджера вони зможуть робити більше для проєкту, будуть значно кориснішими та краще реалізують свій потенціал.

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

В обов’язки Project Manager’а входить акцентування всієї команди на певній проблемі, з якими вона стикається під час реалізації проєкту.

QA Engineer — це один з головних спеціалістів, який знає, як проєкт реалізовано «зараз» і як буде краще/зручніше для кінцевого користувача працювати з програмним продуктом. Це вже навіть не питання юзабіліті. Оскільки QA Engineer сам працює із продуктом величезну кількість разів під час тестування, саме він є тією людиною, яка може говорити, чи оптимально виконано задачу. QA Engineer розповідає, як функціональність має бути реалізована, й має уміти донести цю думку до команди та/або замовника чи партнера.

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

Їм справді не байдуже. Як QA Engineer’и, так і Project Manager’и відповідальні за якість продукт. Обидві ці ролі найбільше зацікавлені у вчасній поставці продукту на продакшен. Тобто кожен із них певною мірою на останніх етапах життєвого циклу ухвалює рішення щодо готовності продукту побачити світ.

Високорозвинена навичка ухвалення рішень та відповідальності — одна з життєво важливих навичок і обов’язків Project Manager’а, що також є обов’язковою навичкою QA Engineer’а.

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

Будь-який спеціаліст на певному щаблі своєї кар’єри думає про подальші зони розвитку. Наші QA Engineer’и бачили їх поза межами своїх обов’язків і прагнули збільшити рівень своєї відповідальності.

Як перейти

Отже, ви як QA Engineer побачили багато спільного у своїй роботі та роботі Project Manager’а й задумались про зміну професійної діяльності. Що робити далі?

Крок 1. Зміна кар’єрного шляху — це позитивне зрушення, проте готуватись до нього потрібно ще на посаді QA Engineer. Спостерігайте за вашим проєктним менеджером і спробуйте (а краще спитайте!) зрозуміти її/його обов’язки. Ідеально буде почати співпрацювати максимально щільно з нею/ним.

Розділіть його/її робоче навантаження і простягніть руку допомоги. Ви можете забрати невеликі задачі, що перетинаються з вашими. Спостерігайте, як Project Manager спілкується з командою та замовником. Ставте питання. Якомога більше питань.

Крок 2. Читайте та аналізуйте проєктну документацію. Прочитайте та проаналізуйте документацію, що готує ваш Project Manager. Подумайте над питаннями «Чому саме так сформована команда проєкту?», «Як визначені та закладені ризики?» тощо.

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

Кожен з тестувальників уже володіє цінними знаннями про життєвий цикл проєкту та основні процеси постачання функціоналу та домен. Саме це допомогло їм при зміні позиції.

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

Письмова комунікація:

  • жодних граматичних помилок;
  • опануйте етикет листування;
  • знайдіть спосіб перевіряти орфографію.

Усна комунікація:

  • розвивайте вміння пояснювати складне простими словами;
  • розвивайте мистецтво переконувати.

Project Manager повинен спілкуватися із замовниками, різними зацікавленими сторонами у бізнесі та з командою (чи командами) задля досягнення спільних проєктних цілей.

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

Вдосконалення письмових та усних навичок англійської мови — не rocket science. Цього можна вчитися, допомагаючи Project Manager’у в письмових задачах (наприклад, у написанні follow-up до зустрічей з командою та/або замовником) і постійно спілкуючись англійською мовою. Курси англійської мови також є корисними. Загалом обирайте для себе найбільш комфортний і продуктивний спосіб навчання.

Найкращий спосіб — це спілкування англійською мовою як в побуті, так і в робочому середовищі. Зберіть фідбеки про вашу англійську та постійно вдосконалюйтесь.

Крок 4. Час поговорити з Project Manager’ом щодо ваших прагнень. Це може бути черговий 1-1. Або попросіть про позачергову зустріч. Саме проєктний менеджер може дати вам перший шанс у команді. Якщо не на поточному проєкті, то в інших проєктах компанії, адже Project Manager переважно знає про такі можливості.

Якщо ж ви є критично важливими на проєкті, запропонуйте Project Manager’у для початку розробити план вашого навчання та переходу й поєднувати ролі 50/50. Зрештою, починати на знайомому проєкті та зі знайомою командою буде значно легше.

Крок 5. Вибір ментора та підготовка навчального плану. Якщо ваш Project Manager і проєкт готові дати вам шанс, то час визначатися з ментором. Це може бути ваш Project Manager або Project Manager іншого проєкту компанії. Зрештою, це може бути і стороння людина, яка готова вам допомагати, скеровувати та ділитись своїми знаннями та досвідом.

Під час випробувального періоду на нашому проєкті ми маємо розроблений 12-тижневий тренувальний план для нових Project Manager’ів. Для тих, хто проходив через зміну позиції, цей план дещо скоригували. Також це може бути адаптований план персонального розвитку (PDP), взятий на озброєння у багатьох ІТ-компаніях.

До навчального плану входять усі заплановані активності на період навчання та/або випробувального періоду як проєктного менеджера. Це вивчення ухвалених на проєкті підходів до управління (довгострокове та короткострокове планування, виконання проєкту), ознайомлення із роботою Project Manager’а в таск-трекерах (у нашому випадку JIRA), підходи до менеджменту команд тощо.

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

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

За досвідом наших «юних» Project Manager’ів найлегшими були задачі, пов’язані зі структуруванням та бізнес-аналізом. Легко вдавалось налаштовувати комунікацію із замовниками і командою для тих, хто перемістився на позицію проєктного менеджера в межах одного підпроєкту та команди.

Крок 6. Робота на першому проєкті та перші помилки. Уже з перших тижнів наші «світчери» отримували реальний проєкт і виступали в ньому Project Manager’ами. Ментор перевіряє роботу, підтверджує хід проєкту та... дозволяє робити помилки. Важлива ремарка: ви будете помилятись, не бійтесь цього. Головне — розбирати причини виникнення помилки, наслідки, до яких вони призвели, та вчитись.

Насправді перша проєктна робота має лише єдину відмінність від тієї, що чекає попереду — вона проходить під постійним наглядом, ще ці менеджери мають поки обмежену відповідальність. Проте під час навчання вони проходять усі етапи прийнятого на PitchBook проєктного процесу: разом із Business Analyst та Team/Tech Leads вивчають вимоги, готують та обговорюють оцінки, планують ресурси та проєктну роботу, ведуть повний цикл комунікації із замовником та командами, звітують про прогрес та разом із ментором ухвалюють рішення про поставку.

Серед найскладніших задач для майбутніх Project Manager’ів — управління підтримкою проєкту (пріоритезація продуктових і технічних задач, алокація ресурсів команд), багатофокусність і постійне перемикання між завданнями. Декому важко було позиціонувати себе перед командою в новій ролі та управляти колегами, які ще недавно були вищі за посадою. Комусь важко давалось делегування.

Крок 7. Офіційний перехід і передача справ. Якщо є проєкт, що займає 1–2 місяці (приблизно стільки часу триває випробувально-навчальний період), то рішення про перехід на позицію Project Manager’а ухвалюють за результатами завершення проєкту. Якщо проєкт великий, то по закінченню певного milestone.

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

Крок 8. А що далі? Project Manager має постійно підвищувати свою кваліфікацію. Ви можете спробувати отримати визнані в галузі сертифікації.

Є також кілька семінарів і центрів з підготовки Project Manager’ів як онлайн, так і офлайн. Можна розглянути сертифікацію в Agile Frameworks.

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

Також Project Manager працює над документацією та використовує різноманітні Project Management tools.

Замість висновків

Позитивно, що ви думаєте перейти від тестування до проєктного менеджменту. А кар’єрне зростання Project Manager’ів буває досить стрімке у порівнянні з іншими ролями.

Project Manager — це своєрідний місточок між бізнесом і командою розробки. І такий фахівець взаємодіє з різними зацікавленими сторонами.

Отже, для проєктних менеджерів важливо думати нестандартно. Їм доводиться працювати самостійно, використовуючи свої аналітичні та стратегічні навички, тому часто кажуть, що хороший QA Engineer має всі можливості стати успішним Project Manager’ом.

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



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

31 комментарий

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

Спасибо за материал :)))
Ну согласна, что если не попробуешь — никогда не узнаешь. Однозначно нужно прокачивать скиллы, чтобы быть релевантным в новой сфере и так везде. Формула универсальная и рабочая. Может я когда-то попробую.

Стаття трохи дивна.
Боюсь її розбирати, бо буде один цитатник...

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

Тоді кар’єрна драбина не буде працювати, бо на посаду виконавчого директора після курсів чи навіть ВУЗу не беруть.

Загалом ідеальний сценарій, це коли ніхто нікуди не свічається,

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

Сам лично начал с тестирования, перешел в разработку.

Це коли я знаю, що мені подобається і кайфую від цієї справи) і тільки прокачуюсь з роками) і стаю норм експертом в напрямку) і завод тут ні до чого)))

ой да раскажи ага, дай тебе столько денег сколько нужно — сидел бы ты прожигал глаза у монитора.

багато років нічого не змінюється) тому кожному своє

Ви ніколи не станете дійсно експертом в технічній галузі, тому що технології оновлюються кожні 5-7 років.
Якщо ж ви працюєте в області, яка 20 років одна і та ж (наприклад, 1С), то це явно не той шлях, який стоїть рекламувати.

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

Як можна прокачати навички CEO, працюючи в QA?

Десь не побачив достатньо аргументації чому ж таки виходять. 2/3 статті як стати проектним менеджером.
Мій досвід каже, що не виходять хороші проектні менеджери з QA, так само як і з інженерів. Аніматори так, менеджери рідко. В нас в принципі індустрія наповнена посередніми менеджерами і QA не мають в більшості випадків якихось переваг, хоча задавалося б в них є та перевага, що вони більше на стороні кінцевого клієнта і специфіка роботи вимагає кращих комунікаційних навиків. Але це не працює по мірі росту складності проектів. Бо брак розуміння складності інженерної складності не заміниш, якщо пощастить і маємо сильних лідів чи архітекторів то вам пощастило, але система з цього не виходить. Коли немає розуміння реальну роботу заміняють субстрактом — абстрактними метриками і їх сліпому слідуванню, а це рецепт до конфліктів і недосягнутих цілей.

Ви так стверджуєте, ніби QA і R&D — це раси або національності.
Людина може потрапити в QA випадково і тільки як PM вже розкритися.
Я бачив різних PM, і хороших і не дуже, вони були вихідцями з різних напрямків, на якість їх роботи це мало впливало.

з тестувальників виходять хороші проєктні менеджери

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

Кликбэйт, ничего личного ;-)

Просто автор забув дописати, що виходять і не дуже гарні.

Я думаю цей ефект і враження підсилене тим, як ми відбираємо QA. Наш проєкт по певним причинам складнуватий, вхідна планка по розумінню комплексних пов‘язаних явищ і систем висока (на що жаліються як кандидати, так і рекрутери), тому є вірогідність, що до нас попадають більше толкових амбіційних, але не дуже готових до інших ролей людей, саме через QA. Проте якщо згадувати, реальні кейси починаючи від Жені П закінчуючи Тоньою, Аньою і Дашою, то все ж дівчата очевидно розвивали свою вроджену гіпер відповідальність і бажання впливати на ширше коло подій і відчувати значимість, маючи під ногами непогане розуміння всієї ширини процесів.
А інженерам/девелеперам що?... їх ліпити можна, але часто виникає пиатння — навіщо? Коли челенжів та відчуття результату і відповідальності за створене рішення/продукт вистачає за очі )))

Наш проєкт по певним причинам складнуватий, вхідна планка по розумінню комплексних пов‘язаних явищ і систем висока
А інженерам/девелеперам що?... їх ліпити можна, але часто виникає пиатння — навіщо? Коли челенжів та відчуття результату і відповідальності за створене рішення/продукт вистачає за очі )))

Ви трохи плутаєтесь в показаннях :) Та і в цілому комент можна нарізати на купу трололо-цитат.

каждый хвалит своё болото

Так как все-таки компания называется, в которой из QA штапмуют PMов?
PitchBook или SPD-Ukraine?

І як каже наш Director of Engineering Саша Хомич, з хорошого QA можна «зліпити» кого завгодно.

А в чому проблема «зліпити» те ж саме з __хорошого__ девелопера чи адміна? (Слово «хороший» робить з цієї фрази чисту маніпуляцію)
КуА не простіше свічаються в ПМів, просто людей з інших ІТ спеціальностей часто __дорожче__ всічнути. Наприклад, порівняємо перехід з девелоперів:
— втрати для проекту. КуА замінити дешевше.
— ЗП на новій позиції. У КуА ЗП в середньому нижче, тому знову ж КуА дешевші.
— необхідні софт скіли. От тут у КуА перевага, бо для них софт скіли є фактично хард скілами. Але у випадку з «хорошими» спеціалістами, це не проблема.

Чому з тестувальників виходять хороші проєктні менеджери

Якось не побачив в статті пояснень/аргументів, за рахунок чого з КуА вийдуть саме хороші ПМи.

А кар’єрне зростання Project Manager’ів буває досить стрімке у порівнянні з іншими ролями.

Буває? Чи зазвичай є?
Якщо перше, то буває, що і повільніше ніж у інших. В цьому світі багато чого буває.
Якщо друге, то це не правда, бо вакантних позицій на ДМ і вище не завжди є достатньо, особливо в світі аутсорсингу, де менеджмент часто є зі сторони замовника. В той же час КуА/Дев може рости значно простіше або налаштовуючи делівері процеси для свого проекту, або стаючи експертом (консультантом для різних команд, представником бренду компанії на конференціях).

не виходять

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

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

З більшості людей можна зліпити, що завгодно. От тільки щоб зробити з тестувальника, наприклад, девелопера, треба просто щоб він ... перестав тестувати і ... почав навчатись програмуванню.

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

Якщо AQA то не треба.

Нажаль всеодно треба, якщо не вчитись, то перевчитись. Так само як при переході, наприклад, з веб в ембеддед треба буде перевчатись.

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

Понатискати кнопки може кожен, але не кожен складе матрицю тестування і напише адекватні тесткейси.

як показав досвід, навіть кнопки понатискати не кожен уміє)))))))

В Україні більшість навіть не вміє на виборах поставити галочку в правильній клітці.

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