7 mistakes in the most waste of time and resources in programming development

& http: //www.aliyun.com/zixun/aggregation/37954.html "> nbsp; I worked as a project manager for several local companies, mainly on some small and medium pages made in PHP, I have seen many companies often make one mistake or another, which is a waste of time and waste of resources.Now I talk about the most unforgivable seven of these mistakes:

In general, there will be a standard document on the original demand at the stage of signing the contract. And one of the biggest mistakes we often make is taking for granted that this is what our customers think. My advice is to have a consultative meeting with all of our core staff at the client's site to ensure that all our clients' needs are covered.

Later if you want to add key features to almost completed products will need to pay a lot of extra costs, which could have been avoided.

I remember once, just because we did not think about a feature at an early stage, our team had to redesign the database model. Ah past memories ah.

Earlier I was working in a small company, because of limited resources, our boss always urged us to write the code as soon as possible. Normally we have to start the contract sooner (sometimes even earlier). We often know a lot about customer needs, but even if we know what our customers really want, our boss will not let us free up time for programmers and designers to write a requirement description. Because of this, rewriting the code became commonplace. Because there is no global charter, the solution given by the project manager often does not include all the requirements functions.

When I was in college, I often heard people say "writing documents is very important." It is self-evident that this is true, and I will not say much. However, assuming you are suddenly assigned to a project that is time-constrained, has limited staff and costs, and even management does not agree to pay for overtime, the unwritten document will definitely give you a goo: If there is a change of personnel during the project or Later add staff to follow up the project, which will cost a lot of company costs.

Taking the source code from another person without any documentation is no more vindictive than this one.

This situation is not just happening to developers. I have done a project, the customer's needs always change so much that the final requirements description and the original version is very different, except for Web applications, I can not find other similarities. Although our discussion is ubiquitously stored in the mail, and the final product is also made according to the client's request, it would be impossible for me to know exactly what we did when we did it, This has become an impossible task. Therefore, it is also important to keep track of project flow and changes in the document, which will prevent confusion and billing errors.

Small companies often hire part-time programmers to do projects. At this point if you also include the remote staff, then a suitable communication channel is even more important. I have repeatedly stressed to employees that communication is the key to successful cooperation. Some programmers lag behind the original schedule, do not inform other people, resulting in team-related personnel can only wait for him out of the results before they can continue to work, the intermediate waste of resources can be imagined.

If you've been involved with projects where many developers work together, then the importance of the claim that a good workflow is a key to success will not be questioned. But in many small projects, management tends to think it is not necessary to set up a workflow, and then the ineffectiveness of the team will make the stuff of those guys a mess: spending a lot of money and resources. In addition, it is also important to set up the following regulatory processes: internal communications, ownership of duties and tasks, emergency response, and more.

For example, there is a very useful task management tool, Trello. Not only does it keep track of tasks, it also defines handlers (such as preparing application software as described throughout the entire coding and testing product process). If you need to use chat tools (Hipchat, Slack, etc.), Trello also provides related integration tools. As a result, only one communication channel is needed to deliver all of your information, which will greatly reduce the cost of squandering your team.

There is a big mistake in the point of view is that source code management is not necessary. In fact, even if we had only one or two developers, we would probably be in deep trouble without using a source control system.

Or my personal experience, in a project, we developed a version that can be used to develop new features can also fix the patch, but we did not use version control. So, when a developer needs to update a product, he has to make a manual backup of the restore point. This is a very important application, with tens of thousands of daily visits. So once a bug was found and a patch was released, we found that there were unexpected jobs in the patch. This was a tragedy, which caused a data disaster and severely affected the company's reputation.

Without proper source code management is like playing with fire - literally: you're burning!

Talk about a job I had, that boss is very kind, energetic, like to personally. He is convinced that all mail must be personally approved by him. Have to admit, because the power is too concentrated, all processes need to go from his side, making it the weakest link in the enterprise. And, in the event of an emergency, there are not even temporary substitutes.

Obviously, this "respectable and ridiculous" boss has become the bottleneck of the project. We are always waiting for him to process the news. Indeed, it is good for controlling subordinates and forcing them to work well, but as a leader, they should also learn to trust subordinates and decentralize power.

Divide and rule. Controlling everything is impossible, especially in big projects like developing software projects.

The above mistakes also have their common ground: the wrong people lack the foresight and strategic vision. If we can not devote time to the right things, and are complacent about the effect of spending cuts right away, we can not neglect that in the end we will have less profit to create. Do everything to start with. Correct principles of service help to establish good habits, and good habits allow us to accomplish our task satisfactorily. This is how a company and its employees really grow. Otherwise, a business will eventually have only a short-lived ending.