1. Write in front
One of the important considerations in Goose Factory's ability requirements for product managers is called technical understanding. The so-called technical comprehension is not for product managers to learn to read codes, but for communication, requirements, and project advancement, to keep the way of thinking basically synchronized with technical personnel. How should this be understood? Let us explain it in detail from the perspective of a requirements process.
There are many sources of demand: user research, feedback, product innovation, upgrades, iterations, operations, market analysis, benchmarking of competing products, and even the needs of bosses, etc., are numerous and countless. In the traditional sense, the product manager abstracts product characteristics based on demand characteristics, thinks about product logic, formulates product goals, visions, implementation plans, draws up detailed documents, and follows the process of interaction-design-refactoring-front-background development-test acceptance and launch , step by step. However, in the process that seems reasonable and is taken for granted by most product managers, there are serious bugs hidden in the technical understanding level.
2. Understanding of software design
As we all know, software development and design can be divided into "process-oriented" and "object-oriented". Although the two methods are inextricably linked, there is a big difference in the way of thinking:
- Process-oriented refers to software design centered on tasks/events.
- Object-oriented refers to software design centered on things.
Let’s take a simple example where a user wants to take the subway from station T to station F:
If a process-oriented design method is used, a series of actions such as subway start-up, operation, and station arrival will be set as a process, and a process of subway maintenance may also be set. Then all these processes are logically connected together to complete a task.
If you design in an object-oriented way, then directly define the subway as an object, and the color and shape of the subway are attributes. The operation and arrival of the subway are the methods of the subway, that is, the behavior of the subway, not the process.
Referring to the way of software design, product managers also have similar differences in thinking when thinking about requirements, abstract product features and logic:
- Sometimes too much attention is paid to how the product implements each step, and it is difficult to describe the overall situation of the product, grasp the classification of users, and understand the goals of each type of user; sometimes, if it is object-oriented, it may complicate simple logic. In the absence of a clear way of thinking, whether it is product PRD, interaction or development communication, differences may arise.
- In order to achieve a reasonable technical understanding, it is necessary to consider which way of thinking to use in the demand thinking process. In particular, it is necessary to communicate with technical personnel in advance, and to adjust the way both parties think about product requirements, whether it needs to be process-oriented or object-oriented. .
- On the basis of communication, continue to design the product in detail: clarify product user classification, the goals and behavior paths of each type of user, so as to clarify product characteristics and logic. According to the situation of each type of user, draw up a series of required instructions such as the corresponding process, timing, and interaction, and then submit it for technical development. Such a synchronous way of thinking between products and technologies, I believe, can avoid many problems when converting requirements design into software design.
3. Understanding the implementation of requirements
Many product managers have said this: This requirement is very simple, just change it casually. Of course, this is also one of the most disliked words of technical students, and I am no exception. I once sneered at the technical staff because of the graphic modification of a simple page. It involves css, json, database reading modification and adjustment of data fields. Therefore, for the understanding of requirements, from the perspective of product managers and technicians, the size and scope they see may be like an iceberg, and there is a big difference between the surface of the water and the bottom of the water.
In the case where the technical level changes are greater than the product expectations, differences will inevitably arise. In order to try to make the implementation of requirements understandable and synchronized, the following elements can be referred to:
- Participate in the general design review of technical personnel: when the product requirements are mentioned at the technical level, general technical personnel will conduct general design, review, detailed design and review, development and implementation of the requirements. Of course, product managers generally do not get involved too deeply at the technical level, but in order not to deviate from the target as much as possible, it is a good choice to participate in the summary design review at the technical level, although for most product managers, they may not be able to listen to all Understand the discussion of technology at the level of outline design. Participating in the summary design review can understand the relevant systems, stakeholders, internal and external teams, etc. involved when the requirements start the technical design, and have a general understanding of the difficulties, bottlenecks and resource requirements at the technical implementation level. In order to reduce the deviation of user type, path and other links.
- Synchronize the long-term vision of the product with the technology in advance: Synchronize the product vision and long-term version goals, either when the demand first appears, or during the interaction design, but personally feel that it should not be later than the outline design of the technology. Synchronizing the product vision in advance allows technicians to determine the data, architecture, iterations, and reserved fields when doing technical design. Sometimes, there are many options for the implementation of technology. In case the expectation of the product is a magnificent building, because the technology was not synchronized in advance, the technology was implemented as an ordinary bungalow when laying the foundation.
- Understand the key points in the requirements: This needs to be confirmed in every technical communication, but try to understand clearly before the technical outline design, which is the importance of participating in the technical outline design review. Understand the key points of the requirements, and understand the relevant difficulties, bottlenecks, resource requirements, etc., and you will have a clearer grasp of the scheduling and time node evaluation of the requirements implementation.
Therefore, for the understanding of requirements implementation, the synchronization of products and technologies can make the implementation of requirements more effective.
Fourth, the understanding of the progress of the project
In terms of demand project progress communication, there are also differences in the understanding of products and technologies: the goal cannot be completed within the evaluation time point, and there is even no clear time evaluation. Faced with such a problem, the most important thing is to formulate a plan according to the previous communication. Only with a plan can we perceive changes. It is therefore recommended to consider the following elements:
- Control the progress of the project according to the key points of the demand: As mentioned above, the purpose of understanding the key nodes in the technical implementation link is to control the demand as a whole and prevent the chain from being lost at key nodes. Sometimes it is the need for product assistance, or the problem of urging the technology to get through the key nodes, and sometimes it is because of the previous assessment and understanding that the problems that may exist in the key nodes of the implementation are digested in advance.
- The "minimum unit of time" for requirement implementation cannot be too long: I define the "minimum unit of time" for requirement implementation as the shortest time that can be marked as a milestone or a clear deliverable during the requirement implementation process. For example, the development of an H5 login and registration function, judging whether the information input format of each input box is accurate, submitting the information to the database, writing the data in the database and returning whether it is correctly written, and giving corresponding feedback to the user, the development of each link The required time can be understood as a minimum unit of time. According to normal logic, the smallest unit of time is recommended to be 0.5 days to 3 days, preferably no more than 3 days.
- Discuss the difficulty and progress of advancement from time to time: For the needs in the promotion and implementation, it should not be regarded as a task that is completely handed over, let alone a "hands-off shopkeeper". Instead, it should refer to the smallest unit of time to discuss whether there are difficulties in the promotion from time to time. How to solve the difficulty, ask about the advancement progress in the smallest unit of time, if there is no progress, you may need to adjust the plan.
Therefore, from the perspective of project progress, it is also necessary to change the thinking of both products and technologies. First, understand the other party's ideas, and then think from the other party's perspective to jointly discover problems and difficulties, and then solve them. In this way, the advancement method of predicting in advance, formulating time nodes, and jointly supervising can make the project progress more smoothly.
V. Summary of this article
So far, I personally feel that through the elements of thinking synchronization, demand synchronization, technology synchronization, project promotion synchronization and communication synchronization, the demand can be better promoted.
a. (Communicate process-oriented or object-oriented thinking with technicians) Abstract product characteristics according to demand characteristics; b
. Think about product logic, formulate product goals and vision (discuss product vision with technicians at the same time);
c. Formulate (preliminary ) Implementation plan, drawing up detailed documents, interaction and communication-design and communication;
d, (participate in software overview design review, evaluate project schedule and difficulties in implementation);
e, (make development plan, split tasks into 0.5 2 to 3 days) Refactoring and front-end and back-end development;
f, (discuss the difficulties in progress, consultation and supervision);
g, test acceptance-online-optimization iteration;
the content in brackets is the optimized process content.
The above theories and viewpoints may not be applicable to all needs and projects, nor may they be suitable for all products and technologies, but we still hope to play a certain reference role in advancing our work.
Finally, I quote a saying from Grandpa Deng Xiaoping, a white cat is a black cat, as long as it catches mice, it is a good cat. mutual encouragement.