At best, it's "reverse engineer it, tell me what it does, and then I'll tell you what feature I'd like changed."
We're often not experts in the domain we're working on, but by asking questions about a user's workflow on a more holistic level, we probably have more insight into what workflow would be the most productive from a systems standpoint.
Of course, this is a back-and-forth. Sometimes users aren't sure of what they want. And sometimes we're not sure of what is the "best" system for what the users want.
Instead of asking the user where the button should be, ask them when they press the button.
It's no panacea, but it helps because it tries to prevent the business people dictating tech specifics, which the developers take too literally.
For example, a business person says "when I press the submit button the results must be stored in MySQL". What they really mean is that whatever they entered into a form must be accessible later, but the developers now believe they must use MySQL and have submit buttons.
By focusing on the "When I complete the form with data x, when I look at the form again later, then I see data x" you've moved the conversation to the business requirements and away from the perceived technical requirements.
(not hating on modern PHP, just its reputation and 'outsourceability')
For example, the ticket might look like "When I submit the form, then the DB Analysts are able to run reports on the submitted data".
I have worked with many companies where this was a very hard business requirement. Companies that dont care how the data is stored tend to be pretty small or not actually care that much about the data.
> For example, a business person says "when I press the submit button the results must be stored in MySQL". What they really mean is that whatever they entered into a form must be accessible later, but the developers now believe they must use MySQL and have submit buttons.
So in other words business people are plain old lying about the requirements.
One minute of googling can be expected from BAs, too.
> They're phrasing the requirement in terms of their best understanding of the implementation.
Then they should say "to my knowledge MySQL is a popular database that I know of and is to my knowledge used a lot in the company, but if you know of a better implementation (I don't know much about that - I'm no computer scientist) use it instead.".
Giving an exact specification is a statement that you want it this way. It is a property of an executive position to give correct instructions to the subordinates. If they are not capable to do that they are simply not qualified for their job. On the other hand: If you want feedback for your specification, ask for it. Giving instructions means "you implement it this way and I am personally responsible with my honor that this is indeed what is needed".
By the time you're having this conversation with a BA, the DB is not going to be changed because they made some offhand reference to a different DB. They said something technically wrong, but in a way that doesn't have any meaningful effect on what they were trying to say: as such, to nitpick a detail like that may give the impression of trying to reinforce your superiority by pointing out tiny technical mistakes in their speech. So just let it go :)
Customers have a problem to solve, and try to ask for something to solve that problem. Understanding the problem and proposing a solution (and a price) is how you get happy customers.
https://youtu.be/BKorP55Aqvg is a great example of how to fail at this. The "expert" totally fails to understand the customers needs, and instead gets hung up on bad definitions. He's supposed to be the expert in drawing lines, so he should be able to understand why they need them. You could say the customer is lying about their requirements, but they probably just don't understand them.
This goes for any customer/provider relationship - internal services, it departments, platform enginners. Not just selling stuff to other companies.
To build on the example from https://news.ycombinator.com/item?id=12428337: If another person says "MySQL" it is MySQL and nothing else. If they meant something different, he would say "data store" or give some non-technical description from which a technology-minded person can reconstruct what the person really wants. The same holds for the "submit button". If the person talks about a "submit button", such a button is meant. If he means something else, he would give a description, say "a user interface element which allows to send the data that I have inputted to the central data store such that [...] Choose the technology which is best according the current UI/UX guidelines.".
If I don't know what I want I give the information in a high-level way such that an expert can reconstruct/build the missing details. If I say some concrete technology that is an exact specification. If this is not what you want, it is lying. There is no in-between.
https://www.youtube.com/watch?v=B7MIJP90biM
The customers might even be happy with it, because it would mean they wouldn't have to admit their requirements were stupid.
I personally prefer it to be instructed when my requirements are stupid (if there really is strong evidence that they are) since this way I can learn in a much faster pace to make good requirements.
is a particularly awesome idea for specifying behavior. really want to try it out for a project sometime: the idea is to write the spec in these domain-specific "gherkin" files.
i find it comparatively difficult to get get buy-in on collaborating on anything machine-readable, however, unless it's from people who are comfortable with general-purpose programming languages, anyway.
nonetheless, in an industry where it's fairly standard for designers to build in domain-specific languages, i don't think it's an unreasonable skill for product managers to consider acquiring.
any user experience stories from cucumber, etc. on rewrites or otherwise?
Absolutely no business person who is responsible at the level BDD works (the head of marketing for example) ever ever ever writes a working BDD description or frankly bothers reading them.
Maybe just maybe they are useful intermediaries for Business analysts but most of those have been fired.
Fitnese tests have more traction but then this is just exposing your API for user tests
yep, if (and it's sounding more and more like "when," even outside of my anecdotal experience) that decision is made, there's not much point in using cucumber or similar.
i was kind of hoping someone would say, "yea, our product manager writes domain-specific specification files, and the workflow is so much easier!" ... but no, i'll just continue being mildly cynical a/b the role of developers in industry.
"it does this when anyone clicks a button."
whereas there's often some implicit question, like
"what happens when two people click the button at the same time?"
and that kind of concern -- where the logical implications of requirements -- is not always handled by top-down requirements management... i'm almost certain i saw a fowler article on "conversational" requirements management recently, and that made a lot of sense.
I find that it helps, but it doesn't solve the whole problem. The most useful bit is the stories with examples, as those are what are so often missing from specs.
The problem with edge cases is that they are infinite. If there's an edge case that's likely to happen (ideally based on evidence of past behaviour), then it can either be in the spec or just in functional tests.
I like to think that BDD is like writing the documentation first. Would you put the edge case in the documentation? If not, it probably isn't the BA's responsibility to decide what should happen, and it shouldn't have a Gherkin-style story.
But it's not a silver bullet. It's a tool that helps solve some problems on some projects in some teams. Usually, it helps in cases where the domain experts are not very technical and where the domain problem is a fairly simple set of business rules.
1. The value of BDD is that you have some stories with examples written in the language of end users. You can use a tool like Behat or Cucumber that parses those stories and runs them as automated tests, but it's not fundamental, and you shouldn't avoid using BDD just because the automation aspect is too difficult.
2. Avoid using Behat to interact with the browser, make HTTP calls or run command line scripts. Otherwise your features become too tightly coupled with your views. Use Behat to test your services and domain entities directly, and not to test the framework, because testing the whole application (including the framework, if you're using one) is slow and wasteful. If you want to automate the browser, there are better/faster options than Cucumber and Behat.
3. BDD features are not the same as functional tests. Your features should focus on the typical use cases and read like end-user documentation, while your functional tests should include edge cases and should be optimised for developers.
Our "tests" are all written by "tell me what to click" QA, and the Behat source is literally commented-out because they cannot be run by programs, only the QA who made them.
Or your "product owner" doesn't really know the product and happens to be in a minimal-overlap timezone, and walking to the other side of the local office to ask Real-Users for feedback eventually generates a subtle reprimand about going through proper channels...
Yeah, not planning to stick around.
One of the red flags I started to notice was where the client liaison had only been working there for a couple of weeks or months.
In general they are completely unable to describe the job and problems they solve for the company, only how they use the software day to day, with out significant coaching and reframing.
This does out some burden on documenting what you did after the fact, but it beats the method of locking yourself into something that's wrong to begin with.
The developers who can get enough domain knowledge to intuitively understand what's needed add enormous value. They can credibly suggest better ways to operate. I refer to it as the second 10X in productivity gains.