When it comes to software process, the various model methods and theories described by the huge set of CMMI theory immediately pop up in some people's minds. If fully implemented in accordance with this theory, most small and medium-sized projects may face serious time and energy problems. So, most of the demand analysis is at best a simple text or a screenshot plus a sentence, and even many projects do not have the so-called demand analysis at all, and the technology is directly connected with the customer.
But is the scale of a project really as expected at the beginning, it must be a "so easy" or "so hard" project? Not necessarily, a small project can gradually accumulate requirements into a large project, and a large project may become a small project with only a few core functions after mining and refining the requirements. There are many factors such as market technical talents and other factors that determine a project, but the most fundamental factor is the demand of the project, and other factors are changed according to the demand. It can even be said that a project is a process of continuously materializing user needs. If so, do you still think that requirements analysis is a process that can be omitted?
"Our project time is very tight, so let's skip those analysis and design stages", "There is no time to write documents, just start development" These are the words that leaders often say when they are in a meeting to "understand" the project team. However, is it really possible to eliminate this stage, NO, to be precise, this is just a "transfer" of the work of requirements analysis. Where did it go, it was transferred to design, it was transferred to development, it was transferred to testing, it was transferred to operations, and it could even be transferred to users in turn. Everyone understands the requirements from their own perspective, realizes the requirements and even expands the requirements. From design and development to operation, the number of participants is often far greater than the number of demand analysis. In this way, everyone will bloom, and the project manager said: This thing saves time in this way. The technical manager said: Let's add a menu here. Development said: It is not easy to achieve here, but it can be changed in another way. The test says: This shouldn't be done here from a user experience standpoint. Operation said: here (the N "here" is omitted here), wouldn't it be enough to add a judgment? Finally, the client said: I saw a better website yesterday, I understand what I want, let's just revise it. Maybe you think that investing one person to do professional demand analysis is optional, but will the sum of the costs consumed by so many people in the later period really be less than the cost of investing in a demand analysis?
The schedule of most projects in the software industry is very tight, which is of course inseparable from the impetuousness and utilitarianism that are popular nowadays. Another important reason is that in the eyes of the general public, computers belong to the high-tech industry, and the production efficiency of the high-tech industry is bound to be far better than that of the traditional industry. If the high-tech industry is less efficient than picking up junk and begging for food on the side of the road, why bother with software development? Software development is very trendy, but it is by no means limited to its trendy technology. In fact, most application software development uses technologies that have existed in the last century. The trend of software development should be reflected in its advanced project management and personnel management, project management system, internal support system, standardized document management, agile development, quality review, performance incentives, and even more popularly, how to win people's hearts and make others convince you All of them belong to the category of project and personnel management.
Most of the software and hardware of computers have been standardized, and the technologies used in software development have reached the point where there are very few people who use the principle of compilation to write a compiler. What we need is something close to standardization of human activity. And a successful project often does not spend the most amount of effort on code, and even uses some technology that is not "fashionable" at all and developers who are not at all "cow B". Software is made by people. A bunch of people with confused thoughts and imaginings can't develop anything even with supercomputers. If you want to manage a group of people from all over the world, you can only use process, rules and a little personal charm to restrain them. , to guide, otherwise what needs to be managed?
For a software workshop with only a few people who rent private houses for development and make lunch by themselves, the development, implementation and operation of requirements may be performed by one person. If he is asked to recruit people for these positions separately, he will definitely think that you want to Bring down his company. However, for a modern enterprise with diversified business fields, the division of labor, standardization and processization are inevitable and inevitable. This means investment and risk, but it is more a test of vision, courage and cultivation as a leader, as well as a system to implement the leadership will and subordinates with executive power. Otherwise, the team that gathers around you will be a group of "talents" who seem to do nothing but ask for a salary increase at the end of the year, or turn people who were not like this into such "talents". The department (enterprise) has become a puppet army formed by a group of "cottage bandits". The so-called bigger and stronger will always be a slogan.