The company already has a mature product, and the sales situation is good. The current project is the follow-up product of the product, but it is not a simple upgrade, if only used. net to implement the previous VB work, there is no practical significance. Because it is a qualitative leap compared with the previous products, it is almost re-designed in terms of structure and business. However, the implementation of the new architecture is difficult, as a result, existing manpower and technical strength cannot be achieved. The formation of a high failure, low or not, on the one hand, the goal is too high, can not be reached, on the other hand, if you adjust the goal, a lot of the previous work must be retried. In the end, the project became a "chicken fault", and the top executives did not care about it. They put all their energy into profitable projects. However, due to the large amount of manpower and material resources invested in the early stage, I have made a lot of explorations in some aspects, and I am unwilling to give up. However, the actual situation is that, if you do not make any adjustment and cut down some unrealistic functions, you can only go further and further, and finally only fail one result.
Therefore, I think:
1. positioning is very important. Before the project starts, determine what the software is and an upgraded version? A new product? What is his value? Do not start it at startup.
2. What are the core functions of the software, what are the difficulties in implementation of the architecture, how is the feasibility, and how much impact these components have on other components. If the risk is too high, cut it down and use other simplified methods.
3. discard some unrealistic functions during development. Some requirements may arise, but in practice there is almost no chance of appearance or appearance. More importantly, it is difficult to implement it, which requires a lot of manpower and time, it may also affect the design of other parts.
4. Be more cautious with the new features proposed by the management during the development process. The management layer sometimes asks for a new function, but you cannot find a reason to refute it, because what he says makes sense. However, because of these requirements, you have to adjust the plan again and again, and modify the existing items for compatibility. In the end, you can find that this item is useless at all or to the third point, which increases the project risk and outweighs the loss. Although we are talking about "Embracing Change", we should first look at the price before "embracing.
After writing so much, I still cannot speak out.
To sum up, we should give up our pursuit of perfection from the real reality.