Diff for "OrgPatterns/Engage Customers"

저자 중 한 명의 친구가 대규모 시스템을 위한 사용자 인터페이스를 설계하고 구현한 적이 있다. 그는 고객에게 어떻게 그것을 유용하게 만들지에 대해 의견을 받았다. 안타깝게도 요구사항 작성자는 다른 생각을 가지고 있었고, 고객이 요구하는 기능을 제거했다. 그러나 고객은 누락된 기능을 요청했고, 요구사항 작성자는 결국 이를 받아들여야 했다. 내 짐작으로는 그것이 내 친구와 요구사항 작성자 사이의 관계에 도움이 되지 않았던 것 같다.

... 조직이 확립되어 있고, 그것의 QA 역할이 일반적으로 모양새를 갖추었고 승인되었었다. QA 기능은 업무를 추진하기 위해 입력이 필요하다. 기업의 많은 사람들이 품질에 대해 신경을 쓰고 있다.

✥ ✥ ✥

It’s important that the development organization ensures and maintains customer satisfaction by encouraging communication between customers and key development organization roles. This isn’t the responsibility of any single “customer satisfaction” organ, but the need pervades the entire organization structure. Most organizations are averse to direct contact between developers and customers, fearing that the developers are “loose cannons on deck” who will promise to deliver things that go beyond the scope of a job.

개발조직이 고객과 주요 개발 조직 역할 간의 의사소통을 장려하여 고객 만족을 보장하고 유지하는 것은 중요하다. 이는 단일한 "고객 만족" 기관의 책임이 아니지만, 요구 사항은 전체 조직 구조에 퍼져 있다. 대부분의 조직은 개발자와 고객 간의 직접적인 접촉을 싫어하며, 개발자가 작업 범위를 넘어서는 것을 제공하겠다고 약속하는 "돌발행동을 하는" 사람이라는 점을 두려워한다.

Yet you can’t know all the requirements up front, so developers need to keep going back to customers for more information—and customers need to keep coming back to developers with their insights, particularly when developers BUILD PROTOTYPES (4.1.7). Requirements changes occur even after design reviews are complete and coding has started.

그러나 모든 요구 사항을 미리 알 수는 없으므로, 개발자는 더 많은 정보를 얻기 위해 고객에게 계속 돌아와야 한다. 특히 개발자가 OrgPatterns/Build Prototypes를 할 때, 고객은 그들의 통찰력을 가지고 개발자들에게 계속 돌아와야 한다. 설계 검토가 완료되고 코딩이 시작된 후에도 요구사항 변경은 일어난다.

Many organizations depend on their marketing organization to provide requirements and needs. But marketing doesn’t provide design data (BeyerHoltzblatt1998], p. 30). The best that marketing can do (or should do) is to understand what will sell and why people will buy what you want to sell. Designers in turn must understand how people will use the product in a way that creates value for them. Good value sometimes leads to good market potential, but marketing usually looks at other factors (brand name recognition, product name and posturing n the market) about which designers care little.

많은 조직이 마케팅 조직에 의존하여 요구사항과 필요를 제공한다. 그러나 마케팅은 설계 데이터를 제공하지 않는다. 마케팅이 할 수 있는 (또는 해야 하는) 최선은, 무엇을 팔지, 사람들은 당신이 팔기 원하는 것을 왜 사는지 등을 이해하는 것이다. 설계자는 사람들이 가치를 창출하는 방식으로 제품을 사용하는 방법을 이해해야 한다.

Missing customer requirements are a serious problem: most problems in software systems can be traced to requirements problems ([Daley1977]; [Boehm1976]). Yet it seems like so much effort to elicit them — which is work that is not directly producing a marketable artifact.

It seems like makework and overhead.

Customers are traditionally not part of the mainstream development, which makes it difficult to discover and incorporate their insights. Yet customer contact correlates with project success [KeilCarmel1995].

Trust relationship between managers and coders are often strained, so you don’t want them to be the sole intermediary between developers and customers.

Therefore:

Closely couple the Customer role to the Developer and Architect, not just to QA or marketing. In short, developers and architects must talk freely and often with customers. When possible, engage customers in their environment rather than brining them into your environment.

Two things are necessary for this to happen: opportunity and culture. Developers must have the opportunity (and the means) to communicate with customers. They should meet customers personally to establish trust and free flow of communication.

