Third, reference plan
In fact, the management of IT companies requires practical, easy to perform, rather than high, complex norms and processes, and the developed management specifications and workflows are to help employees make work better, so that employees are happy Avoid flow in the form. Therefore, the design of tool software needs to be employee, in the flexible, practical principle, using modular structures, so that each module is relatively independent, self-contained, and integrates into collaborative ideas, making each module between each module Interacting to assist employees from more complicated daily work, more effectively reduce work difficulties and improve work efficiency, thereby achieving quality of product quality, improving service attitude, reducing corporate cost and ensuring operational security, ultimately helping IT companies Improve market competitiveness.
To this end, for the symptoms of IT companies, we can consider getting up and integrate from the whole game, and consider the management tools used one by one, while listening to employee's opinions and ideas, try to meet the needs of various people. In this way, the management tools can be welcomed and accepted by employees.
Below I combine my own practice, I provide a reference program to clarify the responsibilities of each department (or role), comploate the processes of each department (or role) and coordinate the relationship between departments (or roles), and improve IT companies. The internal cooperation and team spirit, hoping to bring you a "visible, touching" management idea, and I also hope that IT companies that have not implemented tools or have implemented tool management. The planning or development of the management tool will be included in the important agenda schedule as soon as possible.
Overall module flow chart
As shown in the "Overall Module Flowchart" above, it is basically transferred from top to bottom, from left to right, where the bottom box includes: public management, resource management, training management, knowledge management, outsourcing management And financial management, this part of the content can be independent on the overall process. Public management is the management of the system public content, such as system dictionary, system parameters, person roles, etc. As can be seen from the figure, the development of software can be mainly divided into several phases, test and feedback, design, and development, testing and feedback, maintenance and summary, project management needs to be reflected in the above content, so as not to Monitoring blind spots, as for the process management of software development mainly includes demand management, change management, test management, defect management, version management, and problem management, task management and quality management need to penetrate each module inside. In addition, each module is relatively independent, can be used alone, the interaction between the modules and the association can be seen from the connection. As for the flow and association inside each module, I will be briefly described as an example of defect management and problem management due to the discretion management and problem management.
The following is the "defect management flow chart" and "defect state change map" of the defect management module. The defects mentioned here include errors that appear in software design, programming, and production, as well as issues that help improve quality, worth paying attention and tracking, and potential errors that may exist. From the "Defect Management Flow Diagram", it is possible to see the links experienced from registration to the closure, where the meaning of defect rulings is the last clapper that the superior person is submitted to the developer's dispute or unrecognized defects, for example Developers and testers require superior personnel to ruling when there is different opinions on the same defect. In addition, the defect is generally closed through the release of the release, of course, can be directly turned off for final determination not defective.
So how to reflect that it has not been processed, defective and defects have been resolved? In fact, it can be distinguished by the state of defects. Please see the "Defective Status Change Map", the processed handling and treatment of people, no one has been investigated after the defect registration, and the treatment representation has designated the handler, and the processed handling indicates that the handler is not specified; The specified handler has started processing defects, but there is no final confirmation reason or countermeasures; for the confirmation of the reason and needs to modify the content, transfer to the state of the change, enter the change management module; after this type, release, defects It is automatically shut down to solve the above questions. In addition, the meaning of the referral refers to the mutual flow between the same class. For example, the transition process is to indicate that the current handler if the defect is given more appropriately, it can directly transfer the defect to him (she). Of course, this translation is best to communicate in advance, so that everyone will push each other. Defect management flow chart
