3 ms·

You're living in a different world than I am. In my world, most organizations don't know the software they need until they figure out what they don't need in UA

You're living in a different world than I am. In my world, most organizations don't know the software they need until they figure out what they don't need in UAT. The exception to the rule is when they're replacing an existing system (or consolidating multiple systems.) Then, they think they know exactly what they need, but then they won't figure out what they need until UAT when the real users finally see the system and point out the business rules that were considered unimportant. So, why not iterate quickly, developing the software in one of two orders: * If one portion of the system can be used independently and generate value, why not build that first and get everyone using that? * If the system cannot provide value independently, build the MVP of the first screen they will use in the workflow and a view-only portion of the second screen? Then get real world users to tell you what they absolutely need before calling it done. Once the first screen is done to their approval, then you take stock of the budget. You tell them there is a balancing act between cost and scope, and everything flows from there. (Or, you find that the value can't be realized and bail to another project.)

mbesto 11y ago
Hopefully this doesn't come off as patronizing, but given you're a programmer (had a look at your profile), then yes we definitely live in different worlds. I work with a variety of people who have very little empathy for developers, but effectively hold the purse strings on technology decisions. These people (which largely outnumber programmers btw) see the world in black and white -- things either work or they don't. Software development to them is a black box. > The exception to the rule is when they're replacing an existing system (or consolidating multiple systems.) This is pretty much 90% of the software systems and projects that exist today. Don't let the headlines of TechCrunch fool you. The world outside SV doesn't sit in Google, it sits in terminal screens and mainframes. All that money SAP, IBM and Oracle is making is all made by replacing existing systems (whether software or pen and paper). The people making the decisions don't care about MVPs or what screens look like. They want to increase efficiencies aligned with the objections of their role and not get fired for doing it. When I tell a trader at an asset management company they can't enter in incorrect values for a stock trade because we'll need to fix the data quality issue on our backend, they tell me "f--- off" because they'll simply pay their way out of that discrepancy. So I hear you, but what you're suggesting exists in very few organizations (globally) or in a vacuum.
- ebiester 11y ago
  They're replacing the existing system because the interaction of programmers and users made an unusable system that didn't account for the business needs. Unfortunately, the people in control of the pursestrings don't have the same day-to-day perspective of the people actually using the system. I've seen documented processes be completely divorced from reality. The real challenge in these systems is uncovering the true business, and the true business isn't understood except as a collective. It is challenging to tell a director that they don't understand their own business, however. I've worked in a lot of internal IT shops throughout my career, and it is only recently that I've worked on B2C applications. That's why I explicitly say that replacing an existing system requires more iteration, not less. How many times have you seen a user exploit a bug to get their work done and be angry when it's "fixed?" The real bug is that the business didn't understand their own process. My job, when I was in internal applications, was to cut through the bullshit and really understand how the business was run. And anyone who thinks they can analyze the problem up front and give a precise estimate for how long it will take is delusional.

mbesto 11y ago

Hopefully this doesn't come off as patronizing, but given you're a programmer (had a look at your profile), then yes we definitely live in different worlds. I work with a variety of people who have very little empathy for developers, but effectively hold the purse strings on technology decisions. These people (which largely outnumber programmers btw) see the world in black and white -- things either work or they don't. Software development to them is a black box. > The exception to the rule is when they're replacing an existing system (or consolidating multiple systems.) This is pretty much 90% of the software systems and projects that exist today. Don't let the headlines of TechCrunch fool you. The world outside SV doesn't sit in Google, it sits in terminal screens and mainframes. All that money SAP, IBM and Oracle is making is all made by replacing existing systems (whether software or pen and paper). The people making the decisions don't care about MVPs or what screens look like. They want to increase efficiencies aligned with the objections of their role and not get fired for doing it. When I tell a trader at an asset management company they can't enter in incorrect values for a stock trade because we'll need to fix the data quality issue on our backend, they tell me "f--- off" because they'll simply pay their way out of that discrepancy. So I hear you, but what you're suggesting exists in very few organizations (globally) or in a vacuum.

ebiester 11y ago
They're replacing the existing system because the interaction of programmers and users made an unusable system that didn't account for the business needs. Unfortunately, the people in control of the pursestrings don't have the same day-to-day perspective of the people actually using the system. I've seen documented processes be completely divorced from reality. The real challenge in these systems is uncovering the true business, and the true business isn't understood except as a collective. It is challenging to tell a director that they don't understand their own business, however. I've worked in a lot of internal IT shops throughout my career, and it is only recently that I've worked on B2C applications. That's why I explicitly say that replacing an existing system requires more iteration, not less. How many times have you seen a user exploit a bug to get their work done and be angry when it's "fixed?" The real bug is that the business didn't understand their own process. My job, when I was in internal applications, was to cut through the bullshit and really understand how the business was run. And anyone who thinks they can analyze the problem up front and give a precise estimate for how long it will take is delusional.