3 ms·

Many times (I'd say most times) it's much easier to analyze a problem after creating a solution for it. Sometimes creating a wireframe of the UI is enough, som

Many times (I'd say most times) it's much easier to analyze a problem after creating a solution for it. Sometimes creating a wireframe of the UI is enough, sometimes the visual component is not that important, sometimes a PoC is needed. That's what it sounds you were asked to do, be part of the analysis of the problem and the search for the right requirements. Through code instead of some other tool, but so what? That's part of the developer's job (the more interesting part of the job, for me). Anybody can implement a perfectly spec'd out form. Maybe even an AI.

Gareth321 5y ago
It's unlikely he was expected or even invited to these meetings. Business stakeholders are often outright hostile to anyone else being part of the requirements gathering process. However, to your point, it sounds like he should have interjected anyway. I have had to force my way into broken feedback loops to shut them down many times. This is one important skill in the PM/PO role: facilitating meaningful requirements gathering and collation - especially when they don't want to play nice.
- BlueTemplar 5y ago
  Then they are going to fail. At the bare minimum you need to have at least one person working both on the technical side and directly with the users, otherwise the risk of making something they didn't want nor needed grows exponentially.
  - anm89 5y ago
    I mean, they are 6 months into designing a single form. The failure is already here. They are actively failing.
- tonyedgecombe 5y ago
  > Business stakeholders are often outright hostile to anyone else being part of the requirements gathering process. I’ve seen that a few times in my consulting days. I’d consider it a giant red flag now. One of them even had it written into their contract, something like “developers should spend as little time as possible with the business“.
anm89 5y ago
Nope, I was specifically not allowed to. I'm not a UI person, and they hired a UI person. I offered to take control of the whole requirements gathering and wireframe process up front and was turned down because they had already hired the CTOs friend to come in as a consultant
- postalrat 5y ago
  Yea, time to leave when things like that are happening.

Gareth321 5y ago

It's unlikely he was expected or even invited to these meetings. Business stakeholders are often outright hostile to anyone else being part of the requirements gathering process. However, to your point, it sounds like he should have interjected anyway. I have had to force my way into broken feedback loops to shut them down many times. This is one important skill in the PM/PO role: facilitating meaningful requirements gathering and collation - especially when they don't want to play nice.

BlueTemplar 5y ago
Then they are going to fail. At the bare minimum you need to have at least one person working both on the technical side and directly with the users, otherwise the risk of making something they didn't want nor needed grows exponentially.
- anm89 5y ago
  I mean, they are 6 months into designing a single form. The failure is already here. They are actively failing.
tonyedgecombe 5y ago
> Business stakeholders are often outright hostile to anyone else being part of the requirements gathering process. I’ve seen that a few times in my consulting days. I’d consider it a giant red flag now. One of them even had it written into their contract, something like “developers should spend as little time as possible with the business“.

anm89 5y ago

Nope, I was specifically not allowed to. I'm not a UI person, and they hired a UI person. I offered to take control of the whole requirements gathering and wireframe process up front and was turned down because they had already hired the CTOs friend to come in as a consultant

postalrat 5y ago
Yea, time to leave when things like that are happening.