Diff for "OrgPatterns/Engage Customers"

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

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

✥ ✥ ✥

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

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

많은 조직이 마케팅 조직에 의존하여 요구사항과 필요를 제공한다. 그러나 마케팅은 설계 데이터를 제공하지 않는다. 마케팅이 할 수 있는 (또는 해야 하는) 최선은, 무엇을 팔지, 사람들은 당신이 팔기 원하는 것을 왜 사는지 등을 이해하는 것이다. 설계자는 결국에는 사람들이 그 제품을, 그들에게 도움이 되도록 가치를 창출하는 방법대로, 어떻게 사용할지 이해해야 한다. 좋은 가치는 때로는 좋은 시장 잠재력으로 이어지지만, 마케팅은 일반적으로 설계자가 거의 관심을 갖지 않는 다른 요소(브랜드 이름 인지도, 제품 이름 및 시장 위치)를 고려한다.

누락된 고객 요구 사항은 심각한 문제이다: 소프트웨어 시스템에서 대부분의 문제는 요구사항 문제로 추적될 수 있다. 그러나 그것들을 이끌어내려면 노력이 너무 많이 드는 것 같다 - 이것은 직접적으로 시장성 있는 산출물을 생산하지 않는 작업이다.

그것은 불필요한 작업, 오버헤드처럼 보인다.

고객은 전통적으로 주류 개발의 일부가 아니기 때문에, 통찰력을 발견하고 통합하기가 어렵다. 그러나 고객 접촉은 프로젝트 성공과 상관관계를 가진다.

관리자와 코더 간의 신뢰 관계는 종종 껄끄럽기 때문에, 그들은 개발자와 고객 사이의 유일한 중개자가 되는 것을 원하지 않는다.

따라서:

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.

고객 역할을 QA 또는 마케팅 뿐 아니라, 개발자 및 아키텍트에게도 밀접하게 연결하라. 간단히 말해서, 개발자와 아키텍트는 고객과 자유롭게 자주 대화해야 한다. 가능하면 고객을 당신의 환경에 데려오기보다는, 고객의 환경에 대면하라.

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).