In many software projects, the lack of a reasonable time schedule is the most important cause of project lag, and it has a greater impact than all other factors combined. what is the cause of this pervasive catastrophe?
1. expect everything to work well
first, how to make reasonable estimates is based on a quiet, but not real assumption— that everything will work fine. but there can never be such a project where everything works well.
because the executor is a person, and people will make mistakes, understand biases, do not understand the original code, ineffective communication, and many other problems will appear in the executor.
after all, for all kinds of strange needs, unless you have done it before, you never know what problems you will encounter, and a word hidden in a vague corner of the requirements document may consume a technology for 2 days or even 3 days.
this is often intentionally or unintentionally ignored during the requirements review, after all, the most important requirements review is in the current requirements development
often asked to shorten the time as much as possible, "the product has been designed, your technology starts as soon as possible, and it will be launched at the end of the month, no problem!" ”
2. confuse progress with workload
second, the estimation technique we employ implicitly assumes that people and months are interchangeable, incorrectly equating progress with workload
confuse. it takes 3 minutes for a pot to steam a bun, so does it only take a minute for three pots to steam a bun?
when the degree of business coupling is very high, a certain task can often only be written by one person, otherwise the communication costs will be brought about
as well as joint commissioning costs often make the increased manpower do more useless work. however, often in order to show the importance of the project, the superior leader usually increases the number of personnel to the project, and the increased personnel are often confused, and there is no way to start in the face of a large amount of code, after all, programming is not a brick, and it is necessary to work on the basis of understanding the original project.
3. estimates cannot be carried through
because the demand duration is generally an estimate, not an exact calculation, the project manager usually does not have the patience to continue to estimate the work. when a module in the project encounters a difficult problem, it is often impossible to estimate the specific solution time, even after the estimation can not increase the time, after all, the requirements for the end of the month online are still echoing in the ears, at this time to go to the time is likely to be exchanged for only one sentence "no time, you work overtime on saturdays and sundays!" ”。
4. lack of tracking and supervision of progress
in other areas of engineering, proven tracking techniques and routine oversight procedures are often considered pointless moves in software engineering. but in software engineering, tracking is often ineffective, after all, most enterprises add demand as easily as drinking water. the leader knows that the glass curtain wall cannot be replaced by tiles, but how much time it takes to mention this software function point, then no leader knows. before going online, the leader opened the website to take a look, mentioned a few new needs, often a few sleepless days.
5. the wrong solution brings the opposite effect
when a project manager becomes aware of a shift in schedule, the knee-jerk (and traditional) response is to increase manpower and overtime.
the direction is wrong, and no amount of effort is in vain. new recruits often take a while to form combat effectiveness, and long overtime often brings mental and physical fatigue to employees, both of which are often drunk and thirsty.
why is there always a lack of reasonable time for project development? are there any reasons for your postponement in the above five points?
No comments:
Post a Comment