1. The essence of programming The
so-called programming is actually to give a thing to the computer to do, how do you think it should be done, describe it to the computer in the form of "programming language". Program = algorithm + structure, in this formula, code does not exist, only thought exists.
2. Lazy people create methods
. After all, people's energy is limited, and new "methods" are proposed to solve the fundamental problems that affect the effectiveness of work.
3. What the team lacks is more than management
1. From the perspective of management, the failure of the project is directly related to the experience of the project manager.
The success of the project is mainly assessed by two aspects: project completion quality and project completion time.
2. The connotation of the system is divided into two aspects, one is "body", that is, "system", and the other is "system", that is, "system". The manual produced by the "ISO Quality System" is just a "system". Behind this system, what is required is to change the old "system", not to bring a "management system" to each employee. Just read it once.
3. When the organizational model is determined, the corresponding system should also be established. The establishment of a system should be both humane and fair.
Often the people who shake the system are not the erring employees, but the managers themselves.
4. Follow the ants, but don't fall into the ant hole. Although you are also a part of the team, remember to stay away from the ant hole. When you look outside the cave, you can find problems, but in the cave, there are only ants who "follow the rules". The manager is the one who can put sticks outside the hole.
5. Determine that employees who are "flexibly assigned" need to be able to quickly switch to new roles. But the first thing to examine is not whether he is "capable" to play
the role, the ability can be enhanced through learning, and the change of role is first of all a change of mind.
4. Formal communication
1. There is nothing wrong with "asking the blind". The real mistake is that you ask with your eyes open.
2. You have to confirm whether your communication method is effective, not to pursue whether this method is UML, and whether you express it correctly in UML.
The client signs the "Requirement Confirmation" because he thinks you understand his needs, not because your UML drawing is accurate.
3. Three barriers to communication: The first barrier to communication is not what you want to express, but how you express it.
A second barrier to communication arises in discussions with smart people, making people feel "incomprehensible." In this case, the premise should be established and the conclusion should be formulated as early as possible. The main performance of the third layer of communication barriers is: lack of urgency. The solution is to not set the communication goal to get the other person to agree.
4. Communication is just a means, a kind of tool, and the goal of the manager is the project itself. Making decisions in the shortest possible time with as few people as possible is the key to reducing communication costs. Some "different" viewpoints have nothing to do with the overall situation, and can exist regardless.
5. The effectiveness of every communication should be guaranteed. Every communication opportunity obtained is an opportunity to understand the deeper needs of customers.
Therefore, it is best to design all questions and questioning methods before meeting customers.
6. A historical record should be made for the project. The historical record provides the possibility for the subsequent development and maintenance of the project, and leaves a communication channel for non-existent roles. The history includes documents and reports for each stage such as requirements phase, design phase, development phase, testing phase, etc.
7. You should pay attention to every project review: Communication in a mere formality is most likely the most direct reason why your project is constantly being overturned and delayed.
5. The process of failure is also a process
1. Realization is the goal. Many people forget the essence of the problem. From the very beginning, from the very beginning of our programming, our purpose is to achieve something.
Whether this thing is a small tool or a project as large as tens of millions, our goal is to "realize" it.
2. The simpler things are, the closer they are to the essence.
3. Engineering is not done, it is organized. Of course we cannot "do" engineering, but "organize" engineering. The project manager's job
is to organize the various roles in the project, so that the division of labor is clear, the pace is consistent, and the project is completed together.
6. Who is the person who solves the knot?
1. Corporate culture is a group phenomenon. In addition to the long-term self-evolution, the group phenomenon itself is the phenomenon that the team culture guided by the manager
spreads out and then exerts an influence.
2. Experience comes from thinking about the past, not copying it. For those airborne people who say "we've done this successfully" in front of you, start by thinking of them as lungfish. Only by raising doubts can we look at the background on which successful experiences depend from another angle,
and we can see the accidental or related factors behind some successes.
3. It should be remembered that the responsibilities of managers also include "monitoring, identifying problems and preventing proliferation". Therefore, you should take the initiative to leave yourself time and space to discover the problem, locate it, analyze it, and organize manpower to solve it before it occurs, instead of waiting until the problem occurs, then rushing to the front,
and then before you have a clear awareness of it. When you get to the root of the problem, try to fix it.
4. Put others first, managers must not forget to do one thing before "busy": drive your team.
Ask yourself: "What if you don't do this thing? What if you don't do that thing?" Find the one that has the greatest impact,
let someone else (or everyone) do it, and do it yourself The "not too important" thing is fine.
5. How you look at a problem depends on your perspective on the problem. Ordinary players focus on the immediate gains and losses,
so they see the "problem" of conceded goals. Jordan focuses on the gains and losses of the game, so he sees the hope of scoring.
7. From programming to engineering
1. Language is just a tool, program = algorithm + structure. This is the original definition of programming, and the original state.
2. "Thirty-six Strategies" is more often read as a methodology. The root of this is that "scheming" itself is a method, not a strategy.
3. The BOSS (operator) determines a direction, and the organizer ensures that the decision-making is synchronized with this direction, and engineering is
a specific behavior under such a direction and decision-making framework.
4. Implementation is the essential requirement of software development. Therefore, implementation methods always appear first, followed by analysis and design methods.
8. Can you see the essence of the tool?
1. The method of using the tool is more critical than the tool itself. Therefore, the rhetoric that "if you want to do good things, first sharpen your tools" is not necessarily correct.
2. The essence of the tool is like engineering and programming. In terms of programming alone, it is fine to pay attention to the subtlety of techniques, and it is okay to pursue details and branches; but for engineering, it is a practical technique that allows the team to understand, execute uniformly, and quickly and effectively. is what is really needed. Just like war, in team engineering,
the quality of technology is not the key. It's about whether a technique works for the team as a whole, not whether one person likes it or knows it well.
3. The deeper one is immersed in a technique, the easier it is to forget the original goal and application of this technique—just like Chen Yaozi only regarded archery as a skill,
but could not see its essence as a battlefield weapon; it was like selling oil Weng blindly rehearsed the subtlety of his techniques, not thinking about selling oil.
4. The use of tools has reached the point of integration, and it does not matter which tool to choose. But the so-called accommodating is based on the understanding of the thinking behind the tool.
5. After understanding Interface, we really have the concept of "software design". And once there is the concept of software design, the process of "implementation"
becomes less and less important.
9. Software Engineering in Reality
1. If Yu Gong stopped, he might think about the "method" of gravel. The project manager jumps out of the details and thinks about
the "method" to complete the project. There is only one criterion for evaluating this approach: cost savings.
2. The project plan without cost will not be supported by the operator; the purposeless consumption of cost is the chronic poison in the project;
the most fatal risk is the exhaustion of cost.
X. Specific Engineering
1. Definition of Generalized Engineering: It is oriented to "the fundamental task of software activities"; the process of program implementation does not help to solve the fundamental task.
2. The definition of engineering in a narrow sense: it is oriented to "requirements of specific engineering activities": realization; solving "fundamental tasks" is just
an exploration activity or added value that regards "realization" as a process or result.
3. The most important but also the most difficult to guarantee in all practical activities is: control of scale. Scale is divided into two aspects: scale and scale. The former is the boundary and
the latter is the form. Doing more, and making things "better", etc., are all out of control of project boundaries.
4. From the perspective of thinking method, general engineering considers the "rule" of engineering problems, while specific engineering considers "divide and conquer".
The key to divide and conquer is to isolate the problem domain, find the relationships between the problems that cause confusion, and sort out the unrelated problems.
11. Thinking or thinking
1. Knowing the law and changing, people who read a book of "Software Engineering" will not do real software engineering.