# Working as a Product Manager in Brilltek
First of all, if you are reading this, welcome to our team. You must be wondering what are the roles of a ==Product Manager== in the office.
Through this documentation, I'll guide you and explain to you all you need to know.
The PM will come across a wide variety of different tasks in its journey, but we can split the job in different steps:
- Step 1 : Get to know the project details
- Step 2 : Make the project's roadmap (Gantt)
- Step 3 : Follow your roadmap's sprints with Jira
- Step 4 : Test devs work on GitLab
- Step 5 : Make sure deadlines are followed
## Step 1 : Get to know the project details
Before starting to work on any project, you have to make sure that you understand all the details. Thus, you should be able to answer any question from your team regarding the purpose of the project, the expected outcome, the deadline etc...
Here is a list of things you should **always** ask and make sure to understand before starting any project.
1. ==The client==
2. ==The type of project==
3. ==The purpose of the project==
4. ==The deadline==
5. ==Project's milestones==
6. ==The team==
:::info
if you are not sure about one of these, don't hesitate to ask, it is really important to knonw these in the first place.
:::
*Why those informations are important ?*
- **The client**: If you already worked with the same client in the past, there are some things that could be expected and therefore it is important for the devs or even for you as a PM to remember (example : how long before each milestones ?, is the time of the project flexible ? or any other technical questions)
- **The type of project**: Does the client wants a PWA project ? a B2B project ? B2C project ? It is important to know because depending on the targeted users, your ==Quality Assurance== (QA) will be different. As an example, if a project is B2B and the deadline is getting closer, you may focus more on the output, to show something to the client on time, even if that mean to not focus too much on the QA. In the contrary, if a project is B2C, the QA is the most important. We can't be late. Also, note that a project could be split in 3 types (APP, API, PAGE) at once.
- **The purpose of the project**: To be able to manage a project properly, you need to be able to understand the purpose of the project, what it is and for who it is. That will ensure a better understanding by your teams on the work they are providing and it's always a good way to encourage them.
- **The deadline**: Obviously the deadline is the most important of it all. You have to work around it manage your time efficiently to be able to finish before the deadline.
`Note: Remember to keep one or two weeks at the end of each project for testing and bug fixing.`
- **Project's milestones**: Depending on the client you'll be working for, it is possible that they want to keep an eye on the project's progress during the development time once in a while (for example, it could be a milestone every month). You have to determine milestones that will fulfill the client's satisfaction.
(finish a feature, finish a userstory etc...).
- **The team**: By knowing the team of devs you will be working with, you may have a better idea on how to split work efficiently in different sprints, thus be able to reach the deadline with a complete project.
## Step 2 : Make the project's roadmap (Gantt)
After gathering all the informations about the project, you can use them to create a project's roadmap.
***The project's roadmap is the key to keep track of the project's progress.***
If you want more information about project roadmaps, you may click [here](https://toggl.com/blog/what-is-a-project-roadmap).
:::info
The project's roadmap should be the first thing to do after gathering the informations.
:::
By now, we already know the deadline, and we also know the team of devs and the project type. So we may start thinking about how to split the work in sprints among everyone from the start of the project to the deadline.
### The Roadmap example
#### Split the work
For my example, the project is split in 3 different types (APP, API and PAGE).
I splitted the work by one week sprint. Make sure API, APP and PAGE don't end their sprint on the same day. It is important to **not** have all the pre-sprint meeting on the same day. in my example, API sprint is on tuesday, PAGE on wednesday and APP on thursday.

#### Sprint to-do list
You may estimate the main features to be done for each sprint. You may give a name for each of your sprint if you want.

#### What if the work is late ?
If the work estimated in a sprint is not done after the end of the week, the sprint becomes red, and the unfinished tasks in the original sprint shows in red.


#### Keep in mind
You may include the milestones, the actual day we are (purple column), and the deadline.

---
By doing this roadmap, you will be able to tell how much time is remaining before the end of the project, or if there are any late sprints.
It is hard to **estimate** the work to be done for each sprint as you may not know how long a task may last for. That's the reason why before each sprint, every week **you will have a meeting with your team** to discuss about the upcoming sprint. This is to make sure that everyone understands the progress of the project and what we can do to improve it, or make it more viable.
## Step 3 : Follow your roadmap's sprints with Jira
**Jira** is an issues management and bug tracking software used in agile project management teams. If you have never heard of it, you may check [here](https://www.youtube.com/watch?v=GWxMTvRGIpc&ab_channel=StewartGauld).
**Brilltek** already have its own Jira workflow implemented, so you may check this in the ==project management== official [documentation](https://docs.brilltek.com.tw/project_management/global_view/).
We also have implemented a way to write Jira cards, so you can check that [here](https://docs.brilltek.com.tw/project_management/jira/).
:::info
Jira will be the biggest part of your work.
:::
***You are responsible for creating, editing and keep track of EVERY Jira issue of the project ! You are also responsible for all the testings in the project.***
Jira cards have deadlines, and you can put cards in sprints. So during the sprint, when the developer finishes a card, and then change it to the "UI Test" or "Testing" column, you will have to start testing it.
### The Jira example
#### The backlog
This is the backlog of your Jira issues. From here you can see all the cards that are currently not in any sprint. You can also create cards directly from there. As you can see, you can create Story, Task and Bug.([Reference](https://docs.brilltek.com.tw/project_management/jira/))
:::info
If you want to create a sprint, you may click the button on the top right corner.
:::

#### The sprint preparation
Once you created your sprint, you can drag all the needed issues from the backlog to your sprint.
After checking that all the issues you need are there, you may start your sprint.(button on the top right corner)
`Note: you need to complete a sprint first before starting another one. `

#### The sprint (Kanban look)
After starting your sprint, you may switch the view to have an overview of each card status, who is working on it etc...
If you followed the [documentation](https://docs.brilltek.com.tw/project_management/global_view/), you should have something that look like this :

If you don't have the same columns showing, you may click on the **"Board"** button on the top right and click on **"configure"**.
There will be a **"columns"** section where you can add and remove columns to make it look like mine.
You may also play around other settings to have something custom.
***When a card is in ==UI Test== or ==Testing==, you should be reviewing it. You are responsible for the QA.***
#### Card description
This is a card description, when writing a Jira card, you don't have to assign it to anyone, devs should be assigning cards to themselves (by clicking on the **"assign to me"** button) when they are starting working on it.
There are different ways of creating Jira issues, you may refer to the official [documentation](https://docs.brilltek.com.tw/project_management/jira/).

#### Workflow
This is a recap of the workflow from the [documentation](https://docs.brilltek.com.tw/project_management/global_view/).
`Note : The UI Test column is only there for projects using Storybook.`
1. Devs will take a card from **"TO DO"**, move it to **"IN PROGRESS"** when they start working on it and finally move it to **"UI TEST"** when they finish.
2. Then it's your job to review the work, and if it is wrong, you add a comment to the card, and put back the card to **"TO DO"**. If the work is good, you comment by saying "UI Test ok" and move the card to card review.
3. The tech lead will then review the code and merge the branch to the develop environment, or put the card back to **"TO DO"** if its wrong.
4. Then its your job again to test the work, but on the dev environment this time. same as before if good we put in **"TO DEPLOY"**, if not good, we put back in **"TO DO"**

*This is an example of comments on a card.*
:::warning
It is important to keep track and make sure all your Jira cards are correct. Or it may create chaotic working environment for everyone !
:::
:::info
if a developer doesn't assign its card or does not follow the workflow, you are responsible for telling him to change, to make it clean and tidy for everyone.
:::
## Step 4 : Test devs work2
You may want to know how to test devs work. It is actually pretty simple, especially if you have a clear understanding of the project design, and the expected features that needs to be done.
There are 2 type of testings :
- ==UI test==
- ==Testing==
*What does it mean ?*
- **UI Test**: This is to make sure the UI is looking the same as the Figma file. This process is only for front-end project using [Storybook](https://storybook.js.org/).
- **Testing**: This testing is for all types of project (APP, API, PAGE). It is to ensure the features are working properly before we send it to the client.
*How to test ?*
### UI Test
When a Jira issue got moved to UI Test, it means that you have a project working with [Storybook](https://storybook.js.org/). So you'll need two things.
- Figma file to use for reference (UI/UX)
- Build storybook
Storybook is a tool that is used to make testing more simple. It is regrouping all the different UI components made by branch for front-end. We will need to access this storybook to start testing.
Go to the "**CI/CD**" section of Gitlab, you will see a list of what we call *pipelines*. you can filter pipeline with the name of the branch (Usually developer will name the branch same as Jira issue). Then you can click on the most recent *passed* pipeline.
When clicking on the ==build== stage, you should be able to see the build-storybook.

You will see this. To continue, click on the "Browse" button on the right hand side.

Clik on it and continue by clicking again on storybook-static.

Then look for the index.html and click again

Congratulations ! You can see the storybook, you may start reviewing the UI, and make sure everything looks the same as the [Figma](https://www.figma.com/).

### Testing
For some projects, you may not have a UI Test column in your Jira, because the project may not be using Storybook.
Therefore if you wanna test, you will have to go check the work in the dev environment. Every dev environment should have a url similar to
>*dev.projectname.domainname*
>example : https://dev.crm.fcs.brtest.club/
To find the right link for the project, you may find it in the **wiki** section of GitLab.
:::info
Reminder : When a Jira card is in Testing, you must not only test the UI but also the functionality of the feature and make sure no bugs are showing.
:::
---
After all your testings are done, keep your Jira updated and move on.
## Step 5 : Important things
- You must have a meeting before each start of the sprint and write it with your team.
- Sprints must start on different days for better time management.
- Deadlines must be respected. If a deadline is almost to be reached, notify the developer to finish it in priority.