This paper mainly summarizes some experiences about “how to evaluate the demand and how to better complete the demand review to facilitate the effective development of the follow-up work”. First of all, the requirements described in this article sometimes refer to something that a group of people will accomplish over a period of time, close to the concept of a project, sometimes refer to a requirements document, and sometimes refer to a user’s requirements. Because this topic is too broad and abstract, I can only give some partial views based on my limited personal experience, so as to satisfy the universality as far as possible, which is bound to be one-sidedness. Follow-up work while supplementing and adjusting.
Lead analysis
To grasp the core
Each requirement has a limited number of core problems to solve/core goals to achieve, usually 1 core goal (there may be multiple sub-goals), or preferably only 1 core goal.
To grasp the core is to answer: what problem should be solved? Whose problem is it to solve? What is the solution (to achieve/to achieve)?
Note that the core does not include the question of how, because how is just the means, and the means can be many and varied.
A qualified requirements document should clearly answer these three questions from the outset. It is best to have a background description or a specific user scenario. Generally speaking, the user scenario of C-end products is easy to understand, because we are the users ourselves, but the user scenario of B-end products is not so easy to understand, for example, how the pricing process of a product has gone through. If we do not know the specific work of offline operation personnel, it is impossible to truly understand the demand.
A lot of times with development, “whose problem to solve” is a problem that’s okay if it’s ignored, because it’s so rarely wrong that it usually is. But sometimes if you do get it wrong, the subsequent design can go in the wrong direction. For example, I once worked on a CRM project, which was mainly used to record customer information and business negotiation progress information. At the beginning, everyone thought this tool was for business to facilitate their work record and customer management, but actually this tool was for the boss, so that the boss could track project progress and manage business performance. Business itself does not have any motivation and demand, go to CRM to fill in those information, people just take a small notebook can remember, why use this system, outside business trip also have to connect to the VPN to access the Intranet application, how troublesome. Therefore, the system is not a business assistant, but a management tool. In the system design, the role should be divided (boss/business, the role of the boss is also divided into two layers, general manager and regional manager). If “each user can only see their own editing content”, it will be completely destroyed.
Assess the need
Figure out what needs to be done and ask why right away.
A sign of losing the ability to think is to take things for granted too easily. It seems that what is in front of us is natural and reasonable, and it only needs to be understood, absorbed and appreciated, rather than questioned, reconsidered or even overturned.
The basic premise of doing anything is necessity. Is there any need to solve this problem? Why are we doing this? Think of the cause first, not the effect. If the reason is not valid or insufficient, it can be refused.
Strategizing can be used with “bumpers” thinking:
- Whenever something needs to be done, you ask: What happens if you don’t do it?
- Whenever there’s optimization, you ask: What’s wrong with the status quo?
Evaluation rationality
Rationality is divided into two aspects, one is the rationality of the goal, the other is the rationality of the solution. Objective rationality is the premise of program rationality.
Necessity is the recognition that “this is a problem, and this is a problem that needs to be solved,” and the goal is “how to solve it.”
The rationality of goals comes not only from themselves, but also from many external factors, such as organizational capabilities and environmental conditions. However, in our daily needs, we basically do not consider “whether we will do it or not”, nor do we pay attention to conditions such as “market conditions are not mature and restricted by the level of economic development”. In external factors, we mainly focus on the rationality of procedures, and need to be alert to the requirements of illegal procedures. For example, one-sentence requirements without requirements documentation, requirements raised by non-product roles, and requirements raised separately by bypassing your leader, etc.
The rationality of the goal itself, the general direction comes from the degree of fitting with the stage or long-term large goal, and the small direction comes from the investment return ratio. There is no deviation in the general direction, and there is profit in the small direction, which is reasonable.
The pursuit of sound goals is demonstrable beforehand and measurable afterwards. Either it can be logically confirmed from the product architecture that this capability must exist, or it can be measured by metrics and criteria. Functional class needs mainly see the former, experience class and operation class needs mainly see the latter. Measurable requirements that are not logically certain are particularly important, especially when exploring experimental requirements (which are more common in the early stages of business development or in innovative businesses), and there must be metrics to support or validate the original assumptions.
“Alignment with friends” can be the motivation for a demand, but not the reason for it.
“The boss made the request.” It doesn’t need a reason.
The reasonableness of the scheme will be discussed later.
“Battle”
Who will do
The basic premise of figuring out who will do it is to define the scope of responsibility, and the boundaries of responsibility for each team need to be clarified. The boundary is often less clear at certain times, such as when business at a large factory is booming.
For workers, most of what falls to them needs to be done by themselves, which results in a lack of sufficient sample training to form a sense of who will do it. In fact, not everything needs to be done by yourself. Here’s an example:
When a dependent public service is upgraded, the front-end needs to cooperate with the upgrade. During the upgrade process, it is found that there is a logic to receive notifications originally, but after the upgrade, the service does not provide notifications to the front end but only to the back end, resulting in the failure of existing functions. The reason given by the server is that the security group considers the original method of sending notifications to the front end using cookies to be risky. At present, there are three schemes: first, from the code logic, the front end can realize the effect of notification in another way, with a certain momentum; Second, let the back end step in and provide the interface. Third, in consultation, the development of the service provided a backdoor notification method that could not be exposed on the document. What should I do?
Different styles of front-end may have different tendencies:
- Honest + irresponsible => Plan three
- Honest + responsible + confident in your technical ability => Plan 1
- Honest + responsible + no confidence in your technical ability => Plan two
However, if we take a look at this issue again, the solution will change: The public service upgrade, breaking change happened, but the service party neither clearly explained nor provided a preparatory plan, obviously the responsible party is the public service side. On the other hand, you can’t have 10 dependent parties each dealing with this situation. So the right approach is to promote the service side to do compatibility, personal push can not move, pull the product push together.
If a task involves multiple teams, the division of labor is often a problem. After all, if there is no obvious payoff, no one will fight to do it, and if you do less, I will do more. The most common is the dispute over the border between the front and back ends. Such matters, if not negotiated, often require an authoritative “dictator” to make the final decision. If everyone is doing their job, there can be a consensus in principle that “doing the right thing” is the right thing to do, but there are likely to be disagreements about what is right because of where we stand, and not everyone is doing their job (or even what is considered and what is considered to be the right thing to do). This requires policymakers to think clearly about what is the right course of action on a case-by-case basis, so as to be persuasive and ensure fairness.
However, the boss often said, do not have a sense of boundaries and domain awareness, does that mean that caring about who to do the problem is very narrow and suspected of evading? No, because figuring out who’s going to do it is really about figuring out what’s the right thing to do.
Why do it now?
All products want demand to come online right away, but the reality is that resources are always limited, so prioritize. If you find that all requirements are at the highest level for a certain period of time, you can tell that requirements management within the product is completely out of order. So, in many cases, friendly negotiations are also needed.
summary
One of the most common directional mistakes technicians make is to get bogged down in a specific solution to the requirements, or even start thinking about the technical solution design while reading the documentation. The problem with this is that the default requirements need to be done, need to be done, need to be done now, and have reasonable goals, which may not always be true. However, when the requirements are assigned to specific people, they have already been evaluated and screened by managers, so it is usually ok for the executor to only care about what to do. However, if the pre-assessment process allows managers to think instead, it means that they have given up the corresponding exercise opportunities.
For managers, because resource allocation is involved, they have to pay attention to the priority of requirements, and have to evaluate the objectives and ROE of requirements, and finally reach the judgment of importance and urgency. To reach a correct judgment, it is necessary to have an accurate and profound grasp of business objectives and strategies. So it’s easier to develop a whole set of analytical skills and a better understanding of the business than people who just do the work.
Careful observation will find that a prominent feature of managers’ working thinking is goal-oriented, specifically, goal-results-oriented thinking driven by problem consciousness. Managers and leaders must be strong goal-results-oriented people, because goals and results are the primary, and means are secondary. The boss, in particular, even cares about what needs to be done, and then provides resources to find the right person to do it. He doesn’t get involved in [how] until he has to, or he only gets involved in [how] where others can’t or can’t do it well.
How is very important to a worker, but attention should be paid to what and why first. Otherwise, the sense of purpose is often poor, a prominent performance, is easy to confuse the goal and means. For example, “Complete the form abstraction design and put it into use.” Is that a goal? It’s not an end. It’s a means. “Improving b-side development efficiency” is the goal, and more specifically, what status/metrics will be achieved at what point in time.
Project analysis
The rationality of the scheme is established in many dimensions. The more problems you can “anticipate,” the better your ability to assess needs.
generality
The universality of the scheme depends on the ability to abstract and anticipate future changes. Not being generic often means that every change has an input cost to implement. A good commonality of the scheme can save a lot of manpower. For example, a common front-end business scenario is to configure a variety of static data, such as various announcements, various instructions, various banners, various guidance prompts, etc., and these static information is often displayed under certain conditions, such as the specified period of display, not displayed or only displayed x times. In addition, different objects are differentiated to display different contents, such as app types, cities, new and old customers, and even access to the user portrait system for fine-grained differentiation. How to design a system to solve the similar configuration requirements once and for all?
complexity
If a solution looks complicated, especially if the problem seems less complicated and the benefits and goals are not that large, the solution looks suspicious. Because the cost is too high, it’s not worth it.
Complexity can be the result of over-design: accommodating future changes ahead of time in the pursuit of generality. The basic way to measure overdesign is to look at the likelihood of future changes and the cost of dealing with them once they occur.
contrast
There are two comparison methods: one is “what would I do if I were in the position of design”; the other is “make a horizontal comparison to see how similar products are done”. In essence, both are to find alternative solutions for comparison. Never assume that the solution of the product is the optimal solution, after all, one’s ideas always have limitations, if one focuses on the solution of the product itself, it may fall into the trap, because the wrong solution will also have the “right” design. It is best to think again according to the method, and strive to supplement and improve the scheme from the technical point of view, and even give a better solution.
Effective experience
Effective experience comes from classifying and modeling requirements, and it is easy to see the problem when it comes to similar requirements. What are the types of requirements for front-end business development? What should be paid attention to in each category? For example, when displaying a list, it is necessary to consider: loading state, empty data state, abnormal state, paging loading, pull-up/pull-down refresh, loaded all information, sorting rules, filtering mechanism, and possibly grouping, deleting, and going back to the top.
Full link logical deduction
One way to find deeper problems is to do fine-grained logical reasoning throughout the process. Under various conditions, according to the requirements of the scheme design, step by step from beginning to end, will not encounter unclear, missing, invalid or even contradictory, conflicting business logic. This is a bit too much to ask, since most of the time it is the technical difficulties of implementing the logic that have been specifically developed that expose the problem of the requirement solution. This is a good thing to do when QA is writing use cases, which take into account both the overall functionality and core flow, as well as extreme conditions and edge scenarios. In theory, mine clearance can be done ahead of time, but it depends on the person.
Progress is expected
Loss of progress will have different consequences. The model of small iterations in the agile development of the Internet industry generally does not lead to a large loss of control, while the impact of small loss of control is usually limited. But in the case of mobile phone manufacturing, the consequences of losing control can be fatal, such as falling behind on production capacity and delayed delivery, which means losing the money you should have made to your friends.
Macro schedule management is to coordinate the whole system, such as the r&d and production process management of a mobile phone. This article deals only with progress management at the micro level, down to the smallest project unit, such as a requirement.
Microscopic progress management can be transformed into such a problem: under the given parameters, how to predict the evolution process of subsequent events, so as to obtain stable expectations for the timely realization of achievements at each stage?
For example, given the following parameters: novice responsibility + veteran assistance + unfamiliar system + simple requirements + an important project with a Deadline, is there any risk of delay? The key variable, as an experienced observer might see, is conscientiousness.
Most of the people working on the project don’t care much about the project schedule, after all, what does it matter to “me” when it goes live? As long as “I” on time. But sometimes it does matter. For example, as the front end, you finish the development first and wait for the back-end to coordinate, but for various reasons, there are no resources involved in the development of the back end, dragging the need to be abandoned, then it is useless. For example, if the back end comes online very late, do you have to wait until midnight? After all, most of the time the back end comes online, the front end comes online, and then you have to come back.
Even if the schedule risk of the project is not concerned, individual scheduling needs to pay attention to schedule risk.
Often the risk comes from the dependent party. One of the biggest challenges for electronics manufacturers, for example, is supply chain management, which is why Tim Cook is apple’s CEO. Generally, I have a good understanding of the capability range of my own party (including familiar partners), so my expectation is relatively stable. However, for third-party services and unfamiliar partners, it is difficult to obtain a stable progress expectation because of information asymmetry and various uncontrollable risks.
For example, there is such a demand, a module other departments need to request an online interface, looks very simple, should do not have what problem, after all the online interface must be stable operation, but in fact may consume quite a lot of time on the third-party interface, with all kinds of problems will emerge: interface document? If not, where can I see the parameters and return data of this interface? Is the interface documentation up to date? If it’s not up to date, can you find someone to consult if you have a problem? Can this person be found in time? Will I miss it when I watch it? Does the interface support cross-domain? If not, can you find someone to support cross-domain configuration in time? Will the person be configured cross-domain once found? After matching, can we go online before we go online? How much traffic is expected to increase after we go live? Will it affect the server of the other party? If something goes wrong, who does it go to?
If you can’t figure out all the dependencies and whether they’re available and in place in a timely manner, scheduling is unreliable. There is likely to be a lot of time spent on technical research or debugging with partners.
For non-urgent needs, some idiot-oriented development may have the idea that if something is easy to do, it can be done without being rushed, there is no need to give it time, there is no need to schedule it, is it too big of a task to schedule it? This style of work is easy to lead to the time arrangement out of control, one is easy to attract a variety of convenient small needs to plug, the other is not clear agreed time point, in essence is to avoid the responsibility of delay, the result is easy to delay.
Therefore, a clear time is essential, even if it is not clear at the moment, also want to give a time that can give a clear time.