Agile development performance management 4: setting external performance targets (target management and export-oriented performance) for teams)

This is the fourth part of agile development performance management. (One, two, three, four, five, six, and seven)

 

I recently read Drucker's book and found that it clearly states the concept and statement "enterprise performance only exists outside, while enterprise internal cost only, next, let's talk about the performance appraisal of the agile development team.

Agile development has many "export-oriented" ideas, such as focusing on Customer values and believing that deliverables are the factors that can truly characterize the progress of work, but they are not directly in line with target management. Extroverted thinking can prevent inter-department barriers or kick the ball, but instead discusses the value of external delivery. We can see this from the comparison below.

"Introverted" performance and orientation

Progress: The "completion rate of each stage" will lead to analysis and design personnel to end their work, and a lot of uncertain work will be pushed to the developers. The developers will do the same and kick the extension to the testers.

Quality: "qianxing"CodeDefect rate will cause a lot of disputes between developers and testers on the issue of "whether it is a defect". Other secondary problems, such as inconvenient use and inintuitive use, will be put on hold for a long time.

Cost: The overspending rate compared with the plan will make the project manager reluctant to accept the change, even those that clearly bring great value to the customer.

Function: the proportion of completion of requirements in requirement specifications will result in the development team's thinking being limited to the understanding of the requirement specification period in the current year, rather than constantly refining requirements throughout the long development process.

In addition, there are some more terrible data, such as "Number of code lines produced every month", "Number of function points or story points produced every month" (this is confusing), and "number of defects modified every month, both are inappropriate performance. Drucker's philosophy of "only cost inside an enterprise" states that, whether it is a document, code, software that can run, or even a final product, it is only a part of the cost if it has not been sold.

Most companies and teams that adopt introverted performance have poor performance results. The reason is that a single department, job type, or individual's pursuit of their own performance does not lead to an improvement in the external performance of the entire project (this is called a "merging error ").

Some introverted performances are even mutually exclusive and are in a zero-sum state. For example, the number of defects detected by the test team per capita (the performance of the test team) and the number of defects per developer per capita (the number of defects discovered by the Development Team)NegativePerformance) coexist, thenNeither team can improve performance at the same time.As a result, they will never be able to help each other like a team. If your company has such performance, it is no longer necessary to fight between developers and testers.

Most other introverted performances have potential mutex relationships. For example, in the previous phase, the on-time completion rate is mutually exclusive, while the "requirement completion rate in the Requirement Specification" must be mutually exclusive with the "customer requirement response rate.

Export-oriented performance

Below are some potential"Export-oriented" PerformanceBecause the export-oriented performance of different enterprises and products is very different, please use them flexibly.

Product research hairstyle

Progress:

"Compared with competitors, the listed date of the same product is more suitable for consuming electronic products.

The "response time to distributor demand" is suitable for situations with strong channels.

These outward-oriented performance should be applied to the entire team. In other words, no matter which stage leads to poor progress, the performance will be the same. So that the entire team can think about how to improve performance.

In order to allow developers to start work ahead of schedule, the requirement and design personnel can adopt the segmented writing requirement and design method to write out the most influential part of the architecture that will not change, allow developers to start work ahead of schedule, and developers may adopt the same strategy to release products in stages so that testers can perform tests in advance to prevent Product delays due to too many final defects; the demand and design staff go back and use the development progress and testing defect rate to determine whether the product should reduce the function in exchange for time to market, or increase more functions in exchange for competitiveness.

VisibleA team that strives for external goals can easily unite and jointly think about the best strategy to improve performance.

 

Quality:

The actual data of an ERP company consulted on "number of quality questions to be handled each month" (but they have not used this data for assessment) is generally consistent with the Ruili distribution, therefore, we can predict the number of quality problems in the future.

"Number of end-user complaints per month" is suitable for industries that are closely related to customers, such as consumer electronics and online games.

"Number of complaints from distributors per month" is suitable for situations with strong channels.

"Number of Forum defects raised per month" is suitable ...... One company I use BBS to handle defects for free.

Using complaints from end users as external quality goals does not mean that users do not need to test and leave defects to users. But:Revise our understanding of the defects and revise the methods for discovering the defects with the defects we tested but still missed to the customers.

There are many products that receive complaints about ease of use from customers, far more than complaints about functional and conventional defects. Therefore, "Poor ease of use" should be the core quality issue, and thus the quality focus. When I download an android text message software with a 4-and-a-half-star rating, it is found that many of the recent comments are "getting harder and harder to use" "More and more useless functions", or even "updating too frequently (giving 1 star)", etc, some recent scores are estimated to fall below 4 stars on average. These complaints should be regarded as the final assessment criteria for quality management, because the downloader will undoubtedly decide whether to install software based on these evaluations, instead of looking at the "thousands of defects" "number of defects discovered by testers ".

Cost:

"Actual product input and output" is suitable for a long front.

Imagine if it is mobile phone R & D, we should do a good job in testing, maintenance, refresh system and other interfaces during the development phase. In addition, we should optimize the performance to choose low-end hardware; otherwise, the entire product would be extremely difficult to guarantee profitability.

In addition, if the software is well performed (but the R & D cost of the software is increased), it can save some hardware resources or reduce some dedicated hardware. At this time, it is difficult to assess the software department and hardware department separately.

Requirements:

The actual data of an ERP company consulted on "number of pending requests per month". If the data is large during the trial sales process and degrades slowly (in line with the Ruili distribution ), it indicates that the product is inconsistent with the customer's requirements. It is estimated that some usability factors can also be presented.

Customer screaming rate (customer screaming rate) is an iconic performance indicator of Apple's success. It does not need to talk about the demand, because it must surpass the demand. It is difficult to learn this, but it is necessary to understand and reflect its spirit.

"Matching of software and hardware requirements" is suitable for the consumer electronics. For example, if the hardware and software R & D are parallel, the software and hardware delivered in the final delivery product should match, however, "of the 18 functions, 12 hardware and 13 software are completed, but 6 are not overlapped (that is, these functions cannot be delivered )", in this way, the software and hardware department will work together.

A mobile phone manufacturer is very good at the previous one. Among the 200 projects in a year, there are only three extensions, which are good at using the feature sorting-Software and Hardware Alignment Method, and sacrificing secondary features to ensure time-to-market.

Project development

There are many products and few projects. I dare not say more. Please add it!

The purpose of setting external performance goals for the team is to align the different roles, processes, and personnel objectives of the team, so as to help each other improve the common performance.

Most external targets can be clearly perceived by customers, users, or the market. Their increase almost means an increase in revenue. If you want to pay a bonus when the tester finds a bug but finds that there is no money in the account, you can change it to the time when the customer seldom complains. At that time, the Account must have money.

 

Note: This is an old article. Because it complies with the content of this series, it will be edited and published here after a great change.

 

 I am participating in the csdn blog Star Selection. If I like this article after reading itArticle, Welcome to vote:Http://vote.blog.csdn.net/item/blogstar/cheny_com

 

Click to download the free agile development textbook: Martian agile development manual