5 ms·

From software development classes in School to University, we were told the most powerful method of requirements gathering was observation. Yet in my whole pro

From software development classes in School to University, we were told the most powerful method of requirements gathering was observation. Yet in my whole professional life I've never had a chance to do it despite putting the idea forward. One of my old colleagues who managed to observe a client was met with hostility and questions from the people he was observing. Other times clients want to dictate and have no dialogue in defining requirements.

freedomben 8y ago
I once was in a position where I could observe, and I can confirm that: > the most powerful method of requirements gathering was observation. But the vast majority of my time has been at companies where engineers are never cleared to travel to meet with customers and gather information. It's insanity IMHO. It was the one bright spot about doing contract wor.
vishnugupta 8y ago
Agreed. The problem though is that university curriculum hasn't caught up with the reality yet which is a role called 'Product Manager'. While I was in college there was a mention of 'System Analysts' whose job was roughly matched that of product managers of today. In general though, I doubt any reasonably sized company will let engineers gather requirements. The divide between product manager and engineer has only hardened over last few years or so.
ken 8y ago
When I was developing internal software at a big company, I went to observe some actual users at the company. (I thought what we were building didn't make sense, so I wanted to see if they actually used it that way.) I got a tongue lashing from management for that one! "You're a developer. You're not supposed to talk to users." The entire project, of course, was eventually cancelled.
- maxxxxx 8y ago
  I see that a lot too. There are a lot of well-paid managers whose only role is to be middlemen between engineers, customers and other departments and they protect that role jealously. I agree that some developer probably shouldn't be talking to customers but overall they should. I have had many occasions where we received a spec and after discussion with users quickly saw how we could meet their needs in a much simpler way than the middlemen had come up with.
- gaius 8y ago
  The entire project, of course, was eventually cancelled Been there, done that. Once spent months working on a project but when I finally got to talk to the users they told me it didn’t do what they wanted and even if it did they wouldn’t change their working practices (union rules maybe?) At the end of the year the manager who had assigned me this project dinged me on my appraisal for not having delivered it.

freedomben 8y ago

I once was in a position where I could observe, and I can confirm that: > the most powerful method of requirements gathering was observation. But the vast majority of my time has been at companies where engineers are never cleared to travel to meet with customers and gather information. It's insanity IMHO. It was the one bright spot about doing contract wor.

vishnugupta 8y ago

Agreed. The problem though is that university curriculum hasn't caught up with the reality yet which is a role called 'Product Manager'. While I was in college there was a mention of 'System Analysts' whose job was roughly matched that of product managers of today. In general though, I doubt any reasonably sized company will let engineers gather requirements. The divide between product manager and engineer has only hardened over last few years or so.

ken 8y ago

When I was developing internal software at a big company, I went to observe some actual users at the company. (I thought what we were building didn't make sense, so I wanted to see if they actually used it that way.) I got a tongue lashing from management for that one! "You're a developer. You're not supposed to talk to users." The entire project, of course, was eventually cancelled.

maxxxxx 8y ago
I see that a lot too. There are a lot of well-paid managers whose only role is to be middlemen between engineers, customers and other departments and they protect that role jealously. I agree that some developer probably shouldn't be talking to customers but overall they should. I have had many occasions where we received a spec and after discussion with users quickly saw how we could meet their needs in a much simpler way than the middlemen had come up with.
gaius 8y ago
The entire project, of course, was eventually cancelled Been there, done that. Once spent months working on a project but when I finally got to talk to the users they told me it didn’t do what they wanted and even if it did they wouldn’t change their working practices (union rules maybe?) At the end of the year the manager who had assigned me this project dinged me on my appraisal for not having delivered it.