As a programmer, the most important thing is the product. They may make a request like changing the theme of the phone according to the case. They will also change the same request 10 times and then use the first version.

As a programmer, is he to be slaughtered?

Of course not! Crotch on fire —- crotch burning.

Here are some ways to minimize fights with products.

The plot

The root of all evil: need. There should be a plan for the demand. If not, please ask the company to optimize the process or change another one.

The plan is just like the blueprint of the construction team, the language expression is always ambiguous, and the plan is to reduce ambiguity, and keep as evidence, so that the operation and later colleagues have a trace to follow.

And when you get the planning case, the first thing you need to know is:

1. How much the product cares about this feature

If it’s just product trial and error, be humble. If it’s something that could be extended indefinitely, think of more possibilities and reduce refactoring.

For example, the room PK function may be the operation to see similar products, and then want to try the effect. When we design, we only need to ensure stability, rather than ensure scalability. After all, the room PK needs a lot of anchors, and the probability is not very good. Manual funny.

For example, the room red envelope function is to promote user consumption, should be used for a long time, and there is no guarantee how many people grab, and it is related to money, so we should consider more concurrent design, and improve the number of people can carry. But the red envelope will not have what expansion, at most is to change the red envelope skin, so the possibility of expansion is not big.

For example, the noble function, first of all, is related to money, and all kinds of authority flashy, will certainly expand with business expansion and expansion, so it is best to design an independent system, reduce coupling, later extension function directly access to this system.

2. The story behind the feature.

Each function has a proposal point. Considering the reason proposed by the product, also known as the “original demand”, and then analyzing the planning case, there may be some better plans.

For example, the product wants to have a recommendation system, and then designs a bunch of algorithms, such as calculating weights based on the last number of minutes of a certain time, and then adding decay periods and so on. You can optimize this complex algorithm in a way that is easy to write to meet their needs.

Some people might think that this is not something I should think about, isn’t it the product that decides how to design? Wrong! Products just think about what I want, they don’t know technology, so they don’t know how to be simple, how to be complicated, they can only think of what they can think of.

You can never think of what you don’t know.

This is when you need “the Art of Communication,” you can’t just be convenient, and you can’t completely write algorithms that don’t work, even some algorithms that don’t work at all. This requires you to fully understand the story behind the feature and do the work.

Demand changes

The most annoying thing about a program is not how complex it is, but how it changes all the time.

The first system that needs to be improved is estimation, after the case is discussed, revised, finalized, the program should evaluate it, including testing, should also evaluate, and then give the estimated online time. Any changes to the development process will add time.

However, this is effective for the company operating its own products, but not for outsourcing, so Party A says I need to change, and finally I have to work overtime to change, how to do?

Keep a backup.

Never trust the product or party A’s word, ever, ever.

No matter what they say, this function will not change, after this, and the function of the last time almost etc., do not believe!!

Commit git yourself, tag your changes, or even branch or directory if necessary, to keep your rollback costs low.

State of mind

Maybe you’ve tried all of the above, but because of system issues, or because someone is a screwup, you can’t get out of it.

Try thinking about this:

  • For example, he is a good friend of the boss and a good helper to the operation.
  • If I hate I can not change, if the change has become a fact, it is better to accept. (Life is like QJ, if you can’t avoid it, just lie flat)
  • I don’t know if I can beat him.

If the above you want to be good, even bucket, hospital have already wanted to be good, finally think: fight is what charge, suggest to see luo Xiang teacher’s video.

Actually,

We’re all wage earners, so why bother.

Don’t be. Don’t be

In interpersonal communication, we should skillfully take advantage of others’ weaknesses.

If you’re a soft touch, anyone can throw trouble at you. If you blow up without lighting, no one will dare to hand over the team to you.

So, fight when you have to, but try to be reasonable, not fight.

Ok, that’s all for the experience of dealing with products. Later, I will continue to write several articles about project practice, sharing how to design each function well and how to avoid the pits in products.