4 ms·
Product Requirement Documents Must Die
- throwaway2016a 10y agoTangent to that is... if you are a consulting firm your SoW must have an unambiguous list of deliverables. Not having one is asking for trouble if the client changes their mind or decides they interpret a deliverable differently than you. Or worse, the client got the wrong thing because you didn't ask what they actually wanted.
- typetypetype 10y agoA lot of the issues described here seem like they stem from a lack of good project management. Requirement docs should never go straight from sales / marketing to engineering.
- kafkaesq 10y ago1. Waste. Very little in a product is actually required 2. They focus on solutions, not problems. Sounds like he's been in too many environments completely lacking in adult supervision, where no one seems to know the ABCs of writing good design documents (of any stripe). I find it's just that hard to teach the basics, and once people get points 1 and 2 (which, as he correctly identifies, are huge) things work out much more smoothly for all concerned.
- flukus 10y agoThe worst I see is that the requirements come from management who are "sponsoring" the project. The have no clue how their employees do their jobs or even what their jobs are, yet they make crucial decisions on how the software to do them works.
- rurban 10y agoA PRD is not really required with a single team. A URS (user requirement spec) is mandatory, which goes from the PM to the dev team. A PRD might be useful with multiple, possibly remote teams. Esp. India or China, because with problems they usually play hardball down to the spec and nothing more. Right so. But it's the dev team management job to come up with that.