If the reason for the change is your own problem, you should have the courage to admit it, deal with it actively , and reflect, improve, and email list avoid it afterwards. Don't shirk responsibility, so that everyone is unwilling to cooperate with you and assist you.
If the change is due to external reasons that cannot be rejected, emotionally accept it as soon as possible and design a new solution as soon as possible. Because for some changes that cannot be rejected, negative emotions are not only ineffective, but more likely to make the development of the situation uncontrollable.
03 Some methods that can be used
Master the ability of structured thinking (a summary of structured thinking will be done separately next month). In the production stage of the plan, you must first think about it, think carefully, and then write the document after you collide with key personnel. Just like when developing and writing code, you must first do the design and review it before you start. Because in the process of writing documents, it is easy to fall into specific functional logic, and lack of macro overall consideration, it is very easy to make the output not rigorous.
Fully communicate with associated systems. Don't be embarrassed, don't think it's troublesome, you must ask questions if you can't get the answer, and you must report what you can't coordinate. Doing a little more now and confirming one more problem can save a lot of time and cost in the overall process later.
Communicate adequately with developers, especially key roles such as project managers and technical managers. Communicate the feasibility of the plan and the difficulty of implementing the communication plan, and consider their suggestions for revision. Of course, there may be dilemmas in this process, but since we are a team, we always have to negotiate a feasible plan internally.
Maintain timely interaction with customers. Clear the nature of the customer's needs, and introduce the idea of our plan to the customer as a whole, and finally judge whether this idea can be recognized by the customer. This process will also involve issues such as how to conduct demand insight and how to explain solutions.
Make the plan intuitive and easy to understand, so that "stakeholders" can make constructive comments. When explaining and discussing the design plan to customers and project teams, the functions of the interface class should try to use intuitive expression modes such as prototype diagrams and UI diagrams to make everyone more conceptual; the functions of the background class should try to use flow charts, sequence diagrams, data Discuss in the form of flow diagram and other expressions, so as to ensure that everyone understands and reaches a consensus. Worst of all, a quick drawing with a whiteboard or toilet paper is better than a dry explanation.
There are many ways to change. When there is a real change in demand, or when the leader wants to add a new demand, first look at the true degree of this demand, whether it is a "pseudo demand", and whether the existing function can "curve the country to save the country", so as to guide not to do it. Next, evaluate the urgency of the requirement and the impact on the existing requirements, and then see if the solution can be minimized based on the existing requirements. At the same time, it can also propose whether a certain proportion of non-critical functions can be replaced with new functions, so as to ensure the progress and stability. The workload will not deviate too much.