The project from scratch, the middle to solve a technical problem, sometimes in order to catch up with the progress, i don't know how many shifts, and finally reached the closing stage, see the victory of the light, is it time to breathe a sigh of relief, do not forget that before dawn is the darkest, at this time the external exchange will be more obvious and important, the project will all be handed over to the test personnel test, sales, implementation personnel will take the product to the customer to demonstrate, implementation, once there is a problem in the middle, improper handling, responsibility will be like a ball kicking around, and it is very likely to stage a "dog bite dog" conference.
is the project really coming to an end? according to the requirements of the beginning of writing, is not all the functions are done, as long as one is not done well, even if this function is small, it is not yet done! of course, you can say to the outside world that everything is done, but what is going on, you must have a number in your heart; US does not have an old saying that it is better to deceive others than to deceive, and when the requirements of the end are not met, the corresponding delay must be carried out, and the general delay is:
1. regular delay. i can't finish it when i get to the stipulated time. according to the requirements and task documents, count the unfinished tasks of each person, and reassign the unfinished tasks (pay attention to forming a task document), report to the superior, and after approval, proceed according to the normal development tasks. (it is best to recruit the group of people together, talk about why there is a delay, find the reason, cheer, and grasp the delay time, because after the delay can not be completed can not say that it can not be passed)
2. The time of the test is occupied by the delay. To the specified time there are still some functions unfinished, but the test there is impossible to measure all the functions at once, the unfinished project packaged to the test, in general, the test process and the development of the process order is similar (if not, you can talk to the test), so that the test will first test the function, generally will turn in the BUG sheet every day, the development of corrections (while completing the unfinished function), update the program when updating the past, unconscious?? Everyone in the group knows, unspoken rules?
3. fooling each other with customers under the cover of time delay. the function can not be fully completed (there is probably no test link in the middle), but to rush to see the in-laws, had to say that it was done, and then do the customer to do a demonstration, or first install a trial, the unfinished part can be flickered as much as possible (avoid talking, pulling east and west, asking east and west and other tricks), customers will inevitably put forward modification suggestions, naturally add time, which achieves the purpose, unfinished functions can be inserted into this period of time to complete.
for these several project delay methods, try to use the first, standardized operation, is the best; less use of the second, because due to various reasons can not be regular delay (such as has been delayed many times), it is also possible to use this trick; can not use the third, personal hate this method the most, the delay is very painful, the longer the customer ideas (new needs, have opinions on the developer), often repeatedly, into endless demand. (the delays i did in college were almost all the third kind of delays, which was unbearable; when communicating with friends, i found that many companies often use the third method of delays. ）
according to the requirements document, all the functions requested by the customer have been realized, and congratulations, the project can enter the final stage. the rest of the work is handled separately within and outside the group.
inside the group, do not relax too much, cheer up, do a good job of follow-up work, and wait for the acceptance to be completed.
don't relax too much and get refreshed. the task is done, so hard for so long, of course, to relax a bit, but the relaxation can not be too much, but more than the degree, and then do things to do things to be several times lower efficiency (the task is done, but at any time to do things, the test found a big problem, sales said that customers want to add functions, etc.).
In this point i have suffered a big loss: when i first started to receive a project, finished, handed over to the relevant personnel, all developers rest for two days, rest back suddenly there are requirements to modify some processes, found that everyone is not energetic (including me), originally according to the usual efficiency to do a day on ok, the result of 3 days, and then look back on it is actually normal, just imagine: a group of people in running 5000 meters, after running one by one are tired lying on the ground, and then suddenly come to someone to tell everyone to run another 50 meters, who can still run ah! don't be too relaxed, just talking to the team members does not work, i personally assign them some other work to maintain a basic state.
(1) TEST YOUR OWN TASKS AND MODIFY THEM YOURSELF IF YOU FIND ERRORS. CORRECT THE BUGS FOUND IN THE TEST.
(2) where the deficiencies are improved, where the code is manual labor, repetitive labor, and whether it can be replaced by technology. (doesn't it usually mean that there is no time to study technology, isn't it time?) ）
(3) good places continue to carry forward, which modules can be abstracted into general modules, form common modules and write documents, and save time and effort next development.
(4) form some small problems and tips into a document, and the next time you have a question, you will not know it?
the above work should pay special attention to the formation of documents, the company's knowledge base is not so rich, personally think that the above work (2-3) is more meaningful, and there is no pressure of formal tasks, that is, to maintain a state of development and moderately relax themselves.
outside the group, clear responsibility, is their own do not shirk, more communication, not fighting, in order to solve the problem for the purpose.
before listening to the teacher said that development and testing are opposites, the contradiction between sharp, at that time felt a little exaggerated; in the actual operation found that it is indeed like this (especially when there is a strict performance appraisal, related benefit distribution), the tester thinks that finding out the errors in the program as the main purpose, and the programmer side is known to regard the program as their own child, just imagine that others in order to find your child's mistakes for fun, can you not be in a hurry?
in addition, if there is a salesperson mixed in, it is really hilarious, there is a problem, when the three parties coordinate, the test scolds the development: the delay in time causes the test time to be insufficient; the sales reflection: the program is not completed in time, or the quality is problematic, or the function is incomplete, so that he lost the customer; the development of the scolding: the test of the error rating is incorrect, and the sales staff is not familiar with the software, and the demonstration caused their own mistakes... one of my classmates jokingly called it the "dog bite dog" conference (khan, it seems that he was one of them), and i think the main reason for this phenomenon is that there is not much responsibility and insufficient communication.
a personal opinion on the division of responsibilities
the current responsibility division model is relatively vague and unclear, and there is a problem, that is, it can be said to be sales, it can also be developed, and it can be said to be tested; what's more, when the problem is found, it actually says "as long as it is related to the program, it is your development", i wanted to ask a rhetorical question at that time: "can you find out the problem that is completely related to the program?" ", it may be that this kind of thinking is at work, and the people who have gone wrong with the development have a share, which is very easy to cause developers to be physically and mentally exhausted.
personally, i think that responsibility should be divided into clear boundaries, summed up in one sentence: who found what type of problem the responsibility belongs to whom, as shown in the figure as shown in the figure, parts 1, 2 and 3 are seated at the same time, and the person responsible for the problem can be uniquely determined. when 1, 2, 3 cannot enter the relevant liability provisions, the suspected crime is never committed, and the responsible person is not pursued in this round; after discussion, the responsibility provisions are formed, and then implemented in accordance with the regulations.
for example, a critical error in the same program
if the customer finds out, it is the tester's responsibility (because after testing by the tester, the tester is responsible for ensuring that there are no serious errors in the program)
if the tester finds out, it is the developer's responsibility. (this article should not need to be explained)
in this case, the division of responsibilities is clear, and the number is seated, how can there always be a situation where responsibility is pushed around? but i am only the leader of the development team, and i can't implement my ideas outside the group, so i can only solve the problem through more communication, although the symptoms are not cured, it is better than nothing!
(writing here found that the article has been very long, there are some ideas to communicate with the outside of the group has not been written, as the group leader just began to deal with the communication with the outside of the group is very troublesome, because everyone's interests are often opposed, it is easy to make the relationship stiff, but then careful observation, thinking, practice, found some small skills, can skillfully solve a lot of problems, and why should everyone fight to blush, now look back on it or have some fun)
No comments:
Post a Comment