Шлях до позиції Project Manager. Рекомендації для Початківців
Мій шлях від QA Engineer / QA Team Lead / QA Manager до Project Manager ( час від часу була навіть Technical Writer).
Чому і як? Дам відповідь на цих два питання тут і, сподіваюся, це буде корисно для початківців, хто починає кар‘єру Project менеджера (хоча, насправді, не лише початківцям).
Почала свою кар‘єру як Quality Assurance Engineer. Ще тоді знала, що хочу уввійти в світ Інформаційних Технологій і вивчала ІТ в університеті. Отримувала багато проектів в аутсорс компанії, і це дало мені більшість моїх знань, навичок та досвіду.
Одного моменту, перейшла до продуктової компанії і працювала над одним великим проектом. Це було краще рішення, оскільки саме там я зрозуміла про свою кар’єру в майбутньому.
Той проект мав багато проблем в системі управління. Але тоді було не зрозуміло, що хочу змінити, бо не знала. Далі ж почалася рутинна робота: проект не стояв на місці, з‘являлися нові клієнти, розширялася команда, але завдання на розробку приходили рандомним чином.
Новий член команди довгий час не міг увійти в проект, оскільки не вистачало інформації. Мало хто до кінця розумів всю суть проекту…
Тоді, ми вирішили ввести документування, описати повністю існуючий функціонал, оптимізувати QA документування і т. Довелося стати ініціатором, чомусь начиталася стандартів з технічної документації та запропонувала, і мені дозволили тратити певний час на документування. Хоча, насправді, це повинен був робити Technical Writer і частково вся команда.
Більшісь команди ставилася до цього скептично. Кому воно треба, не хочу / не буду і тому подібне. Потратила багато сил на написання документації, її раніше майже не було.. і чомусь вірила, що це допоможе, і в навіть було натхнення. Це спрацювало!
Дивно, але факт, більшість команди, особливо новачки знали більше, Support команда менше зверталася за допомогою до Development команди, бо були чіткі інструкції, кожна нова фіча, покращення (доречі, було запропоновано певний лексикон) були чітко алгоритмічно описані. Мені це подобалося, і менеджмент команді теж.
Та все хороше колись закінчується… я ж була щей тестувальником (одним! на той час). Проект зростав, команда теж, а на QA чомусь економили. Прийшов час, коли не встигала нічого, і не було ніякого натхнення від цього. Задачі змінювалися майже погодинно і тоді закинула справу з документуванням…
Та вирішила, що треба покращувати Менеджмент. Здається, всім було байдуже, аби відбути день на роботі і забути як про страшний сон. Знову почала досліджувати тему Управління. І мені це зайшло.
Звичайно, почала менше тестити, менше цікавитися цією областю, але згодом в мене з‘явилися студенти на QA (так би мовити, нехай повчаться, попрацюють кілька місяців безкоштовно, а там вирішимо). Досвід навчання в мене був (я захищала кандидатську в універі) і вчити когось складно не було. Але керівництво знову не розуміло, що це мій час, а продукт то не тестується повноцінно. Чому не можна було найняти Middle QA для мене залишилося загадкою, але зараз не про те.
Так от, згодом зрозуміла, що мої ідеї заходять, але їх немає кому виконувати. І поступово навчала своїх QA Trainees, перекладаючи роботу тестування на них, а тим часом приймала участь в різних мітингах і все більше спілкувалася з менеджментом. Інколи були дні, що весь час займали мітинги, і одним днем мені запропонували зайняти роль Project Manager.
Так от, базуючись на вище сказаному досвіді, хочу порадити всім починаючим, та й не тільки, в цій галузі:
➡️ всі книги та курси, прочитані на пройдені Вами, не варті нічого, якщо Ви не проживаєте проект та не любите роботу, яку робите;
➡️ ніякі тулзи для планування Вам не допоможуть, якщо Ви не вмієте планувати власний час;
➡️ працівники не будуть Вам підчинятися, якщо вони не мотивовані, якщо вони «відбувають» робочий час;
➡️ вміння управління людьми не для кожного, цього можна навчитися, але людей треба ЧУТИ;
➡️ гнучкість – це ОСНОВА в управлінні. Команда складається з різних, часто не схожих між собою, людей. В якщо Ви щей новачок чи тільки змінили проект та команду? Тому курс психології тут не завадить;
➡️ проект потрібно ЗНАТИ. Можна не вдаватися в деталі, але чітко розуміти хто і що робить і що буде, коли хтось чогось не зробить;
➡️ Project Manager завжди на стороні Development команди. Це не означає , що Ви завжди відповідаєте за всі «косяки», але Ви повинні скласти максимально комфорті умови для роботи, щоб ці «косяки» звести до мінімуму;
➡️ ризики – від них не застрахований НІХТО, помилки трапляються часто і ми тут для того, щоб їх вирішувати.
Намагалася донести досвід зі сторони підлеглого і висновки, які прийшли з таким досвідом. Вдячна за досвід всім моїм попереднім роботодавцям!
