Experience sharing of a newcomer in project management (1)

I recently switched jobs, and did several interviews with project managers. I saw another , so I had the urge to write this article.

I graduated in 10 years, and then did 2 years of development (in fact, there are still 8 months of internship, this is not counted) almost 2 years of project management experience, I also sorted out some of my gains, some places may be ideal If there is anything wrong or wrong, I hope someone can correct me!


1. Demand source or mining

  For the development team, there should be only one source of demand, that is, demand engineers (many unprofessional product managers are also the work of demand engineers, and some are directly project managers to talk about demand, here is unified as Demand engineer), I have also seen cases where customers call our developers directly. At this time, we also ask developers to listen to what customers want, but don’t promise users whether to implement them or not, answer the question. After arriving on the phone, understand what the user wants, and then reflect it to the project manager and requirements engineer, and the requirements engineer will contact the customer again to understand the requirements.


  Before, our team has been complaining that the demand is changing, and the order has been changed day by day. We have also been complaining that the demand engineer is just a messenger, and the only function is to collect the requirements of all parties! This is not the user's problem. It is possible that the user himself does not understand it. At this time, a requirements engineer needs to understand the business, dig deep into what the user really wants, and then decide how the entire system needs to be implemented. This is actually a process of turning passive into active.

And even if you dig deeper, there is a high possibility that you will still not be able to truly understand what users want. At this time, you have to embrace change. That’s why we switched from waterfall development to agile development.

I read a book "Are Your Lights On", and there is a very interesting quote in it: No matter how it looks, people rarely know what they want until you give them what they want. , which is also one of the reasons why we switched to agile, through rapid iteration to produce results, after giving the user something, let him know more about what he wants!

2. Project manager and requirements

Before talking about agile, let’s explain our team. Our team is a relatively mature team, with 5 developers, 3 testers, and 1 requirements engineer. Development and testing are all 2-3 years of cooperation The people who come here are familiar with each other, and the department managers are advocates of agile.

Before the requirements are formally incorporated, the requirements engineer and the project manager should first discuss the requirements (if possible, the project manager should also participate in the process of requirements collection, and a step back can also be a key meeting of requirements collection) to understand the information of the requirements , to understand the following points of a demand function:

1. Who is the user of the function? who
2. What kind of problem is the essential intention of the function to solve? why
3. What is the main content of the function and what are the key fields? what

Here, there is no need to discuss how the function is implemented in detail, but to ensure that the project manager has a clear and thorough understanding of the business, whether there is a demand that can be replaced by a better way, and whether the demand engineer considers whether there are any deficiencies.

PS: If the project manager plays the role of a requirements engineer, then the above 3 Ws should still be fulfilled, because the project manager directly faces the developers. Whether the project manager understands the business is very important in the entire development. .


3. Developers and requirements


The next step is the agile planning meeting process, in which the requirements engineer announces the requirements to the developers, and prioritizes the requirements. If the developers have any questions, they can ask them at the meeting. If it can be better The solution is the best!


The first thing to be clear here is that only the determined requirements are made at the iteration meeting. What needs to be guaranteed is that the requirements are clear at this meeting, and try to ensure that they will not change within three weeks (for the Changes in requirements or the emergence of congestion during the iteration cycle, which will be discussed later), there is another point to make it clear that the requirements should remain unchanged within the iteration cycle as much as possible, and the support of the external environment, such as the decision-making level, they must have a consensus and adopt the iterative method. The smallest unit of mode! Even if there is a change, try to implement or change it in the next iteration. If there is no consensus, then the project manager or department manager needs to go to public relations to clearly explain the advantages and disadvantages of the iteration.

Take our company as an example, in the initial project process, we did not adopt agile, so we experienced a lot of pain: requirements came one after another, developers were dying to work, but after making something, users found that it was not what they wanted , and then all the previous work was done all over again in vain, and a lot of functions caused each launch to be like fighting a war, each time it was a big upgrade, and it was often encountered after deployment! In such a case, the leaders can easily accept the agility proposed by our department managers (of course, the specific public relations are certainly not so simple).

After developers clarify the requirements, it is actually the most troublesome to estimate the labor hours of each function. Our current approach is
to split the functions and split each large function point into the smallest execution unit. The smallest execution unit refers to the functional modules that can be estimated. Generally, about 2 days is the best, and no more than 3 days at most. If it is found that there are function points that exceed 4 days, continue to disassemble until it is disassembled into 1-3 day's situation. Another benefit of splitting functional modules is that it helps developers better understand and design requirements. Because it is a function split with full participation, everyone has a clear understanding of each module, which is conducive to the next schedule and risk management!

------GeggieGeggie---------
Lunch break, dinner