3 ms·

I have been working as a DWH developer for a few years but I retained the role of sole requirements taker for the whole company. IMO there are two difficulties

I have been working as a DWH developer for a few years but I retained the role of sole requirements taker for the whole company. IMO there are two difficulties I found to be particularly hard to break through. One is for business users to clearly state their requirements once and for all. The other is for me to fully understand what's going on on the developer's side. Solving the first one is easier for me because eventually everyone agrees that requirements can be staged. With enough experience in BA I kinda anticipate each stage and make sure that the later stages do not conflict with earlier stages. Solving the second one is a lot harder because I have to learn a lot of programming buzzwords. I need to understand micro services and read service charts. I also need to know how the app uses the services. Overall it's a tough job. Fortunately I can arrange meeting with developers so that we would go through each one and make sure the current architecture supports it. It's a lot of extra meetings but it's a hell lot better than extra fire fight meetings.

rocqua 5y ago
Interesting, being from the technical side, I feel the opposite. It is easy to see the long term technical implications of a requirement, but hard to figure out what the users actually want. I sort of figured this was an inherent problem. Users won't know what they want until they get to try something, I figured. Interesting and surprising to see that someone else, with a different background, has little trouble with the users
- Gareth321 5y ago
  You've both explained why the job is so hard, and hard to fill: a competent PM/PO must speak both "business" and "tech" fluently, without being experts in either. In my long years I've found some people speak business very well, and they're promoted. Some people speak tech very well, and they're promoted. To find someone who speaks both languages well and wants to spend their lives translating between two camps which often times don't even want to understand the other side is demanding and difficult. We often end up taking all the heat with misunderstandings, requirement conflicts, capacity constraints, and priorities. Such a candidate is usually earning as much or more in their respective camps, with comparatively lower levels of stress.
- markus_zhang 5y ago
  I guess it depends on the background. I came from BA so I implicitly know everything the business wants(and still have to break them into phases). I completely agree with the second paragraph. Sometimes users have no idea what the real data looks like so have to wait. But there are other cases when they see additional data that can be useful if a bit of new data is added, which results in ad hoc requirements.

rocqua 5y ago

Interesting, being from the technical side, I feel the opposite. It is easy to see the long term technical implications of a requirement, but hard to figure out what the users actually want. I sort of figured this was an inherent problem. Users won't know what they want until they get to try something, I figured. Interesting and surprising to see that someone else, with a different background, has little trouble with the users

Gareth321 5y ago
You've both explained why the job is so hard, and hard to fill: a competent PM/PO must speak both "business" and "tech" fluently, without being experts in either. In my long years I've found some people speak business very well, and they're promoted. Some people speak tech very well, and they're promoted. To find someone who speaks both languages well and wants to spend their lives translating between two camps which often times don't even want to understand the other side is demanding and difficult. We often end up taking all the heat with misunderstandings, requirement conflicts, capacity constraints, and priorities. Such a candidate is usually earning as much or more in their respective camps, with comparatively lower levels of stress.
markus_zhang 5y ago
I guess it depends on the background. I came from BA so I implicitly know everything the business wants(and still have to break them into phases). I completely agree with the second paragraph. Sometimes users have no idea what the real data looks like so have to wait. But there are other cases when they see additional data that can be useful if a bit of new data is added, which results in ad hoc requirements.