Product Manager aka Product
If we compare it with the construction of a dacha, then the Product is the customer, the owner of the dacha. The Product’s task is to ensure that the system has a maximum of useful and necessary features for the user. To do this, he conducts user surveys, monitors metrics on how the new feature affected, for example, conversion, user churn, LTV. As one of my colleagues (a very good Product Manager) told me, my goal is to make the user happy, to give him what he really needs, and not what he thinks he needs. I think these are more like the words of a dreamer. Although, when I watched “Yandex Manager School,” there was an example of the behavior of a good Product that fits into this paradigm: A guy comes to a trainer and says that he wants to pump up. A bad product is like a coach who just starts training him. A good Product is a coach who will ask why he wants to pump up and if the client says that, for example, in order to protect himself, he will advise him to go to boxing or sambo instead of the gym.
Project Manager aka Project
Project Team Leader in a matrix structure. If you compare it with construction, this is a Foreman. If you compare it with the game and thus the raid in WoW, this is Raid Leader. A project is a time-limited event. They believe that each sprint is a mini-project with a set of goals. Project’s task is to ensure that tasks are evenly distributed among team members (in fact, he assigns them to them) and to ensure that the process within the team is followed. A taskmaster to describe his work in one word. Recruits and removes people from the team. Builds a plan, work schedule and Gantt charts according to the list of features and roadmap from Product so that Product understands approximately when a specific feature will be ready. In young teams, the idea is to optimize the process in order to improve it and write instructions for the process. In this company, all processes are already regulated and documented, so, in fact, all that remains is to monitor their compliance.
Business Analyst aka VA
Its purpose is to document what exactly the customer/product wants. What should be the feature that he wanted to add or what exactly and how should be changed in the old feature. VA writes technical specifications from the business side, how the user sees the system, roughly speaking technical specifications about the front. Technical specifications about how the system reacts to the user’s actions and how it interacts with him in general. A set of scenarios and alternative scenarios to them. Business technical specifications set if that. If the user has chosen a password shorter than 8 characters, then we show him a message – the password must be longer than 8 characters. If the user has chosen a password without capital letters, then we show the user an error – the password must contain capital letters. Usually this is also depicted graphically in the form of a tree of outcomes. BPMN diagrams.
Systems Analyst aka SA
Its purpose is to design and document the technical structure of a system. Often they also write what tables should be in the database. Which database to use. What is the data transfer protocol? What entities will be in the system (User, Book). TK from the system, TK from the developers, rudely speak TK about the back. Various UML diagrams are used here. Basically class diagrams with relationships between them like composition etc. The chief systems analyst of the team is called the System Architect.
Technical project manager. Decides which data transfer protocol to use, which database, which microservices to divide the project into and other technical issues. This is presented in the form of a technical specification for the system. In fact, the chief systems analyst of the project.
Roughly speaking, if we consider the Business Specification as a book, then the Designer here is an illustrator who makes illustrations for the Business Specification so that the developers can clearly see what exactly the customer (Product) wants to receive in the end. In the process, he thinks about how to display what is written in the Business Specification in a more beautiful (UI) and user-friendly (UX) way.
Frontend Developer aka Frontender
Here it must be said that all fronts, Web, Mobile and Desktop, have been combined into one group. The differences are in where the application is launched in the Browser, on iOS, on the Windows desktop, etc. According to the technical specifications and design, it implements a part of the system that is directly visible to the user and which runs on the user’s device. Decides which technical solutions at the code level and the final implementation to apply to implement the technical specifications. What library to use for localization, what code style, etc.
Backend Developer aka Backender.
According to the technical specifications and sometimes looking at the design, it implements part of the system that runs on servers. Just like the front-end developer decides what technical solutions at the code level and the final implementation to apply in order to implement the technical specifications. What library to use for localization, for working with the database, what code style, etc. only in the part of the system that works on the server side.
Automated testing specialist aka Auto Tester.
The main task of QA (quality department) is to check that the system works according to the specifications and design. They compare what is written in the technical specifications with what is actually done. Also, if they find some behavior that is not described in the technical specifications, they offer to include it there with a description of how the system should behave in this case. For example, show the user a message – “Ugh be like that! Don’t do that again!” Here we must make a reservation that QA in general is the one who is responsible for the quality of the product, aka the number of bugs. The higher the qualification level of QA and the more power they have, the higher the quality of the product, while also taking longer and being more expensive. Auto Testers write tests, test robots that imitate user behavior, press buttons, fill out forms and imitate the behavior of the frontend – make requests to the API. Usually these tests are run after system changes to check that the changes did not break anything.
Manual Testing Specialist aka Tester
Manually checks the front of the application as a user. He also writes manual testing scripts. Usually he is engaged in quickly testing new features or feature changes for functionality in order to find the most serious bugs. It also deals with the reproduction of bugs that were introduced a long time ago or that were reported by someone not from the QA department (the support department, for example). This is necessary to make sure that the bug still exists in the current version of the application.
Configures automatic assembly of artifacts and their deployment. Sets up stands. In general, it makes it so that the desired version of the back up on the desired server can be deployed or rolled back to the desired version with one click. Monitors servers and their metrics – network, processor and memory load. Sometimes, upon request, a new version is manually installed on a new server.