Focus on details but not on details

We often say that we should pay attention to the details. In the general direction, there is no problem. In the past, there was a book "Details determine success or failure" about this aspect. In some fields, details need to be concerned, but they cannot be stuck in details. In other words, if you have been struggling with the details, it will be difficult to break through and grasp the overall situation. After all, people have limited time, so they can grasp the whole and grasp the key details, attention to the details of core fields is king.

I have done a lot of projects before. After the overall business of the Project is determined, I am stuck in the discussion of details. When a group of people sit together, you can say, I will say, take out all the possibilities that everyone can think of, and then you can find the corresponding solutions for various possibilities. Some of these details are specific to a specific instance, some are caused by abnormal business rules, some are interactive, and some are abstract, public.

Among these details, the most valuable is the details of abstract and general fields, which can help you abstract specific details into common features, in addition, the abstract details can be applied to other fields to achieve the opposite effect. For example, in projects, we often use the timing mechanism. One of the details is how to retry if the system is being maintained and the scheduled task is not executed. For a specific scenario, you can write a manual trigger button. The details can be abstracted, that is, how to compensate for the failure to execute tasks due to exceptions in the timing mechanism. There are multiple solutions, and you can even develop a dedicated task management platform to do this. Similar to the general and abstract details, such as the business concurrency control solution, it is worth noting and in-depth mining.

For the details of some specific scenarios, such as our cooperation with external parties, we have customized the Protocol. However, in rare cases, we do not comply with this protocol. This is a special case in general scenarios, it is difficult to abstract these problems because they are for specific fields and scenarios. The value can be analyzed based on specific details, and the value of this part is relatively low. It can only enhance your understanding of a certain field.

There is also a kind of discussion that is purely a waste of time. These discussions are completely meaningless or have little reference value for feasibility. For example, if the length of the page text box is large, do you want to send an email to the user if the service fails, and many force Installation Problems: "For a dispensable function, consider the machine power failure, disk fill, and other details.

if you are often concerned about the third type of details, it will be quite boring and boring. the most time-consuming and confusing issue is the discussion of the second or third type of details, this type of detail problem is difficult to help you or let you consider the problem from a higher perspective. You can understand this part of details, but you do not need to fall into this part of details. You should focus on the common points of the details, find Common Problems from some commonalities and propose general solutions for these problems.