An emotionally complex agile release and lightweight application

For the concept of "agile release", I do not know how many people are familiar with the concept, for me personally, the feelings of the idea is very complex. On the one hand, I am a loyal supporter of agile release, but I see a lot of abuse of it, even I can abuse, do not know how to give it the right definition.

A few days ago to see a typical case, a peer said, their own Sina Weibo application, from the creative to release only 6 days, 6 days! This app is called "apps," and it has a sense of the app social referral service. From a positive point of view, as early as possible to come up with a prototype available to accept market testing, and then based on real data and feedback to adjust the product, far more reliable than nowhere "user modeling, competition analysis." The negative part is that the popularity of the agile release also encourages "a pat on the head" "a pat on the thigh," summed up as "a series of" The Absurd project blind development.

From 2008 to now, I have joined the Internet product industry has 3.5, according to my observation experience, usually a series of projects, the success rate is less than 1%, the average death rate is 50%, between success and death is "good death rather than live" such a flattening state. So dismal result, greatly promoted the specialization of process management, all kinds of use research means, all kinds of competing goods analysis, all kinds of data mining compete to compare, the result? The success rate is likely to rise to 5%, with the average death rate down to 35%. At the management level, it's just kettle.

Very early, before the NetEase game an unknown name of the high man has a famous saying: Whether it is 5 people's project, or 500 people's project, the failure of most of the reasons are from "not capture user needs." The true meaning of this sentence is, how professional process management, the success rate of the promotion are very limited. Otherwise, those big international companies, they usually have the most sophisticated, most prudent project management norms, is not always win? Fart-not a pile of uncompleted buildings.

The success of any product has three prerequisites:

1, the product is in the rising period of the market (timing)

2, management system and resource support can promote product development, not drag it (geographical location)

3, product leader with this product must have the gene (people and)

All three are ready and easy to do. Process management can only verify the "Weather", for "geography" and "people and" are helpless, the success rate of the promotion of Natural limited. But if even the process management does not do, I am afraid it is a beat series straggly. Even if not too outrageous, there are two consequences: first of all, the initial version did not grasp the core requirements, a breech hit the word of mouth, Web products users do not want to try again, app users uninstall or no longer upgrade. The second is that the initial planning of the elasticity is too small, the late expansion caused a lot of restrictions. Of course, the initial picture of a pie will die faster ...

So in the end is agile, or conservative, a matter of opinion, there is no definite statement. Plainly, it depends on the person. Depending on the background of the project, the person will choose lightness or prudent process management rather than seizing a dogma to die. But this law has a twist in the light of application era, becomes one-sided "agile release is King". The reason is simple--the average development time for light applications is 6-8 weeks, and if the preparation is for 3-4 weeks, the food is cool. When the development cost is low to a certain extent, agile release is the better risk control method. Because the guarantee effect of process management is only "better than nothing", but it takes a lot of time, the development cost is completely lose, as the trust product leader's experience and intuition.

At this point, the trust of the PM is the key to the implementation of agile release. In addition, there are three necessary links which will have a decisive impact on the outcome.

First, lightweight applications are more suitable for agile releases than traditional products, and the reason for this is not the low cost of development. The positioning of the light application itself is "to meet the specific needs of specific users," the division of the target user groups more granular than the traditional products, more typical users rather than diversification, reducing the difficulty of using research.

Second, more than half of the members must be loyal users of the product (especially PM himself), which works better than any user model. Only strong empathy can truly understand the user, understand the application situation, and the user has more resonance and topic. Although it may also be pushed by others, but always more effective than aloof.

Third, the management must be streamlined positions, the pursuit of one person more than a fine division of labor (reduce communication costs); You have to organize the manpower in a small project group, kick the hell out of the bill of lading schedule (improve product ownership). Group members of the best after more than half a year of running-in, cooperation tacit understanding, mutual affection.

Combined with the above three points, it is easy to find agile release in fact, with large companies have no fate. Because the big company is at all despise "small use of light application", the project is difficult, and the staff scheduling is very inflexible, 2nd completely insecure, the 3rd is more mirrors. If the authority is not sufficient, the level of reporting layers of approval, talk about what agile release, is a eunuch's dream. But the more wear the shackles of 80 Jin to walk, the more easily fantasy and preach the good of agile release, but forget the "people" is the king-yes Ah, who is willing to admit that they are not reliable?

So I was embarrassed to see the slogan "Agile and agile" on the Big Horn in the sky. The truth is true good, holding the banner of the people who Misbehave is also Shijian. Every time I talk about agile, immediately there are a lot of people shout loudly, sometimes I wonder to see their products, forehead sweat suddenly like fountain. Just, even if I do not talk about agile, they will not be crooked to gallop up? Who is not the past, who is not the repeatedly wall, perhaps one day break the walls out. As long as you can bear the cost of failure, you hit it, and I am not so.

The only problem is that if you choose the Agile release (light application) route, it's best not to try it on the company's projects, not take the boss's money and risk it. In addition, most corporate systems do not support agile release at all, but are dragged down by it. Instead, find some like-minded companions, group A team, with free time to do a little sense of the project Bar-the idea of a true love will be willing to pay. Despise those who shout "why not Agile", "Why not Innovate", and then 8 hours a day to work, let the company for their recklessness and ignorance of the bill, but do not want to the company (and their claim to "very involved" project) to do more than two or three hours of work.