> <mailto:
eric%40domainlanguage.com>> wrote:
>
> > I think it is important to distinguish the various roles that a
> > business
> > person can play in a software project.
> > There are three that are particularly important:
> >
> > *Customer/Stake* holder (ok, these are not exactly the same)
> > These are people who have responsibilities for defining scope,
> > choosing
> > the features to be developed, etc. This is connected to paying for the
> > development.
> >
> > *User*
> > This is a person who actually uses the software on a regular basis.
> > This
> > role is essential for usability of the UI. This person is usually
> > not a
> > Customer. This person may or may not be a domain expert.
> >
> > *Domain Expert*
> > This person may or may not be a Customer. May or may not be a User.
> > What
> > this person must be is someone who works in the field, and has done so
> > for quite a while, in a capacity that gives him/her some breadth of
> > understanding. So a clerk who has worked in a business for many years
> > might be a good User, but not a good Domain Expert. A Domain Expert
> > can
> > answer questions not only about how the business works, but WHY the
> > business works that way. A Domain Expert is almost never a technical
> > person (including software analysts).
> >
> > The lack of these distinctions leads to the kind of confusion we see
> > in
> > this thread. What Randy was saying is that he had a Customer who was
> > not
> > a Domain Expert. This is fairly common, because Customer is more of a
> > decision-making role, either management or delegated by management.
> > These people may or may not have deep experience in the field. In
> > such a
> > case, you can have Domain Experts who are not decision makers.
> >
> > Most interactions with Domain Experts are exploratory, not
> > decision-making. Often people are afraid to have these meetings
> > because
> > this is not clear. The idea of some programmer brainstorming with some
> > random business expert worries them because they feel they need
> > control
> > of scope. Yes, they do. So it has to be clear who the Customer is --
> > who
> > makes the decisions. Exploration produces possibilities. When
> > promising
> > possibilities emerge, the Customer needs to be involved to make
> > choices.
> >
> > When there is no Domain Expert, exploration doesn't work. Really
> > valuable options never emerge. The Customer chooses something naive
> > and
> > the resulting software is mediocre. It might be "simplistic,
> > brittle ...
> > kludgy, hackish".
> >
> > Don't assume all non-technical people are Domain Experts. You need a
> > Customer, but you need to be sure you have Domain Experts as well. If
> > you are lucky, they are in the same person, but that is not always the
> > case. And often it is useful to have multiple Domain Experts anyway,
> > to
> > provide fresh perspectives and to improve availability.
> >
> > Eric
> >
> >
> > Randy Stafford wrote:
> >>
> >> Adam Sroka wrote:
> >>
> >>> Domain experts shouldn't need
> >>
> >>> to read Fowler. They should keep themselves firmly in the domain.
> >>
> >> If they are able to recognize patterns in the domain, then they are
> >> more expert than otherwise. If not, ubiquitous language breaks down
> >> when the development team sees the applicability of patterns that the
> >> "domain expert" doesn't, and speaks the language of those
> >> patterns.
> >>
> >>> I still can't picture how the customer's understanding of the domain
> >>
> >>> can lead to bad technical designs. Perhaps a naive understanding of
> >>
> >>> the domain leads to a naive implementation, but your description
> >>> of a
> >>
> >>> "simplistic, brittle ... kludgy, hackish" system doesn't seem like
> >>
> >>> something that a domain expert should have the power to create. No
> >>
> >>> offense, but this sounds like a failure of imagination to me.
> >>
> >> No offense, but that sounds like a failure of humility to me. You
> >> weren't there, so you can't speak with any authority about the
> >> situation. When the "customer" / domain "expert" in question
> >> is the
> >> head of product management of an ISV, responsible for specifying
> >> requirements for the company's product, and has no expertise in
> >> requirements analysis and specification including domain modeling,
> >> she
> >> absolutely does have the power to create a system that is overly
> >> simplistic, and not able to implement the behavior required of it,
> >> and
> >> less fitting and useful to the users than it otherwise might be, in
> >> my
> >> considered opinion. "Before you criticize someone, walk a mile in
> >> his
> >> shoes" –Sarah Jackson
> >>
> >> Regards,
> >>
> >> Randy
> >>
> >>
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>
>
RSS Feed