The hardest thing about engineering is requirements
jaybs.medium.com
jaybs.medium.com
As a PM I’ve seen my fair share of “PMs are useless waste of space”.
The article doesn’t directly talk about PMs but the role of gathering AND properly unambiguously articulating them is extremely important. It happens to be the primary job of a PM.
The challenge is that the difference between bad or poorly written requirements and well written ones isn’t immediately obvious. And the skill and effort required to go from writing okayish requirements to good ones is high. You need to take in to account: actual customer problems, business need, future roadmap, market and cultural shifts amongst other things. Heck, deciding whether this is a problem worth solving itself isn’t easy and frankly a step many people skip.
My take is that a good Product manager is worth their weight in any ridiculously rare metal you care to name. They will act as a force multiplier for the dev team.
But a bad product manager will poison the well, make bad products and be out of sympathy with the code and tech.
And as it is very hard to tell the difference, well why not play it safe?
I had a PM leave on me at my last job. It took 3 months to get a new PM. That meant all the PM work fell on devs for a while. Believe me, I could tell that both my old PM and the new one were good PMs after that experience.
A good X is worth their weight. Sure, any good professional is always welcome, but in regular team in a regular company, regular PMs are mostly dead weight (in contrast, regular devs are just good-enough devs).
On the flip side, I've worn many hats and it feels like one of the most impactful places to be in a business. I get to shape what we build, and see it to completion. Very satisfying, but not easy.
On the other hand, the effective ones have always had way fewer product managers with a lot more individual authority, who are in charge of the overall product direction but will let the rest of the team execute it to completion.
The problem is usually I choose solution which is easiest to implement and usually the scope is too tight because I need to also design the lower api and libraries.
Even though I think I am someone who understands the customer/domain pretty well, and is good at empathizing with the user, you're just too close to the implementation to effectively product manage.
In the domain I work in, I think people are used to the "head implementer" being the effective product manger (although without that title), and it takes some work to try to convince decision-makers, please, let's not do that.
Product managers are really business managers. Their goal is to ensure the software meets a business need that can help the firm developing it translate the value it delivers into $ by application of a commercial model.
Put another way - they define the WHAT and WHY, the HOW should be managed by their colleagues in Engineering.
Would be nice to do it in a formal way about taking a massive pay cut
Nowdays I felt just the opposite happening when I worked in Google Ads: PMs getting new feature requests from sales people and pushing down on us with strict timelines, even if we feel that that feature is not the best way to deliver better ads targeting for our customers.
Probably you should just go to a smaller company with less PMs, where the PM/Eng ratio is optimal or too small (or go into higher management)
https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...
Having discovered that it's easier to be self-effacing, the quick way to the top is just to directly contact the sociopaths (who usually just say "yes" to everything).
As for requirements specifically, I believe that to make it easy, they should all be 0 or ∞, which makes it easy to test. In practice, laws of physics will add other limitations, but having a grasp of those will make it easier to articulate the design decision (e.g. we can't make that faster because it's already at the speed of light).
I've always felt that having the dev experience helps. As you're walking through requirements with a client you're also piecing together how it should work.
There's an old joke about posting requirements to a job site: "(1) awesome webapp (2) really useful (3) must make me a billion dollars.
The requirements problem is like that.
Requirements are "gathered." Reality doesn't work like that. They aren't gathered. They're invented. a collection of requirements adds up to a design. Thinking of it as a bunch of requirements leads to designed by committee problems.
Designers need to know the problem space, the materials, etc. The requirements part can't be separated from those, which is exactly what the concept promotes.
I totally disagree. The spec dies not exist. It isn't buried in your customers' brain or your CEO's. It isn't mined. It is invented, one way or another, by those making the damned thing.
The "requirement" for a spaceship is "must travel to the moon." What software requirement mining tries to do is mine Kennedy's mind for the design of the bathroom.
Also, the requirements for a spaceship are only "must travel to the moon" if your customer is a 5 year old child. The real list of requirements is way longer and includes things like "must be compatible with our existing launch infrastructure".
The key problem in obtaining the requirements is not a problem of communication (as the original article states) but in the work that needs to be done by (or with) the stakeholders to figure out the actual requirements. And I'm not talking about making the detailed spec, I'm talking about the big conceptual requirements which often after some proper analysis get a fundamental change of perspective. This is the main issue in making good products. If you simply make a spec for the requirements the stakeholders initially think they have, your success will depend on how much thought and work they have given to choosing these requirements, and often that will be lacking.
Take something like a radio. The person building the electronics to meet the design and sourcing the parts may need to know the requirements around the temperature it needs to operate in. The person handling the internal electronics is very likely different from the person designing the product. The person designing the product will need to know where, when, and how it's used by whom.
With software we often mash the roles into one or a few people. A developer may do all or many of the parts. If we look at other engineering disciplines, aside from software engineering, requirements often make sense.
I was just reminded of someone who had to test PVC piping. It had to meet certain standards for handling pressure. The people do engineered the materials, the thickness of the pipe, and so forth had to know the requirements it needed to meet. They also needed to know the requirements for the size of the pipe so that it would mate with other things. They weren't designing the system the pipes would be used in.
Requirements are often a way to take the design, break it up, and communicate it to others who aren't part of the design. They are also a way to create common interfaces. Both of these are things software designs are often bad at. Sometimes intentionally so (non-standard interfaces create lock-in).
Software requirements encompasses a vast spectrum of best practices and creative problem solving, mediation and imposition, linguistics and invention, details and principles, according to the people and domains involved.
"Make me a billion dollars" may be your objective, and while it may not be an actionable one, it is in fact important to distinguish in your design whether your primary objective is to make money, rather than being a passion project for example. The cost-benefit analysis of various design decisions changes depending on how big a priority profit is.
You may be willing to make decisions that are less profitable, but lead to a better product, when profit isn't your primary objective.
These aren't discrete objects. They're key parts of a formal, or semi formal decision making process, administration systems, management methods and suchlike.
Look... there are outlining methodologies that playwrights or novelists sometimes use. It's fine to use such constructs. What's not fine is trying to build institutions based on them.
It's just not reducible neatly into profit objectives and such. Those are fine tools, but they're not good models of the world.
I'm against framing design as "requirement gathering."
If you're designing, deciding or otherwise doing subjective, creative work don't wrap it up in a fake-discrete process.
Customer feedback is valuable information. It's isn't ore that you refine into cutlery.
> There's an old joke about posting requirements to a job site: "(1) awesome webapp (2) really useful (3) must make me a billion dollars.
> The requirements problem is like that.
Yeah. Someone, in the history of SW had a great idea: requirements must be atomic.
That's why a lot of products break when they are put together.
> Requirements are "gathered." Reality doesn't work like that. They aren't gathered. They're invented. a collection of requirements adds up to a design. Thinking of it as a bunch of requirements leads to designed by committee problems.
They are gathered. They are however, not a collection. They depend on each other. And when this depenfence is missing or left over the engineer will invent it to compensate for the lack of it. Every engineer. In its own way.
> Designers need to know the problem space, the materials, etc. The requirements part can't be separated from those, which is exactly what the concept promotes.
True. But "requirements must be atomic" :(
Requirements in the sense that a customer or higher up might negotiate with a PM aren't atomic like that.
Imo, this is a lot like an engineer blaming the spec and/or demanding a better spec. They're asking to be given a perfect task.
To me requirements aren't gathered, they are 'elicited'.
https://en.m.wikipedia.org/wiki/Requirements_elicitation
"The term elicitation is used in books and research to raise the fact that good requirements cannot just be collected from the customer, as would be indicated by the name requirements gathering. Requirements elicitation is non-trivial because you can never be sure you get all requirements from the user and customer by just asking them what the system should do or not do."
Good leadership identifies issues or opportunities in markets, builds something useful, and most importantly, markets and sells into the domain.
Having worked on both sides, I would say that understanding markets and being able to sell into them makes almost Engineering seem pedantic.
This 'gathering requirements for Engineers' is an 'engineering centric' way of viewing things. I mean you have to take some perspective on it, but I think that the issues is going to revolve around 'the hard part'.
If you're building new Nuclear tech, the Eng. is going to be a 'hard part'.
Otherwise, it's the money, markets and selling that is 'the hard par' and the Devs. are bit more like Construction workers but with more thought in the process.
No it can't A collection of requirements implies many, many possible designs.
Change the team, you get a different design.
A good-quality requirement is _testable_, amongst other things. After the design and construction are complete(-ish), the team should have to show that each requirement is in fact met by comprehensive testing.
Along the way, each requirement should be mapped to elements of the design. So you can (on paper) verify the design meets requirements. And the designer(s) can be confident they are meeting the full set of requirements.
And for the nay-sayers that complain you can't ever adequately elicit the requirements out of the users (or customers), then your engineering process needs to address this risk. See many comments that refer to ways and means to achieve this mitigation.
Someone who grasps why simply adding a new button on the frontend might require a week of backend work because of prior decisions.
I think the problem begins before the 'leader.' The product itself dictates all the downstream consequences, including whether 'requirements' are a problem.
Assuming no fatal management dysfunction, when you're working on a product that has substantial value, enough that the customer is eager to pay for what you're capable of delivering, requirements are straightforward. When you're working on things of low value and the customer won't pay unless they get an ever more improbable gymnastics routine and every tier of stake holder is lying to the other then you starting hearing about 'requirements' problems. The 'requirements' problem severity is a function of where you are on on the continuum between these two products.
If you’re building a real product there’s frequently not even an existing customer and certainly none to “give you requirements”. You need to understand problems to solve and turn those into requirements for a product and if you can do that then you’re not working at a customer giving requirements to a vendor.
One subtly for me is that what you said is 100% true of the parts of the organization which interact with customers, or even design partners who want to become customers. But since not every member of engineering is in that role, the requirements which come back from those meetings still need to be "MVP accurate" and (IMHO) need to specify just as much what it *won't* do as what it needs to do
For example, "customer wants to query for names" is a shitty requirement. Of course they do, we all want search engines for everything, but that's not how software works. Do they want it case sensitive, case insensitive, the ability to indicate by using special search syntax (like "quoted"), do they want "starts with" or "contains" searches, wildcard characters?
Getting to MVP means not building the wrong or extraneous things just as much as building the right things, and only a handful of people bear responsibility for distinguishing between those sets
> The problem is that it is hard to scale.
This is true for everything involving human beings.
not only that but the destructive nature of it was also wonderful to society overall, our living standards skyrocketed to an unfathomable degree during said revolution.
talking about the ecological destruction -while an important aspect- is irrelevant to the argument of scale to meet people wants and needs.
Think about it this way, would you be talking about the ecological destruction in an 1800s meeting to scale up farming and husbandry efforts to meet the demands of that time?
If the answer is yes, then would you be willing to delay/postpone the efforts until there are better technologies that are more ecologically friendly to exist and then accept/allow these efforts?
If the answer is no, then it is , like i said, irrelevant.
I beg to differ. As far as I know we scale up things in order to benefit from economies of scale. And we do so because the 'technical system' underlying our civilization leads us to always want 'more'. J. Ellul, among others, wrote about this.
> i doubt solar panels would've been feasible as a scaling method for energy during that time, much less electric cars, or even less likely, farming strategies and equipment that are ecologically less 'problematic'.
Indeed.
Note: some of those ways (solar panel/electric cars/farming strategies/...) have flaws (bad side-effects), some of them catastrophic, we aren't aware of, but will discover (just as all fossil fuels, which enabled the Industrial Revolution, do have catastrophic side-effects.
> not only that but the destructive nature of it was also wonderful to society overall, our living standards skyrocketed to an unfathomable degree during said revolution.
Claiming that those effects were beneficial is acceptable. However it IMHO doesn't balance the bad side-effects (current climatic challenge). Saving (or enhancing the life) of some doesn't justify creating a major risk for others (later).
> talking about the ecological destruction -while an important aspect- is irrelevant to the argument of scale to meet people wants and needs.
The case may be about obtaining anything (even a population) 'big' without economies of scale (or, to put it bluntly, without a technical system), I doubt so, and our ability when it comes to detect bad future side-effects of selected solutions (IMHO this ability is near zero). That's the reason why I think that what works for humans (and maybe for each and every complex life form) is a society built upon small groups, and more generically that everything that (in our society) works for long and without any major blunder is done by and for such groups. In more than a way L. Kohr showed it.
> Think about it this way, would you be talking about the ecological destruction in an 1800s meeting to scale up farming and husbandry efforts to meet the demands of that time?
I would, indeed.
> If the answer is yes, then would you be willing to delay/postpone the efforts until there are better technologies that are more ecologically friendly to exist and then accept/allow these efforts?
At the time: no, however knowing what I know now I would plead for a very (VERY!) progressive (time and space) implementation (precautionary approach).
> If the answer is no, then it is , like i said, irrelevant.
I understand your point, mine sits on the "let's avoid committing the same error twice" principle.
You may start with the first but the second seems kind of inevitable after some years.
I find there are 2 extremes of developers:
1) Ones that develop very fast (and does not think about what is being developed, sometimes blindly). There is no reward to speak up to ambiguities in requirements, or even mistakes. So the mindset here is "can be fixed", "QA" will find, etc.
2) Ones that develop much slower, overly reviewing requirements, use cases, etc., and spending more time with product / designer throughout development.
________
For those who are team leads, managers, hiring managers, which of 2 above would you prefer?
________
EDIT: I am not a super star coder (more a "jack of all trades"), but I have very good intuition on product so many times I wonder if there is a better job field for me. I would be interested to hear ideas along this path.
There's an alternative mindset here as well: let's get something in front of the users because they don't know what they want (because they gave us vague requirements), and this lets us iterate more accurately.
This is a strategy if you have developers with certain freedoms like talking to users directly vs. having product owners to distill requirements, and more or less running the entire development lifecycle.
I think it's bigger companies where this mentality starts to become pervasive with promos.
A blend of both can well work in a team.
You give Coder 1 projects and in a week they have a working version that starts generating revenue, albeit with cut corners and limited scope. After it bakes for a month or two and we are sure we want to keep this thing, you hand it to Coder 2 to improve quality, integrate with the rest of the stack, etc.
If it was a bad idea you throw it away and C2 never needs to support it.
C1’s fast velocity is largely a product of the high quality codebase curated by C2. C2 is always spending their time on known-profitable projects, thanks to C1. We also make sure C1 and C2 are both involved in deciding what we build and in deciding architecture.
Usually C1 is a more business-motivated type who is excited about the domain. C2 is usually more of a technical purist who is excited about building great software.
On a team with good leadership this is a very powerful combination, everyone is valuable.
If C1 delivers quickly on bad requirements, there is no guarantee that product will make revenue. Ask any startup founder who started building a product before doing market research and validation.
I think when we add the archetypes of "fast but sloppy" and "slow but clean", we end up with more permutations than C1 and C2 since the matrix looks more like:
[ Business Oriented, Technology Oriented Quick/Sloppy , Slow/Clean ]
C1 isn't for fast-but-low-quality. It's for instances where you have a detailed spec. Maybe there isn't much ambiguity. Maybe there is, but you're working with an iterative process or something where building the wrong thing right is ok.
In my experience though, there's a never enough C1 type of work to go around. C2 is always the bottleneck. Requirements, specs, stories or whatnot do not reliably make good sense at the point where someone is actually making thee thing.
So to OP's question, I'd take the C2. Not because you don't need C1s, because you probably already have enough.
I used to work in a place where (1) was called as "Customer Engineering" and (2) as "Product/Standard Engineering" (i was part of this group). The former allows you to hook in the customer and keep him engaged with quick feature deliverables in separate code branches some of which are then rolled into the "master" branch (with due diligence like refactoring, making it robust and more general etc.) after due consultations with Marketing/Sales.
I was a skeptic initially, thinking (1) would be producing crap code which would need extensive rewrite but that didn't happen in reality. They were experienced developers themselves (this is the key for (1) ) and so the code was mostly okay and needed little tweaking. Everything worked surprisingly well.
I believe every Company needs to have these two groups in Engineering.
This isn't, strictly speaking, true. There is nothing in Agile that requires you write "User Stories" at all, let alone this specific style of user story (the "as a _ I want _ so that _" style is called the Connextra template, and it was created as an experiment, not a doctrine).
Alistair Cockburn calls stories, "promissory notes for future conversation." That's it. They can be one word, they can be a sentence. If you're writing anything down in your story, it's to remind yourself of the conversation you had with your team, not to create a contract where you meet the requirements.
If you can't have a conversation with the team, and the team doesn't include a person who has skills to engage with the customer regularly, then yeah, you shouldn't be attempting Agile. Saying "User Stories don't work for teams who can't talk to the customer" is like saying, "A bicycle can't work without both wheels." Duh.
One of the four things, so one full quarter, of the Agile Manifesto is, "Customer collaboration over contract negotiation." [0]
If you need a contract, you should probably rethink something. Either you're not really trying to be agile, or you don't really need a contract, or something very rare and not-normally-your-process is happening.
Honestly, this is probably another case of confusing Scrum with Agile. They are not the same. The author claims to not have much experience with "Rapid Prototyping" (the concept not the tools), and in that sense I would humbly argue that the author, therefore, does not have much experience working on an "actually" agile team.
[0] - https://agilemanifesto.org/ I always feel bad quoting sections of the Agile Manifesto, as I think it's so short it should be read in full every time it's relevant, but it's hard to slip into a comment like this without derailing the remaining part of the message entirely. Please do give it a read, even if you've read it before.
The "Agile Manifesto" is nothing other than commonsense platitudes elevated to (unbecoming) Insight. There is nothing concrete and actionable in it. The "Rhetorical Devices" engaged by its proponents are (from [0]);
1) Unverifiable claims
2) Proof by anecdote
3) Slander by association
4) Intimidation
5) All-or-nothing
6) Cover-your-behind
[0] - https://learning.acm.org/techtalks/agile and Also see Bertrand Meyer's book Agile!: The Good, the Hype and the Ugly.
My response was to your above statements. As is evident, almost everyone of Meyer's criticisms are proven True here.
If you don’t want to be Agile, then don’t. I don’t care. However, if you’re trying to follow Agile principles, there are right ways, and there are less right ways.
It looks like you just want to argue. That’s great, it’s just not for me.
What is this even supposed to mean? To me it seems like (6) indulged in by Agile proponents. At best the "Agile Manifesto" is a exhortation to cultivate a particular "mindset" but there is no Process nor Methodology defined anywhere. Hence there can be no "right" way; everything is made up each of which can be interpreted in many different ways.
My point is to expose the "hollowness" of Agile/Scrum/whatever.
I write my notes on stickies and litter them throughout my desk area according to importance. Some people keep notebooks, you do you.
I mean, I've been taught that the number of development cycles was what the Waterfall / Agile spectrum was about... with an upfront contract without any prototyping being as Waterfall as it gets.
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.
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
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.
Most of the time users will come and say what they want. They basically describe what their "perfect" implementation should look like. But almost never do they describe what needs they have. Or what they really wanna solve with that suggested implementation.
Now we always ask: What's your need?
They can suggest possible solutions/implementation. But that's only a suggestion.
One extra benefit when asking about needs is, the person who implements that feature can better empathize with the user.
In our highly solution-focused (and -driven) societies it is hard to actually see much less adequately express underlying needs[0] to yourself and especially other people. For example I'm very adept at leapfroging over all that 'chit-chat' about observations, feelings, emotions, needs and getting right to the juicy 'objective' of possible solutions, often at the dire expense of my actual needs and making me even more deaf to the needs of the other people involved.
Well, surprisingly a lot of tenacious conflicts aren't characterized by a lack of a set of solutions quite the opposite, they get stuck because of the unwillingness (of both parties) in considering to change one's 'strategies' in order to fulfill the underlying often unexpressed needs (as defined above).
At an impasse there are usually two disregarded meta-strageties at play in order to force a quick 'solution':
(1) My set of strategies had brought me success otherwise I wouldn't be in my advantageous position X so I will continue using them, no matter what.
(2) (At some point) I will say "yes" and ignore (some of) my needs in an attempt to appease.
As it is clear both (desperate) attempts are self-defeating (in the long term).
[0]http://www.transformativeinquiry.ca/TIbook/c4/c4/c4s1.html
I did all of that and sent the report with estimates back to my manager, who responded that I had missed an estimate for one item out. That item was "Code will be of good quality". I responded that all of the code will be of good quality and it would be nonsensical to estimate an amount of time to this one thing as it if was a separate task.
"I'm not not going to write a complete system with bad code and then spend time re-writing it to make it good code."
This story did not end well.
This is not a requirement. This is a wish. To attain code quality you need a good process.
To a software developer, "requirement" has a special meaning. It describes how the software will behave. To most other people, "requirement" is just a regular word with its everyday meaning. It describes something that can't not happen. That something can be anything, not necessarily limited to software features.
(They probably should be able to figure out from context what a software developer is really asking for, though. And one of these things is not like the others.)
They ended up just saying "go get started and we will get you requirements later" to which I said "no thanks" in so many words.
I've happily been relocated to another team. I'm excited to hear how many months /years it ends up taking them to hash out what could probably be knocked out in a single well organized sit down.
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.
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“.
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
And requirements aren't hard because of communication, requirements are hard because they are mostly unknown to everyone involved. While there are "little r" requirements in projects, if I encounter a group/firm/company/culture that puts a capital "R" on the word, I try to stay away. Creating software is largely finding something worth creating, and a process that puts Requirements in the foreground has an implicit assumption that Waterfall actually works.
The essay starts off on the wrong foot and doesn't really go anywhere that hasn't been trodden in countless other articles. Even worse, it ends with "no/low code tools will save us!"
After some cycles of iteration we're usually pretty well aligned about what we're building, and only then do we start coding. Engineering teams sometimes go too fast to punching out code when figuring out requirements could save enormous amount of time, effort, and stress.
Really; a lot of what I work on day to day can be summarized as 'this thing over there needs to be better, or maybe pink'.
Can't give up though; I'd encourage the author to follow their instincts towards prototyping tools. The quicker you have a running system the user can 'feel' (as the author puts it), the closer you are to a shippable outcome.
And yeah PM's are useless wastes of space, but I'm glad they are there to help the rest of us ineffectually get the next Frankenstein up and limping.
I have worked in several positions where there was no project manager.
Doing so massively improved my appreciation for them.
A bad one can be miserable, for sure.
A good one is worth their weight in platinum, though. They drive figuring out user needs vs wants, they prioritize the ever-growing pile of work, and handle any communication that doesn't require developers so the devs can stay focused on the problem of writing the software.
Every time I work on something I try to learn to think like the user, at least a bit. I even had to learn the basics of coal mining once. You could say it was a waste of time for a programmer to learn coal mining. But, it Saved countless hours of misunderstanding and wasted time.
Second best option is when your product owner is a user.
Then all the other approaches are even last place. Imperfect solutions to a problem id rather not have.
Requirements is a communication problem.
You can help your engineering by making sure ideas are correctly named, that definitions stay true to principles and the same throughout the company.
When software is built on immutable principles then it hardly ever needs to change because principles do not change (or they are not principles).
I have worked developing various banking systems. Most of the time it is not requirements that change, it is people discovering they have different definition of something that other people have and the change is to accommodate differences in understanding.
Building the right thing - that's the real challenge :-)
Which I 100% agree with. But it’s not just for engineering, it’s for everyone..
As a young engineer working on bigger institutional projects we followed the classic waterfall processes, fact-finding, system analysis, separating out functional and non-functional, stakeholder mediation and so on. Stuff mainly worked and we had gruntled clients. Although things took many years, and ran over budget, but not too much.
Getting into smartphone related startups after 2000 I saw a wholly different culture. It wasn't just the Agile thinking, but the movement to mobile always-on tech made almost everything part of the maintenance phase. Companies no longer even try to ship finished products. Anything can be added or changed after the product is in the "consumers" (not customers) hands. Time to market and sheer speed of development has changed the requirements landscape.
After 2015 I noticed a far more disturbing shift. Requirements are not even part of the picture. The customer will "have what they are given and like it". Why?
As we know, for many ventures the profitable part of business is not giving value to the customer but extracting value _from_ them to sell to other businesses. The product is merely a vehicle for foisting features upon users who are made a captive audience via lock-in, legislation that mandates products or complexity that hides function.
In this "hostile technology world" any requirements come from parent companies or partners in the rent extraction game, or are dreamed up internally. The job of marketing is to push/sell these features as "necessary and inevitable" and of customer/public relations (if it exists) to deflect disgruntled consumers or assuage their fears and disappointments with empty assurances.
Good intuition with rapid prototyping, as it encompasses the necessary steps of understanding the problem, finding the appropriate solution and presenting it to the stakeholders, all in a relatively low-cost package.
This. I like to say that customers don't have requirements, they have problems they need solved (I hate the buzzword "solutions"). They're non-technical so they don't know what is possible or reasonable. It is up to the PM or lead to propose ways to solve those problems. Another issue is that (this appeared on HN recently) you can't tell people anything, so it's often necessary to show them something before they can really get on board with it. At that point things start to change and people will claim the requirements are changing, when in fact they are just starting to get fleshed-out.
There is a second layer of requirements which are essentially a design. Not design by a designer but an internal software design. The customer doesn't care about this level of requirement but people tend to confuse the two. Some developers ask for too much detail and some customers try to micromanage. It's the PMs job to manage this boundary.
What follows is one way to get requierments right -
¹ Current State
Assess the situation. Understand the transformation (one or more processes) the client seeks to address, and find out what the technology landscape looks like. Start identifying stakeholders, and familiarise yourself with the client's worldview, environment, and the power and political landscape.
² Objective
Identify who the client is, and define the client's objective. The objective is specific, measurable, agreed to by the client,realistic, and time-boxed. It is guided by the results of the situational analysis.
³ Scope
Bound the solution by outlining it's features and functions, by defining what's out of scope, and by discussing the criteria by which success is measured. The scope delineates what stakeholders expect the project to deliver.
It's not hard but it's not going to fall into your lap without a little effort.
¹ https://www.wittenburg.co.uk/Work/Transformation.aspx
² https://www.wittenburg.co.uk/Work/Objectives.aspx
³ https://www.wittenburg.co.uk/Work/Scope.aspx
(Being nice helps too - people like helping nice people -- https://www.wittenburg.co.uk/Work/Trust.aspx)
Also, I’ve found that, even if you do a great job of gathering requirements, no one likes it, when you give them exactly what they asked for. I’ve taken to using what I call “Evolutionary Design”[1]; where the entire design “morphs,” during development.
[0] https://stevemcconnell.com/articles/software-quality-at-top-...
[1] https://littlegreenviper.com/miscellany/evolutionary-design-...
Software or hardware engineering is a solution. You can solve the same with a pen and paper if you know what the user needs.
Agile is a way to iteratively validate expectations and revisit and update things with minimal wastage
Good engineering requires making the correct decisions in those cases. It requires knowing the 'actual' problem so you are not building a solution for the wrong thing. That means requirements are a part of engineering. Maybe not the full responsibility of gathering requirements, but understanding requirements, clarifying requirements, and feeding back what requirements are feasible or conflicting seem very much a part of engineering.
Perhaps you're using the word "engineering" as a synonym of "implementation" (which could work); I'd have thought it was more "design" though (in a technical sense, though I'm sure it might cover some of the aesthetic sense too).
Negotiation of requirements is a problem based on limitations like recources (money, people), known knows and known unknowns.
I'm working with one of those tools, it's free, check it out:
The 3D character model and some of its animation were done by Giorgos Chronopoulos (https://taloscreative.co.uk) in 2009.
The audio is a royalty free track.
For the screen-casts I used `ffmpeg` https://github.com/uxtely/screencast
The rest of the video I did it in Maya (3D portions) and Final Cut Pro (Sound FX and 2D animations).
Perhaps that suits todays predominant development methodology… “hack it, deliver, repeat”. The modern “agile”.
I find few concerned about “requirements”. After all it seems that the only problems in computing are “technical” ones.
The really important thing about requirements in an agile process is that you need a set of documents that accurately describe what the product is supposed to be doing right now. Using the stories doesn't work because you have to look through everything from the beginning to build up a picture of what a feature is, and using the code doesn't work in case someone has mis-understood the requirements. Managing the change through the project is the hard bit.
In those domains, success doesn't come from succeeding at the task, success comes from the task having been the right task to have done.
The other hardest part is not building stuff no-one will pay for.
Hence, it's the most difficult thing. But noone ever points at it in schools or textbooks
I also once worked at a place where a large project had a ship date before the requirements document ship date. Of course when it was done it did not match what was written down, and also wound up not matching the (internal) customers needs either, so it had to started over.
"It seems possible that very soon, if not already, it will take less time to prototype a solution than it will to properly document the requirements."
Maybe Trump uses it inappropriately outside of titles, I haven’t paid enough attention to his writing. But the author here doesn’t.
When "Agile" happened, the BA role slowly transitioned to Product Manager (PM). For a short while, PMs from BA background still took ownership and care for the board, still took care of acceptance criteria for stories/tasks, still signed off on the deliverables.
Now, Product Management has become a cult of personas. The role doesn't feel obliged to be accountable for defining specifications, or having a work handover, or signing off, or coordination, or product documentation, or anything. The role assumes it's creative work on a blank canvas. But guess what, all modern roles are largely creative, but it doesn't mean everyone should have no working model. But for some reason, this role has gone beyond beyond a working model into "I'm special".
I'm seeing many other comments below still focusing purely on the personality aspect of it. Good product managers vs Bad product managers. NO! This is about Good product management vs Bad product management. The role should have a working model and clear cut responsibilities. And those practices shouldn't be undercut by saying "I'm special". But most PMs feel "boxed in" by any way of working. They prefer calling it "culture", because culture can be something abstract and disassociated from.
We should realize: The transition to Agile has good and ugly sides. The ugly side is the broken transition from BAs to PMs, and the lack of accountability for what's being built which has left teams and deliverables ambiguous and dangling.
---
As a side addendum: I would partly blame Steve Jobs for it. For some weird reason, he has become a role model for PMs. He was a freaking CEO who did the selling and investment, you can't delegate anything to a CEO! He would have had armies of PMs dealing with the working model and details. But unfortunately, PMs seem to fetish the master salesman and personality cult angle of Steve Jobs, spending all the time in "Why", but forget about the details and start delegating their actual responsibilities to everyone else in the team. It should be made pretty clear that PMs are not CEOs like Steve Jobs. They are regular people who should have regular working models.
How low is the bar for submission to this place? I can say X, immediately followed by NOT X and it'll still end up on front page, huh?