Posting a good article on CCBOY-turning to 12 object-oriented steps in "column sound"

Stingy gods-4-12
We have discussed a lot about changes and changes. I wonder if you have taken the time to consider the question of how we transform to a new technology or platform?
The transformation of technology or development methods in the past depends on the software development process and actual design and development personnel, often on the final development personnel, which will be a test and transformation for a single development individual. In this case, the consequences of a successful or failed change are basically those of these developers, whose functions may flow to their upper-level development organizations or companies. However, what's interesting is that the transformation process and the final form are also different and very different. Just like a gliding flight, it passes from one hill to another; however, it is painful to practice swimming in the quagmire. Not only is it full of sludge, but it also gets deeper and deeper.
Today, enterprise-level development requires the collaboration and support of a team. The strength and will of each individual must be adjusted to suit the themes and strategies of the entire team. Now, a new technology application in enterprise-level development also means that the entire development team needs to respond and adjust it together. Some people in the team claim that it is meaningless to start using a new technology. Therefore, turning to a new development model or using new technologies must be faced by the entire development team, or even extended to a higher level, with adjustments or changes at the project organization or company level.
When we know this possibility, we may need to accept our own frustration first. No matter how the transformation process gets longer and becomes more complex, individuals will no longer be the primary and only individual of the transformation. The transformation not only happens to individuals but also to the entire team, technology and non-technical things are mixed together.
The results of this change bring about consistency and predictability based on the team's requirements and spirit. Therefore, we will not debate on whether or not we want to change, reduce the error of using a new technology to adapt to all projects, or take the initiative to experience new technologies with significant projects. After getting frustrated, we were still comforted by the team, because the change together meant to work together to form a good guideline. Each person can evaluate the technology itself in an objective and consensus manner to see whether it is acceptable, whether it should be rejected or adjusted. In turn, it may develop into a mechanism that enables technology or change itself to become a positive force to be controlled and used by you and most people in the team.
The key here is understanding, understanding, or understanding. Not only do you need to understand it, but the entire team also needs to understand it. We need to understand not only the technology itself, but also the reasons for using it. Understanding the final understanding is only to form a correct concept. What you understand is to get a correct and clear idea.
I do not think that the transition to a new technology or platform can start and develop together with the project itself or be handed over to the well-developed risk control in project management. In fact, some projects have failed from the very beginning. The project itself hides the transformation to a new technology or platform, and most of the entire project team is not clear or prepared for this. Failure itself is a blow to new technologies, because outsiders cannot see the workload of change, and technical reasons seem to be more suitable for making a possible public explanation of such a secretly aborted project.