Create a typical enterprise Web site project

Synopsis: This is a true story. In the story, I was the head of a project, because at the beginning too cater to the customer, but gave up the insistence on some basic principles, eventually led to the project was forced to make a big change. In the process of change, the loss is minimized by introducing agile development.

Project background

In early 2006, a customer contacted my company and wanted to be able to create an enterprise Web project for its enterprise. According to the customer's simple description, this project is essentially a content management system, and integrates the forum, FTP and e-mail functions, so it is not complicated. According to previous experience estimates, up to one months to complete this simple project.

Demand analysis

In general, the main features of the project include news and article publishing, product launches, and background user management and permissions settings, as well as peripheral forums, FTP, and e-mail systems. It should be a very simple Web application, usually by writing a simple, summary document, and you can arrange for the developer to actually encode it.

But the client is a state-owned enterprise, so a simple summary document is clearly impossible to audit through the leadership. To this end, I and the customer together, the site all the functions organized into a list, and marked the relationship between the various functions. After the functional and internal logical relationship is sorted out, the client also draws the layout of all the pages together with the designer as a chart. Ultimately, the requirements document is up to 50 pages.

In the process of organizing the requirements document, I found that the project was not as simple as the customer first described it. Because the customer's enterprise has more than 100 departments, workshops, so the customer requirements according to department and workshop on the site's users to manage. At the same time, authority management is a layer of authorization. In short, the higher authorities can, but also to the direct subordinate departments authorized, and can not leapfrog authorization. Authorized users can create a subcategory of the product. The child category is then assigned an administrator for the subordinate department, and then the administrator of the subordinate department creates a deeper subcategory or manages product information.

On the surface, there is nothing wrong with this design. But in the actual operation, this kind of design requests to each department's related staff to carry on the training, lets it master the system the use, increases the project the application cost. At the same time, because of the cumbersome licensing model, ultimately responsible for product management personnel do not have sufficient power to use the system.

So I put forward my own opinion to these unreasonable places, hope to adopt more flexible and practical design plan. Unfortunately, I failed to convince my client to accept my opinion. After all, this is a large amount of the project, the client side in charge of insisting that I also helpless.

Although according to the requirements document, I set the project development time to two months, but it turns out that the two-month time limit is too optimistic.

Prototype system development and preliminary review

When the documentation is ready, I've arranged for developers and designers to do this project. And the developer less than 20 days, took out a prototype system, although the details of a lot of need to improve the place, but the main functions have been. After the prototype system was developed, we conducted a preliminary review with our customers. The results of the review are both satisfactory, so be prepared to refine the details in the rest of the time.

However, I found that the power part of this prototype system is very poor, so I put forward the revised opinion again. But the client apparently was unhappy with the way I was "skeptical" and ended the discussion with a phrase "This is our industry's decision." Although I already know that the decision to determine the success of the project, "People" is the key factor, but under the pressure of customers, I chose to compromise again.

Many developers believe that as long as the prototype system passes the review, the entire project will not encounter major problems. But the reality is sometimes very complicated. Because the prototype system is usually just a few people sitting together for a simple show or a trial, and the actual use of the system's environment has a huge difference. So many problems are simply not exposed at the prototype stage.

The system was completely defeated.

The whole system is perfect, from the requirements document to the actual development work less than 1.5 months. During the business trip, the client's other contacts either have no decision-making power or are not aware of the problem (state-owned enterprises), so we continue to develop according to the requirement document without further feedback. However, after the perfect system is "very smooth" through the customer's inspection, began to deploy to the server for trial run.

But like volcanoes, the problems that exist in the system can erupt beyond the tipping point. In just a week later, the onsite technical support staff who provided training were brought back with a detailed revised opinion document and feedback. And I just looked at these documents for a few minutes and realized that the project was going to be a major change, otherwise it would be impossible to put into practice.

The content of the modification opinion document mainly concentrates on the permission system, in particular, the design of the permission system is too complex and too rigid. First of all, layers of authorization is too cumbersome, and sometimes change the name of the product category to find a superior administrator to do. Second, because the system limits can not give a manager to assign multi-level product classification permissions, so must each product classification level to set up a different management account.

Customer Enterprise has more than 10 large categories, more than 100 small categories, thousands of models of products. But in fact, there are not so many people willing to take charge of the management work, and finally became a person with several accounts, the original idea of strict authority management is not a fictitious. And because the use of too much trouble, the actual management work gradually to a small number of people concentrated, causing these people complained, began to put forward a variety of negative views of the system.

In this case, our company and customer business leaders have a number of meetings, the initial decision on both legs. On the one hand, with the shortest time to modify the existing system to ensure that the new product release customers, the website can be officially launched. On the other hand, make a new system to replace the existing system.

Start again, how do you choose?

For a software company, if a project is redo, the loss and impact are very large. Because not only other development plans to be disrupted, but also the cost of the company to increase exponentially. At this time, how to reduce the loss is the most important thing. Fortunately, after further consultation with the customer, the customer undertook half of the loss. The full redo also changes to only the permission system portion.

Based on this goal, I first schedule the developer to modify the system. Cut off the privilege system (which, in effect, caused the whole system to redo) and modified multiple functions according to the successful experience of other projects. After the modification of the system, although the lack of authority management, but other functions through the customer enterprise staff to reflect good use. Moreover, most of the functions of this simplified system can be moved directly to the newly-developed new system, and the cost is reduced to a great extent.

At the same time, in my strong request, the client enterprise decided to arrange the person responsible for this project. So I can ensure that the development of the new system is not the same.