But these visits will be superficial if the organization culture builds walls between customers and developers. In particular, if system requirements must go through a lengthy formal process to be approved, the developer will be hamstrung — unable to respond to customer requests. Therefore, the organization must develop a culture where developers have some latitude to respond to customers. This is not saying, however, that all control of requirements should be relegated to the developer. Order is necessary.

Beyer and Holtzblatt note that “many common ways of working with customers remove them from their work.” ([BeyerHoltzblatt1998], pp. 36-7). One way to help this is by “putting designers and engineers directly in the customer’s work context” ([BeyerHoltzblatt1998], p. 20). This is particularly important if you are using customer engagement to create wholly new market directions for the enterprise, rather than refining existing work. Putting developers in the customer work environment also trains developers’ intuition about good design and good human interfaces, and this intuition can fill in when specific detailed requirements are unavailable [BeyerHoltzblatt1998], p. 35).

Language is a key element of culture that can smooth customer engagement if treated properly, and smother it if treated badly. Don’t make your customers learn UML or other technical notations; do your best to learn their language and to communicate with them in the terms of their culture.

QA can monitor the relationship to keep the direction within contractual business limits, while allowing a free flow of insights back and forth between developers and customers. Such communication can often flow unimpeded; however, see the pattern GATE KEEPER (4.2.10). Note that this pattern is all about relationships and culture. It is the culture of respect for and communication with customers that makes the communication effective, for example, during the writing of use cases, as described in PARTICIPATING AUDIENCE (10.5.20) ([Bramble2002], p. 35).

✥ ✥ ✥

This pattern supports requirements discovery from the customer, as required by SCENARIOS DEFINE PROBLEM (4.2.8) and BUILD PROTOTYPES (4.1.7). Other patterns like FIRE WALLS (4.2.9) also build on this pattern. The pattern RECOMMITMENT MEETING (4.1.12) is a more formal derivative of this pattern in a different context.

A good understanding of customer needs can avoid rework after implementation is done. While it is also important to continuously engage customers through each development episode of iteration, early understanding helps launch the effort in the right direction. A Navision project in Copenhagen felt that improvements in customer engagement helped save time on their development schedule (from a draft pattern “Scandinavian System Development” by Flemming Pedersen, 24 January 2002).

This was a strong pattern in the Borland Quattro Pro for Windows case study. Also, see [Floyd1992] and in particular the works of Reisin and Floyd therein.

Some processes and methods are founded on customer engagement, such as IBM’s Joint Application Development. Other methods are conducive to customer engagement, such as Cunningham and Beck’s CRC design technique. Other methods, and especially most CASE-based methods, are indifferent or harmful to customer engagement. Even some of the best customer engagement techniques tend to stop once they achieve some level of contractual agreement about what is to be delivered. Customer engagement in agile processes goes far beyond that. Developers need to assimilate the context in which their product will be used: this is called contextual design. Contextual design means gathering data on customers’ models of how they do their work rather than creating models of how the program will solve the problem. Use Cases are about the latter; contextual design is about the former. See [BeyerHoltzblatt1998].

The pattern is “ENGAGE CUSTOMERS”, in the plural, to support a domain view and to avoid being blind-sided by a single customer. The project must be careful to temper interactions between Customer and Developer, using FIRE WALLS (4.2.9), GATE KEEPER (4.2.10), and the QA organizational presence as in ENGAGE QUALITY ASSURANCE (4.2.29). A big part of interacting with the customer is to learn how they want to interact with the project as the unfolding software uncovers problems in requirements and systems engineering (see APPLICATION DESIGN IS BOUNDED BY TEST DESIGN (4.2.30)).

Note that “maintaining product quality” is not the problem being solved here. Product quality is only one component of customer satisfaction. Studies have shown that customers leave one company for another when they feel they are being ignored (20% of the time), or because the attention they receive was rude or unhelpful (50% of the time). For customers having problems that cost over $100 to fix, and the company does not fix it, only 9% would buy again. 82% would do business with the company again if the problem was quickly resolved after they complained. (The source for the former pair is The Forum Corporation; for the latter pair, Traveler’s Insurance Company [ZuckermanAndHatala1992].)

Joe Maranzano [Maranzano1992] notes that this pattern probably should come earlier in the language. However, it is important that the project roles be defined first—particularly those that interact with the customer, and those that are driven by customer input (such as Quality Assurance). Said in another way, the organization exists to serve the customer, so the organization should be in place before the customer is fully engaged.

This pattern works only if customers are directly accessible to the development team. If that is impossible for business reasons or because of geographic separation, consider SURROGATE CUSTOMER (4.2.7).