How to do product subtraction

"How to do product subtraction" This problem is based on the specific product market conditions, the company's personnel environment to judge, out of the complete ecological environment, can only say some taffy nonsense, cliché, no more talk, the following according to their own experience for everyone to sum up.

Life most hate taffy excrement ...

However, the recent product subtraction has several actual combat experience, may wish to take out to talk about. Before speaking, think of the micro-blog to see people say inspirational quote "not to the last minute, do not give up", was fiery forwarding countless times. And some June said, "When is [the last minute]?" Laugh and want to shake hands with a gentleman. Product subtraction is also the truth. The pig in this industry knows that subtraction is good, to do subtraction, when in the Bureau, it is easy to know what is more, what is less, what is plus, what is minus. Chenge "Product subtraction good", as if the Hong Kong film Bad Lines "people alive the most important is happy."

Let's get to the point. Do product subtraction skills to local conditions, a matter of opinion, but there are some objective means to help you to the knife. By this means, I found three of them, which happened to be not too difficult.

The first method is to set a few fewer milestones. Set the current phase and the next phase of the product target with a period of 1-3 months. At each stage it is best to have only one core goal, absolutely no more than two, and the size of the granularity is based on different time periods.

Set goals, but also a technical work. Defining a single goal is helpful in dividing the task weights, and setting the next stage goal is useful for scheduling secondary tasks at the current stage.

The second approach is to make a strict release schedule. I am in Joel's "software random record" to see such a passage, deeply sympathetic, immediately hand out to mass pm altogether.

————————————————————

An effective schedule has many great benefits, one of which is that you will be forced to delete some features. Why is that a good thing?

Suppose you want to implement two functions. One of these is very useful and will make your product a truly excellent product. Another is easy to implement, and programmers can't wait to write it out ("Look! Don't blink!"), but this feature is not very useful.

If you don't have a schedule, programmers will first make easy/interesting features. Then, they have not enough time left, you have no choice but to postpone the schedule to develop useful or important functions.

If you do have a schedule, you will realize that you have to cut down something before you even start working. So, you cut off an easy or interesting feature, and all your energy is devoted to developing useful or important functions. It is this pressure that forces you to cut off some of the features that make you end up with a stronger, better product that includes a better combination of features and can be done on an earlier date.

Recall that long ago, when I was in the Excel5 development team, our initial list of functions was huge and the completion date was far behind schedule. "Oh, my God!" We thought to ourselves, "These are all super important features!" without a macro-editing wizard, how do we live?

Finally, it is obvious that we do not have a second road, can only be cut off a lot of functions, cut to the point that can not be cut, "only the skeleton", so as to be completed on schedule. Everyone was very unhappy about it. To make everyone feel better, we comforted ourselves that the cut was not abandoned, but only deferred to Excel6.

As Excel5 's development work drew to a close, my colleagues and I began to write the design specifications for EXCEL6. We sat down for a detailed review of the list of features that were brushed from Excel5 's schedule and ready to be put into the Excel6. Guess what? This feature list is worse than the worst list you can think of, and none of the features are worth developing. I think each of these features has never been worth developing. To keep up with the schedule, we cut off these features and now it looks like it's the most valuable thing we've ever done. If we hadn't done that then, the EXCEL5 would have been extended by one time, and then the product would have had 50% useless garbage, and in the future we would have to maintain these features until the last day of Excel's life, to get the current version backwards compatible with those features.

————————————————————

Joel's article is a lot better than me, not Dog, and then the Third Way: Publish your first version as quickly as possible. How fast is it? Even before the user beta came out, the preview was published internally, which I would call the light pole version. Only basic usable core functions, with fairly rough interface and interaction.

In the past 3.5 of products, I have repeatedly been ashamed to realize that the design of a product prototype, and you in the real data environment to use it personally, there will always be some gaps. To be honest, I can't predict exactly how I feel to use it before releasing a product (module). This thing may disappoint engineers, but even if the three bow apology, I have to say, "Design scenario" and "real use situation" there is always a gap. Sometimes the design direction itself is wrong, but we add exquisite refinement to it; sometimes the direction is correct and the details are not the same. Considering that the development backbone function usually only accounts for 50% or less time, it is best to provide a light pole version of the real data before perfecting the details, so that the team can "correct the feeling" and adjust the design in time. At least more accurately than on paper.

The above three simple means, is I come this year's summary of experience. I don't have enough talent to see what to lose, what to hold on to, and to create some external pressure to make a choice through pressure. This includes setting the core goals, making it easier for you to cut down on tasks beyond your goals, developing a release schedule that makes it easier for you to cut off tasks that are not achievable in your schedule, and preview products (or small agile iterations) in advance to quickly perceive the real experience. Otherwise, a column is a proud design, the palm is meat, the back of the hand is also meat, if the lack of pressure, it is easy to indulge their ideas, and later regret.