Page 1 of 1

but when you really use it, i

Posted: Mon Dec 23, 2024 4:29 am
by rifat22##
Of course, this is only the standard of our department. The requirements of each company are different. It is only used as a reference and example. Don't take it too seriously. The standards mentioned above are actually the same for both products and development. Products are from being usable to being easy to use to being desirable, and development is from being usable to being stable to being continuous. But once you start to give up, the so-called ambition will be gone. Specifically speaking, the things produced are very "makeshift" and very "rough".



It means that it is indeed available,you feel that kazakhstan mobile number example something is missing. Let's take an example. One is the backend function and the other is the frontend function. Let's talk about the backend first. Our venues often need to issue fixed coupons to certain fixed users. The fixed period may be weeks, months, or years. Anyway, it is not very fixed but relatively not so flexible. When I first proposed this requirement, I thought of having a scheduled task that can automatically issue coupons to this group of people regularly.



I also evaluated according to this expectation. After the first coupon distribution, everyone thought that this function had been completely blocked. But about a week later, someone reported to our staff that there were no coupons available recently and they could not use them. Finally, after investigation, it turned out that the backend did not have the function of automatic distribution and all coupons were issued manually. So now more than half a year has passed and he is still issuing coupons manually. He seems very busy every time, but he does not solve the fundamental problem every time and is just doing repetitive work.