Software product development, why failed
Liu hang
Software product development, why fail? After four years of software development, I have experienced several failure cases, I have to reflect on this issue. Most of my friends I have been in contact with software development. They are like me, and the examples of failure have much more than success. From all kinds of articles on the Internet, the information coming from the forum is also full of pessimism. Why are so many failures? For this problem, there are various answers. Such as demand is unknown, constantly changing; project management confusion, time and one drag; technical solutions, technical problems can not be solved; people flow frequently; there is no market, no competitiveness, etc., not enough. It is the reason for failure, and in the process of product development, it is necessary to face another danger and reef, and each may be a fatal threat. How to face these dangers, bypass these dangers? Some of the following is my personal thinking. Developing software as a whole process, this article tries from product development throughout the process to explain the various problems we will encounter and have proposed some own insights.
First, the project of software products
The development and project of a software product have many different. In general, software projects are started because of a clear customer, or have a contract or intention. Software products are completely different. There is basically no customer before a product is not developed. Of course, some people can find customers with ideas or concepts in the brain, I only admire these people. Of course, most companies can only take out a set of their own products to sell, it is likely to find orders. So there is an idea of doing products.
There are two cases in these software companies. One is a number of projects in a certain industry, and some experiences such as industries, technology are also accumulated. Every new project must repeat a lot of work, and the efficiency is naturally not high. At this time, the company is naturally thinking about having your own product. So start the product.
Another company is completely not the case. They are not doing more projects in a certain industry, and even have not done a project at all, they must be ambitious. This happens every day. They used to be systemically integrated, may sell hardware, perhaps it is not an IT industry, or just make a project, now they have to enter the software industry, so I am eager to make my own products to play the market. So they started the product of the product after some investigation and demonstration.
In both cases, it can be obvious that the foundation of the previous company is much better, and there are a lot of success. But this does not indicate that the latter will fail. At present, the key is to see if he has a comprehensive investigation and argument, enter this software industry, is it feasible to do this product. Many products fail, starting from the beginning. The company has not done how much serious argument is in a hurry. Software industry, product development has a lot of regularities. If the company's decision-making layer, the leadership has no experience, and has not learned, and the experience of other industries is not far away. The failure is not far away. For a simple example, human resources in software development are most important. Software developers' salary is very high in various industries, especially for people with extensive experience. If you don't understand this, you can't find outstanding talents from the leadership of the traditional industry.
In either company, they must be prepared in the following hearts when they do product projects:
Ø Software product development investment is very big, especially for companies that want to do large and excellent products.
Ø Software product development cycle is also relatively long. Two, three years to do a product is very common. Don't think that you can do a good product for half a year.
Ø Software products are very easy to fail. There may be no market development, or there may be no market.
If a company is prepared without these hearts, the result is likely to fail. Why do you say this, take my personal experience. A company I have done, the main business is to do system integration. Later, a product development of logistics software was started. In 2000, the logistics industry software has just been rising and is also a better direction. The company has built a development team and started a twenty-year tweet development process. Due to the various problems encountered during the R & D process, it is not possible to give the company a clear result. When research and development begins to see the dawn, the company has terminated this product. The company's high-level endurance does not have a lot of investment and too long. Any company who wants to do product must have these hearts to prepare, fully estimated investment and research and development cycle. Suppose the company has made full arguments and has a certain investment and time budget, product project. But this is just a good start, because the failure of any of the following processes may result in all over.
Second, the team building
After product project, it is necessary to start building a R & D team. Software development is a intellectual activity that is both highly collaborative and independently created. So people's factors are an important aspect that is related to product development. It should be said that the product can be successfully developed, and the reasonable construction of the R & D team is critical. A company's leadership may have no experience in software research and development, but must guarantee a reasonable R & D team. It is easy to understand that it is to let the right people do something appropriate. However, in turn, if the leadership has no experience in software research and development, it is difficult to build a reasonable team. How do you build a good team? This issue does not have a very common answer. The size and technical difficulty of each product are different, and the answer is different.
What we often see is that the company will appoint a R & D manager or a PM, responsible for the entire research and development process. So the problem came out. Is this PM responsible for management or technical work, or both are responsible? How to specify PM responsibilities? If there is no clear answer to this question, then the danger follows. Come to my experience.
After leaving a company, I came to another software company to do the product development of online education platform. The previous stage can be said that there is no full-time project manager, and management is basically responsible by a Team Leader (architect) that does technology. Although there are many problems, everyone is basically united to work together. Later, the company recited a PM for our team. This Jun is a sea turtle. In foreign countries, study work for several years, there is also a technical background. We are also full of expectations. I didn't expect to have opened our Team Leader soon, he found some reasons why everyone did not recognize. And self-service person in charge, to all of our technical programs, and severely ask us to obey his technical leadership. If he is universal technology, the key is that his technology is not a little, and it is also good to feel good. The final result can be seen. The product basically failed, and the technicians have hopped, and finally, this PM has only walked.
Such a story is happening every day, and a large number of technicians are complaining that leadership does not understand technology. In my case, it can be obvious that the company does not have a clear duty to this PM, or this PM does not work in its own position. This PM should do management work instead of technical.
Both software development knows that a team generally has a technical leader, or called architect. What is the responsibility of him and PM?
If the size of the product to be developed is relatively large, such as more than 10 people. At this time, there is more management, and the organization should consider using a full-time PM to be responsible for this work. His main tasks include the recruitment, providing the development team to the resource, formulation, supervision and implementation, etc., he should be a leader who can encourage morale, know how to mobilize the enthusiasm of employees, to the position as a PM Individual quality and character should have more decisive significance, and his main work is to provide all necessary services to the R & D team, the role of supervision should include it. In such a team, there must be a architect to comprehensively and responsible for technical work. He has the right to decide the technical solution independently. The relationship between his and PM is unity and cooperation, rather than leadership and leaders, architects should get PM should have PM Respect, and this is hard to do in China. Many PM interference architects' technical work, even ingenu, causing confusion between teams. The above case is exactly this. Architects generally have a little perfectism, he always wants to see that the product is more excellent, but is this to develop the product to unconver control? In fact, architects should compromise the real situation (such as time, funding restrictions), which is to make compromise on PM. If the PM represents the realism of the resource, the architect represents perfect idealism, they are constantly cooperating, compromising the development of the product. For the development of the product is small, the full-time PM can also be completely not set. Set a Team Leader, he is responsible for the entire technology and is also responsible for the management of the team. If the burden is heavier, you can configure a secretary (project management personnel) for Team Leader, and his main function is to assist Team Leader to do some convenient management. If the preparation of the person is recruiting, the development plan is supervised, and so on.
After the team is reasonable, the following will enter the core process of product development.
Third, business modeling & demand analysis
The front process is more determined by the corporate leadership. When our skilled people entered this team, they can only pray that there is a good start: the company will determined to develop this product, there is an excellent, understand yourself PM of responsibility. Now all the processes below are closely related to technicians (including demanders), and the technicians determine whether the product success or failure is.
Whether you do a product or a project, the first step is needed, this is not required. Almost every software knows that the importance of demand. But why so many main reasons for the final failure of the project is demand?
In software research and development, the business needs of the product are more difficult to determine than the business needs of the project. Products generally face the general needs of a certain industry, involving more convenient, reasonable extraction of these needs to form a more common product itself is a difficult job. This is more difficult for some software companies that have not experienced experience in these industries. Many companies really lead to the failure of the product because they don't have a good demand analysis. In the company I used to do logistics, it is also a serious mistake. We were not familiar with the logistics industry, and we can't grasp business needs, and product development has consumed a lot of time and effort during recurring process.
For this problem, almost all software engineering methods have proposed a good solution: introducing the domain business expert (Domain Expert). In our R & D team, we must have such a role, even if we don't have such a full-time staff, you must play similar characters (such as architects). Business experts can work with architects to develop business modeling, and architects are asked to translate business models into system requirements. In accordance with RUP processes, it is ultimately becoming a USE CASE. And a good business expert is very rare. This is why many companies have this awareness and have no important reason for demand work: due to funds, time and other restrictions, they finally give up this step, and hopes hopes On architects or other developers, this risk can be seen. There are also many companies without business experts, and attach this role to the architect. They ask architects to be proficient in business and are also universal technology. In the reality, such a human phoenix is a category that is visible and unsurable. Therefore, there is no clearly separate product research and development, what you get is not good enough, or you are not satisfactory in software architecture.
How to maximize the reasonable demand? I personally think that it is a good way to do a product. This is more feasible when making a Browser-based application system: Based on the business needs, this page may be rough, and the background does not need any programs, but can be based on these page elements and between Process to verify that business needs are reasonable, correct. This method is applied to project development (relative to the product), and can verify the demand with the customer. After several repetitions, it can be more accurate, grasp the real needs of customers. Such work is time consuming, but it can play a lot.
Fourth, architecture design
If the demand is good, it can be said that this product can basically go out, but it is known to have excellent quality, and how it is what the architecture design work is. In addition to meeting customers' business functions, a good product must meet some non-functional needs: system performance, availability, manageability, reliability, scalability, security, etc.
It is precisely because of these many problems. In this process, architects are easy to go to extreme. The most common extreme cases: (1) Excessive pursuit of perfection. (2) It will be done, and the software quality is not considered.
As a system architect, many people have the tendency of perfection. They continue to consider the performance, scalability, security, advancement of technology, and more. The words they like most, components, versatility, scalability, etc. So they constantly modify the architecture, constantly emerged new ideas and adopt new technologies. And all of this will make R & D fall into the hide. When I did logistics and education platform products, I met such a problem. Architect wants products to make more business needs, but also hope that almost every business module component, with more versatility, using as new technology. One of the finals that caused the plan to drag, let the company leaders lose confidence.
The second situation is also common in some smaller product research and development. Technical leaders basically abandon the pursuit of software quality under the pressure of time, funds or PM. They only hope to make a thing as soon as possible in the specified time. They basically don't consider components, scalability, and more. The products and projects that do this are almost almost because of his versatility, and the expansion is too bad.
It can be seen that both cases may lead to the failure of the product. The first one always wants to eat a fat man, they ignore the decline in software development, and the software is always falling, updated, and the spiral rise is developed. The second is the sorrow of the technician. They don't have the conditions to pursue software quality and can only hop the next version of the product. In fact, there is no previous version of a good framework, the new version wants to do well, almost re-developed. So an excellent architect, not to give up the ideals of the perfectionism, but also to make a certain degree of compromise in this balance, leading teams in this balance. In fact, there are too many companies that have a new company in China's software industry. They will not provide more conditions, more space allows architects to realize an excellent product. This is the sorrow of all of our software technicians, this is the sorrow of all people who want to go or are being architectual.
At this stage, in addition to the above situation, there are many problems, which will also lead to the failure of the product.
For example, the company's understanding and mastery of software engineering. Software project emphasizes the use of the process to ensure the success of the project, generally proposes a complete set of theories, such as some core processes, steps, methods, rules, etc., such as RUP, XP. There are many project managers, the senior rigorns of architects and software companies want to use these methods to ensure the success of the project, product. In particular, the company's superior leaders can only pass this method to ensure control of the project, so it is especially keen to implement these methods. However, what is the fact? . Everyone often has this experience: for the document, written documents, basically throw it into the garbage bin, no effect. I said this, I don't think the software engineering is not good. The key is how you use it. Software Engineering is a very practical discipline, which requires us to continue to adjust, implement, not some dogmas in this Xuko. I am most afraid of encountering this: some leaders or project managers have read several books of software engineering, and they have thought of finding a spiritan medicine, they began to implement in the project. For example, what time is developed, what time does it achieve, what is the result, what kind of documentation, etc. This tendency is filled in the product product. At some time to hand over the architecture design document, most of our time is not to consider, verify the architecture, but to write this document. As a result, when we want to implement, it is found that there is a serious problem with the entire structure, and then it is too big to do it again. Personal feelings are to use some software engineering theories, need project managers, architects have rich practical experience, and can develop some independent methods based on different product development situations. Software engineering is some universal theory, and it should be flexible to cut.
Fourth, other steps
If the above steps are good, the product should be basically successful. With a reasonable architecture design, detailed design and encoding should not be a problem, this only needs our software engineer's efforts. Of course, test is important, but basically will not lead to the failure of product development.
The author posts: After having several projects, I have experienced some failure, I wrote my own ideas. This article text is more chaotic, basically what you want to write. I have encountered problems, many friends who do software are often encountered, after complaining too much, I decided to write it down. It is too difficult to do software in China. If you have some idealism to the software, then you are too painful. My Mail: daliliu@sina.com
