Що робити коли ти лише прийшов на існуючий проєкт
Всім привіт!
Захотілось підняти це, на перший погляд, просте, проте дуже цікаве питання. Адже зазвичай спеціалісти дуже хвилюються коли приходять на нову роботу або новий проєкт, і забігаючи наперед це нормально — головне мати алгоритм дій, для того аби «увійти» у проєкт якомога легше.
Я сама неодноразово була у такій ситуації і всередині компанії (без зміни роботи) і коли вже безпосередньо змінювала роботу і хочу поділитись своїми порадами, що робити, коли Ви приходите у вже існуючий, проте новий для Вас проєкт і Вам необхідно розібратись зі всім якомога швидше!
Отож, почнімо!
1️⃣ Знайомство з командою та документ відповідальних.
Після знайомства з командою, створіть документ, у якому запишіть імена своїх колег та навпроти вкажіть з якого питання до них можна звертатись.
Це допоможе швидко вирішувати проблеми та звертатись до потрібних людей, не «дьоргаючи» інших.
Ви можете запитати цю інформацію у ліда, ментора, ПМ-а чи іншу відповідальну за Ваш онбординг особу.
2️⃣ Налаштуйте робоче середовище та отримайте всі необхідні доступи.
Переконайтесь, що у Вас є доступ до всіх необхідних робочих інструментів, таких як Jira, Zephyr, GitLab і тд., тестових середовищ, баз даних та інших сервісів.
Адже без цього Ви не зможете навіть ознайомитись з документацією.
3️⃣ Ознайомтесь із документацією.
Наступне, що варто зробити після отримання доступів — це детально ознайомитись із документацією проєкту.
В ідеалі там має бути все: опис фіч, бізнес-логіки, API-ендпоінти, опис архітектури тощо.
Проте...то в ідеальному світі)
Часто буває що документація відсутня або застаріла, то ж це буде поінтом для Вашої подальшої роботи: зробіть це однією зі своїх перших ініціатив — розбирайтесь, уточнюйте у команди деталі та оновлюйте/пишіть документацію самостійно.
Це допоможе Вам краще зрозуміти систему, закласти фундамент для якісного тестування та принести користь проєкту і команді.
4️⃣ Інформаційний мітинг.
Влаштуйте мітинг, на якому зберіть девелоперів (або хоча б тех. ліда), дизайнера, ПМ-а, та інших членів команди за потреби.
Попросіть аби кожен з них розповів Вам все, що є важливим у його зоні відповідальності щодо проєкту.
Звісно краще все ж підготувати список питань, які Вас цікавлять, аби оптимізувати витрату часу на мітингу та уникнути інформації, яка на даному етапі Вам не знадобиться.
P.S. саме тому, я раджу ознайомитись з документацією перед мітингом. Це допомагає сформувати список питань краще та більш конкретно.
А також, якщо все ж доведеться оновлювати чи писати доку з 0 — то це чудовий спосіб скласти собі план, в залежності від тої інформації яку Ви отримаєте на мітингу.
5️⃣ Ознайомиесь з процесами тестування в команді.
Дізнайтеся, як відбувається створення тест-кейсів, тестування та баг-трекінг на проєкті. Чи використовується автоматизація тестування, чи є стратегія тестування і яка, де та як зберігаються тестові артефакти і тд.
Розуміння цих, на перший погляд дрібниць, допоможе Вам швидше включитися в роботу та уникнути небажаних помилок.
6️⃣ Оцініть якість тестів та продукту.
Знайомлячись з документацією та процесами тестування Ви 100% будете вдаватись до аналізу.
То ж гарним поінтом може бути оцінка наявних тест-кейсів, оцінка покриття продукту тестами і тд.
Це дозволить Вам зрозуміти, де є потенційні ризики та зони для покращення.
7️⃣ Почніть з найпростішого.
Як би це не звучало, та ніхто Вам не довірить тестування критичних задач на перших тижнях роботи...
То ж, виконуйте невеликі задачі поступово, це допоможе краще розібратись у продукті та швидше увійти в ритм команди.
8️⃣ Комунікуйте та питайте.
Мені здається це найважливіша порада зі всіх💪🏼
Не бійтеся задавати запитання!
Краще уточнити одразу, ніж робити припущення, які можуть виявитись неправильними. Комунікація — це основа Вашого швидкого онбордингу у проєкт.
А чи є у Вас якісь свої лайфхаки/поради/алгоритми які допоможуть у перші робочі дні?
Поділіться!
2 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів