Some people say that “together in the lakeside blowing the night wind, will remember some longer”, that lived in the hospital, is it possible to imprint on my heart? Before they want to write an article to summarize their experience as a PM, long time alternative released this requirement, there is another demand to publish, a bit of time on the weekend, and want to sleep the lives, my lazy carcinoma is made: (abut again, I also is just a child ah, ahem, aunt to get to the point, so so, dragged on, until the last few days in the hospital.
Every time you finish a project or step out of a comfort zone, you need to review yourself, right? One is to take a systematic look at what you’ve done as an outsider, and the other is to give yourself something to look back on in the future that you might otherwise forget
The following is a summary of Bella Sauce’s experience as a PM at Ali
1. Project approval
Before you do a project, you need to know why you want to do this project, what is the value and significance of this project? If it’s a major upgrade to an existing version, you need to know exactly what the problems are, what the pain points are, how scalable it is, how maintainable it is, etc. At the same time, you should also determine the goal of the upgraded version. Only when the goal is determined, when the technology solution is selected, you will know which technology solution should be selected, because the technology solution you choose should be sufficient to achieve your goal.
For middle-Taiwan projects, there are two more issues to consider, namely compatibility and difference. The so-called difference, that is, the upgraded version can be seamlessly compatible with the new access to an industry? What is the cost of access? Can we entrust part of the access work to product or operation students to do, so as to liberate part of the labor force of technical students? The difference refers to whether the upgraded version can support the differences between different industries and whether it can be isolated from each other.
In general, I choose to use mind maps to express this information. Maps tend to be more concise and intuitive than words, and TL’s are more receptive.
2. Technical pre-research
The main purpose of this phase is based on a stage to determine the objectives, research what technology can support you achieve this goal, the technology can theoretically feasible most accurate into feasible on the ground, can take the current business scenario do a deduction and data, the data after deduction of ok, can do a small run the demo, To prove that the technology can really be used in this project.
In this stage, it is necessary to produce the data deduction diagram of each technology selection. If the deduction process is complicated, it may also be considered to produce another detailed Excel style data deduction diagram, and how the data changes in each step should be reflected. In addition, it is necessary to produce operational demo of each technology type. Finally, it is necessary to produce a comparison of various types of technology selection, which can be in the form of table or mind map, rather than pure text. Based on the above comparison, the final technology selection is determined, and then the technical solution can be written
3. Preparation of technical solutions
Private thought technical plan should contain the following sections, the business background, scene analysis, system architecture, application architecture, system flow chart, the domain model, storage model, global available definition, the function module design, interface definition, project milestones, and so on, if it is need to sea project, also need to consider the way of localization, time zone offset, deployment and so on.
3.1 Service Background
Business background mainly explains the background of this project, that is, why this project is done and what kind of business background it is based on. The mind map drawn in [1. Project approval] can also be directly placed in this PA.
3.2 Scenario Analysis
Scenario analysis is mainly about the application scenarios of the system, if you can list the true demands of the business side, it is the best. The life of most programmers, however, is not directly connected with the business side classmates, but with the product manager.
3.3 System Architecture
The system architecture is recommended to be presented in diagram form. Start with a picture, the rest depends on the talk, is not impossible ha. It happened to Bella Sauce, where I opened with a picture and watched the big boys talk for three hours or more. I admire it. That experience also taught me how important expression is. In general, I draw a system architecture diagram like this, focusing on what middleware is used, what data sources, what applications, what SPIs are open, how these components interact with each other, and ultimately what businesses can be supported.
3.4 Application Architecture
The application architecture is still recommended to be represented in the form of diagrams. I usually draw an application architecture diagram like this. The main focus is to show what modules an application consists of, what functions each module contains, the hierarchical relationship between modules, and which applications contain which modules. In addition, this diagram can also be used to draw which middleware, which data sources, which business scenarios supported, so that this diagram will be more complete, even without looking at the system architecture diagram, just look at this diagram, you can understand the design of the whole project.
3.5 System Flow Chart
The flow chart of the system is mainly flow chart, which can be supplemented by text description or table description. Because this is closely related to business logic, no examples are given here.
3.6 Domain model design
Domain model design, this stage is very necessary, first to determine the domain model, then to determine the storage model based on the domain model, not all domain models need to be converted to the storage model to save to the database. In the process of domain model design, the overall flow chart of the system should be very clear, and the system flow chart of the last stage can be combined to deduce whether the normal and correct operation of the system can be deduced according to these domain models. The diagrams, supplemented by the necessary text, illustrate how the domain model is designed to make the system work.
3.7 Storage Model Design
Storage model design, need to detail the design of each field in the table, field type, whether the primary key, whether to create an index, whether can be null, whether to be a sub-table field, and so on. Table structure design table display. Storage model design, or suggest the form of pictures, convenient to show the relationship between the tables.
3.8 Globally available definitions
Global available definition, mainly defines some general methods, enumeration classes, common conventions, etc., to avoid each application or each developer to define a set of their own methods, enumeration, etc., to ensure that the same field or the same method is unique in the system.
3.9 Function Module Design
The design of functional modules, that is, the detailed design of each module, should be as detailed as possible here. Some examples can be given to ensure that students responsible for the development of this module can read the documents to understand what to do and how to do it. If necessary, each module can be a detailed technical solution.
3.10 Interface Definition
The interface definition, well, I don’t want to explain much, but remember to write the incoming parameters, the outgoing parameters, the name of the interface, and remember to accept the incoming and outgoing parameters in a custom class, and don’t forget to implement serialization
Don’t forget BaseResult, isSuccess, getData, getErrorMessage, buildErrorResponse, and buildSuccessResp.
3.11 Project Milestones
Project milestones, i.e. the timing of the project, such as development time, commissioning time, lead-in time, release time, etc., are also the time to identify resources and ensure that relevant students can participate in the project within the time frame you have planned.
3.12 other
If your project needs to go offshore, you also need to consider how the system will be deployed, localization, time zone offset, middleware support, etc.
4. Project process control
Only a good plan, the project process control is not in place, ultimately can not deliver a satisfactory product. So how do you keep the project on schedule while still ensuring the quality of delivery?
As the owner of a project, you need to:
- Technical solutions should be feasible
- Identify the timing of the entire project, what measurable results should each phase deliver, the interconnectedness of each phase, and the impact of not delivering on time
- Identify what each person does, how long each thing takes to do, and what are the deliverables
- Whether it can be tested and verified by stages
- Identify the risks in the project and whether the risks can be controlled
- Big promote net, and upstream and downstream depend on these factors also want to consider
- Relevant personnel, such as testers, need to be locked in advance
In the case of action, consider the following:
- Each day will know everyone’s progress, risk points, need assistance points, etc
- Runnable single tests at all stages are required
- Review the code regularly (e.g., once a week), check the real progress, owner or owner& corresponding developer to attend
- Develop development specifications to ensure uniform code style
- Function separation as small as possible, a function point is best not more than 5 days, try to control within 3 days
- After the development of the overall self-test is ok, the overall code review of the project is carried out and the test is proposed
- After the code review is completed, the modified code should be subjected to the overall regression test. During the regression test, the code is not allowed to be modified except for bug problems
- Release to avoid big promote the closure of the network, before the release of the party to determine the release time point, see the release order has no requirements
Among them, you should focus on the risks in the project. No matter what the reasons are, whether caused by controllable or uncontrollable factors, the current situation deviates from the plan, all of them belong to the project risk, which should be thrown out as early as possible, and you should make sure that the people who want to see this risk see it as much as possible. Secondly, the risk is not just thrown out. We should also consider whether we can cover the risk and whether we need other people’s assistance. If so, we should bring it up as soon as possible. Finally, give as much time as possible to test. You never know what problems you might find during testing.
5. Deliverables
Lies not only in delivery lists to students to the product, let him check his proposed requirements we have achieved, also lies in our own a review of the program, in addition, the delivery list can give to test students a strongest king auxiliary role, contrast tester can know this project delivery list all functions, convenient they test. Therefore, the delivery list should be as detailed as possible and not conflict with TC
Mind map +Excel+ text is recommended.
6. Prepare for the release
Mainly some resources preparation, such as online server, online DB, online MQ and other middleware and resources preparation.
Second, replace the SNAPSHOT version binary package used in the project with the official version binary package. After the replacement, remember to regression test again.
In addition, we also need to determine the release time of the upstream and downstream companies. If this release depends on the release time of the upstream and downstream companies, we need to negotiate with them on the specific release time and determine the date, so that we can check whether they release it or not and decide whether we can release it.
Well, you can also write tools before you release that you can use to fix your online data if something goes wrong. A qualified data guard should not subscribe to DB directly, but should fix it through tools. The project goes live, and the corresponding tools go live.
Release 7.
During the release process, you need to look at various monitors to ensure that the release is ok before you can continue to release in a wide range.
Release completed, there should also be a wired test link to check the online functionality available.
At the same time, we need to follow up online monitoring, alarm and log for a few days to ensure that there are no problems before the release is successfully completed.
8. Checking
A personal review is a must, for reasons I won’t go into. You foreign share/checking refers not to preach, and so on the checking, but for you the real inner you checking, in this project yourself whether you ever grow up, grow up what, what place do well, what do bad, bad place can avoid or solve next time, this project have any stray from your original intention, and so on.
The above is a summary of Bella Jiang’s experience as a PM in Ali. Maybe you who are reading this article have experienced a project course that does not match the above process completely. Maybe it is the team’s habit or the fast pace of the project, etc. Please leave me a message in the background or add me on wechat. Tell me about your current project experience.
The nuggets essay | 2020 years and I summarize the campaign is under way…