[mienski]

As someone that spends most of their days at the design/scoping phase, then watching the product go into development where it encounters constant misunderstandings and gotchas that the customer never told us about or never realised themselves, I completely agree that there is a huge disconnect between the scoping and requirements phase and the build phase.

I almost have guilt over feeling like my work of design and scoping is effectively useless to a developer, all my mockup layouts have to be built ground-up, my requirements aren't actionable in any way unless they feel like reading them (I try to keep them as succinct as possible, but the nature of working for clients also means I have to be somewhat specific so that people know when they should actually pay us). I've looked into things like Cucumber (https://cucumber.io/) so that my requirements can actually be compiled as tests, but adoption is slow and arduous, and all I'm really doing is adding more work to a dev.

My latest line of thinking is that I need a way to show the user interface, and then the data flow and logic all the way back through the system (usually a back-end DB or a customer legacy system). It's vital that these are presented together, hence my current process is interactive mock-ups built in Sketch (https://sketchapp.com/) and hosted on Invision (https://www.invisionapp.com/) which allows the customer and developer to click around and see it on a mobile screen so they really get a feel for it. Finally I couple that with a BPMN diagram which has swim lanes not just for the traditional system swim lanes, but also for a user (i.e. User taps Submit) and for a user interface (i.e. shows the mockup screen that is displayed), and then the logic flows down through the diagram. (e.g. User, User Interface, Mobile App Logic, Server Logic, Server DB, etc.)

[beaker52]

Can I suggest you involve your entire team in the discovery phase, meaning talking to the customer and interacting with the problem from the very start?

Shared understanding (passing what you've learnt on behalf of the rest of the team doesn't count) can help everyone, (including the customer!) understand the whys, whats and hows of their own problem space. Then as a whole team you can come up with and vet the solution - qualified by the deeper understanding everyone in the team has.

This deeper understanding will help you arrive at a better solution, wasting less time building the wrong thing and reduce the friction in "handing-off" to development (because there isn't a hand off).

[roel_v]

This here. Having someone who doesn't have to social skills of a house plant to talk to the customers, and then have the neckbeards in the back room code it up, is not the way to go, and nowadays I refuse to work with partners who work like this (or with subcontractors who want to force this workflow on me, and not limited to software dev either - I no longer work with e.g. building contractors who work like this either). And yes, I understand the point of specialization and division of labor, and yes in the past I too would have much preferred to just be the guy being handed perfect specs and never having to talk to anyone from the outside, and then when things go wrong there is always 'the spec' to blame. But it just doesn't work that way. In the past, being a 'business programmer' was called being an 'analyst-programmer'. I never really understood that, until I got to a point where I realized that the actual 'programming' (i.e., 'coding') is the easy part; it's the 'analysis' of the problem (well, and the formulation of a solution to the problem that comes out of that analysis) is the key to delivering value. But still, the relationship between the problem understanding, the solution and the implementation of that solution is so close that you just cannot completely separate them.

I interviewed a bunch of firms for building a website last year; nothing particularly fancy. Several of them (at least the big firms) send in a guy who would always start off explaining their 'process' (all fancy sounding), that process essentially being 'you tell me what your problem is, then we will together design a solution, and then I'll hand you off to our project manager back at the office who will just have the programmers implement it; you'll never even have to see these guys face to face!'. Uh sure, probably to 95% of your customers, naive and gullible because of lack of experience, that sounds great and like it's an advantage, but no way I'm going to get caught with my pants down 6 months from now because there was some aspect we didn't cover in the 'design' but the programmers coded it up like that anyway because hey it say so in the spec, right?

[pbowyer]

> My latest line of thinking is that I need a way to show the user interface, and then the data flow and logic all the way back through the system (usually a back-end DB or a customer legacy system).

Yes, this. It's what I've wanted as a software engineer and as a product manager. A unified overview.

I find the project materials become siloed, and cross-referencing is time-consuming, error prone, and not done enough. There is often a written spec, and a separate set of wireframes, with clickable areas to show interactions. Those two need to be merged together. Then a bunch of JIRA tickets, again separate. These need to be associated with the wireframes and the spec.

I have yet to find any system that makes this work.