When a small company first started, there were only a few people who made products. At this time, there is no need for any management. You can meet and discuss many things. However, as the company continues to grow and develop more and more products, leaders and technical backbones will fall into low-level and cumbersome business activities. This often leads to a phenomenon: the company seems to be getting bigger and bigger, everyone is getting busy, but the products are getting worse and worse, and the R&D time is getting more and more uncontrollable.
When such problems occur, everyone habitually begins to introduce various management systems, the most common of which is various process management software. When we introduce this kind of management process, we often have unrealistic illusions, such as: can automatically supervise all employees' work, can automatically record the workload of everything, and automatically remind everyone what to do next. Unfortunately, if this kind of software is used for warehouse management or supermarket cashiers, it is very efficient, but if used for software development management, it will be unsatisfactory.
What is the underlying cause of such management confusion? I remember that a certain education expert in the United States once said something to the effect: "We should educate our citizens so that they are just smart enough to operate the automated system, and just too stupid to accept all those poor jobs." To put it simply, if you want this kind of automated process system to run smoothly, it requires the employees attached to the system to be foolish employees.
Software research and development are purely mental activities with high IQ. Software engineers are mostly intellectuals who have been trained for many years. Inner restlessness and human desires will cause frequent conflicts between personnel and systems. The most typical performance is that everyone is willing to take advantage of the loopholes in the process, especially the loopholes in the various KPI assessment mechanisms. This will make team members too eager for quick success and short-term benefits, and no one considers the long-term interests of the company, which ultimately leads to more internal struggles than collaborations.
After a company has achieved a certain level, it will definitely not work without management, and traditional process management will not work either. Management seems to be the only way for individuals and companies to grow. Is there a better strategy?
The total quality management system (TQM) spends a lot of time criticizing various KPI assessments and emphasizing personal leadership. After contacting TQM, I felt like I had discovered another path and found a low-cost software R&D management system suitable for small teams with active team members.
I think the most important feature of this management system is respect for human nature. Most software R&D engineers have a strong desire to grow up. The management system driven by the endogenous needs of this bottom-level human nature may be less understood from the perspective of professional managers, but there is less resistance in the implementation process and the effect is obvious.
It needs to be emphasized that the total quality management system (TQM) is more of a methodology, somewhat similar to Tao. It is necessary to combine the characteristics of the real product and consider various constraints such as the ability of team members to construct feasible strategies. These strategies are already similar to techniques. In this section, we will describe some strategies that our team likes to use, but because of the different constraints, everyone can only understand, it is difficult to copy.
◇◇◇
The document system is a very confusing task in the software development process. Many company product submissions are just a bunch of code. If a key employee resigns, it will be difficult for future generations to take over. This will cause great losses to the company and even lead to the fragmentation of related product lines.
Everyone can naturally realize that this state is not right, so in some time when the work is not busy, the leader will ask everyone to make up the documents. Unfortunately, this kind of temporary documents written in order to meet the leadership's requirements is of little value in most cases. For example, if the documents do not match the code, they may even have a negative effect. A lot of hard work, wasted a lot of manpower and material resources, and finally turned into a bunch of useless work.
How to crack the document dilemma?
The total quality management system emphasizes people-oriented, and the documents are produced by people, so they should serve them. Based on this philosophy, our team reached a basic consensus: only write useful documents, and write useful documents. Based on this design concept, the R&D supporting document system structure built by our team is shown in the figure below (Note: related documents such as project initiation, user survey, requirement summary, and acceptance are the upper-level process documents of the company. The document system in this section only refers to Supporting documents for R&D work):
Architecture design documents, which have been explained many times above, are not only used to guide product architecture design, but also an important mission to assist the team in internal communication and reach consensus. When a newcomer joins, it is also necessary to understand the architecture design document before starting specific work. In order to achieve these goals, architecture design documents are mostly graphics, supplemented by necessary text descriptions.
In our plan, there is no specific detailed design document. The detailed design document focuses on describing each software module. Some modules are relatively simple, just a description of the architecture design; some modules have more complex interfaces abstraction, and it would be better if there is a paragraph of text to describe their design ideas; some modules are suitable for adopting status Computer programming, at this time its detailed design document is a state diagram.
After years of practice, our team likes the strategy of code and documentation. Integrating detailed design documents and code together is first of all to facilitate review. If you can first understand the design ideas when reviewing the code, the review efficiency can be much higher. Furthermore, with the aid of the review mechanism, it also helps to keep documents and code synchronized.
In the distributed architecture, it is necessary to build a communication link based on the can network, and the state machine is most suitable for use at this time. The following code is the CAN network communication link state machine. After long-term training, everyone is already familiar with this text-based state diagram. If there are multiple state paths, we will be used to using different comment lines to describe.
/* 主CPU和各扩展CPU连接状态机 */
#define LINK_STATE_IDLE 0 /* 初态。成功发出连接命令后进入LINK状态 */
#define LINK_STATE_LINK 1 /* 连接态
* 接收到板类型进入状态TIME,发送对时命令,并设置连接正常;
* 超时后重发连接命令,并设置连接异常
*/
#define LINK_STATE_TIME 2 /* 对时态。超时后发送对时命令,进入RX态 */
#define LINK_STATE_RX 3 /* 接收态
* 接收任何帧时返回TIME状态;
* 超时后返回LINK状态,发送连接命令,并设置连接异常
*/
Code review checklist is a continuous iterative team document, its main purpose is to guide the code review process. The code review checkList document is the most valuable asset within the team, but important does not mean emergency. Usually everyone is stuck in specific work, no one will take the initiative to construct the document, need to be supplemented by some systems to ensure it. For example, if the auditor encounters a common problem, he needs to consider whether to add the checklist; for example, after a bug is solved, he also needs to consider whether to add the checklist simultaneously,..., in actual work, it is necessary to clarify which positions or jobs have checklist maintenance Responsibility.
When building a checklist, we are used to adding a writer to each record. Checklist is the wealth of the team. We often use checklist as the basis for newcomer training and assessment. It not only helps the team to keep pace, but also helps to cultivate leadership within the team. It is a team honor. Many people enjoy this honor very much, so they will actively participate in the maintenance of the checklist, which also helps to produce excellent auditors.
One more thing needs to be added, the checklist document must not be simple to use. Some companies feel that their checklists are small and shabby at first, so they quickly copy a lot of them, and eventually make checklists unusable. Less is more, slow is fast, continue to build based on the characteristics of your company, team, and products, screen and supplement one by one, maintain availability, and avoid formalization.
◇◇◇
In the research and development of industrial product embedded software, the "people" factor is always the first. How to build a positive talent team may be the first task of the team leader.
In order to build a talent team, we need training, but the reason is simple, and the reality is embarrassing. Many companies have some intensive induction training when employees first enter the company. After explaining the basic system of the company, they are in a stocking state. How far everyone can go depends more on personal effort and luck.
I personally didn't like the centralized training mode. I remember that my induction training was an explanation from one teacher to another. I was drowsy listening to it. There should be more training in the subsequent product development process, but it is often missing.
Training is difficult to implement. At the same time, there are many jobs in the workplace that people are not willing to do. Remember the two rings I discussed before?
In real work, everyone prefers the work of writing code, but does not like the work of code review and integration testing. If there is no uniform code specification requirement, reading other people's code is a very painful thing, and it is even better to rewrite it yourself. Similarly, if there is no unified architecture and interface thinking, integration testing is also difficult to implement.
I wonder if you can realize that code review is actually a more advanced job than coding. Before code review, you should not only think about the general structure of the program, but also need to take into account multiple perspectives such as products and teams, and even learn to tolerate other employees. More importantly, review is the best training strategy.
At first, I had a misunderstanding that testing work is relatively low-level and is a kind of "silly" work. In fact, integration testing is also a more advanced work. It is not only necessary to think about whether the internal implementation of the module is reasonable, but also to test whether the modules are compatible, and more often need to think based on the product perspective. Similar to auditing, integration testing is also a training strategy for module programmers.
Similar to this, work such as problem decomposition and synchronization and mutual exclusion at the project site also requires a certain ability to deal with. Eliminate everyone's misunderstandings and redefine these tasks in the product development process, not only to avoid the embarrassment of some tasks that no one is doing, but also to automatically select the talent echelon.
Among ordinary employees, an employee with strong ability, serious attitude, and certain leadership within the team will naturally grow into a supporting employee, and grow into an auditor. At this time, his task will be sublimated to: review the code of ordinary employees. Assist when it is difficult or find an abnormality, and quickly substitute temporarily when someone asks for leave or leaves the job, undertakes the coding of modules of a certain degree of difficulty, and product level integration testing.
With the continuous iteration of this personnel selection system, product managers will be born among auditors, product line leaders will be born among product managers, and architects will naturally be born among product line managers. This kind of naturally-growing architects generally have strong leadership and coordination skills, far stronger than those assigned by the leader.
If you want to make more money and have a higher position, you must have the ability to train upper-level personnel and grow into higher-level supporting employees. This kind of talent structure is an echelon organization model supported by layers, as long as it is well divided Work, driven by human nature, an excellent self-iterative team is naturally constructed.
One additional point is that when supporting employees work, they often adopt a man-to-man on-site strategy. There are two person-marking strategies. One is to do the work by yourself and let the newcomer watch and learn, and the other is to do the work and watch by yourself. This strategy is quite efficient and can quickly discover the problems of newcomers, which is much more efficient than just reviewing the final results.
◇◇◇
Document system, team building, this kind of work is the old and difficult problem in traditional research and development work. Now, with the help of a total quality management system (TQM), and driven by positive humanity, we disassemble these tasks and integrate them into daily specific affairs, and the execution has a sense of smooth flow.
Reconstructing the entire R&D process with this concept will eventually form an efficient management system that seems to have no management.
——————————————
I am Xiaomaer, an embedded software engineer who longs for conscience and soul. Welcome your company and travel. If you are interested, you can add a personal WeChat account nzn_xiaomaer to communicate, and you need to note the word " different dimension ".