Sometimes it feels like life is an endless stream of the same mistakes being committed notoriously again & again (plus some occasional stupid, irrational, semi-random behaviors from time to time). And I don't refer to any particular person, the same observation applies for yours sincerely as well.
And that's a thing (two things?) I'd like to write about today - two particular mistakes people keep making on the daily basis. Why these two particular mistakes? Because I had problem with them as well, but with a proper guidance I've learned to be extremely cautiuous about these & now I believe I have them under control.
Let's name them:
- Focusing on the solution, not the problem itself, first.
- Instead of concentrating efforts on a narrow problem, thinning the offensive by making it too wide.
Regardless of my hard struggle to keep things as concise as possible, I have to split the post in two. So in this post will be about hard relationship between problem & solution and in few days I'll write something more about blitzkrieg & panzer fist of fury in IT.
It's all about EFFECTiveness
I keep telling my subordinates:
You don't have to know the solution, but at least make sure you know the problem.
A pretty smart guy, named Steve Jobs, said something even better:
If you define the problem correctly, you almost have the solution.
It's pretty much obvious and there's really no point in writing about it, right? Wrong...
Wherever I go, whoever I talk to - people tend to think with solutions, without prior effort to understand what the actual problem (to be solved) is. What's the actual pain that will be eased? That's the expected (and desired for) value?
One of the best examples are so called "business requirements". In 95% of BRs I've seen, so-called "analysts" (I'd rather call them "chroniclers") just write down "what would you like to get" what usually means "how is the UI supposed to look alike?". Let's name it straight - it means that the end-users / business owners are the ones who design the application. Just to remind you, these people:
- are domain experts (most likely pretty good in what they do)
- are living within the domain only daily basis, but ...
- they ARE NOT UI/UX experts
- they DON'T KNOW ANYTHING about software development - technologies' capabilities, restrictions, patterns, ...
So, instead of extracting their domain knowledge and building a model that abstracts the perspective suitable for this particular IT system, we let them "snapshot" the reality and struggle with forcing it on UI windows - they very last thing they know how to do properly ... The solution, instead of aiding them efficiently and solving their problems, reflects the flawed (in a need of silicon aid) reality, mimics the limitations they face right now & ignore the potential computer science brings in.
Congratulations, job well done.
Let's use it. Because yes.
Another scenario:
A: We're going to use product X. We've tried it & we think it's great.
B: Really? How so?
A: I can create categories using it & there are 7 ways to filter the lists.
B: Sweet. Who asked for that?
A: Well, no-one, but the old product had only 3 filters, so it's a pure win.
B: Yea, sure - and about the categories: what's the benefit of introducing them? Did anyone ask for categories, did you do any research to find out whether they will actually use them?
A: Ermmm...
B: And the product you're replacing with this new shiny toy - did you find out what kind of functionality will disappear? And how will it affect the use cases? Won't it cripple everyday operations?
A: ...
It's so freaking awesome, that we're going to use it. We don't have a sensible justification, we have no clue about the actual cost, we've ignore the transition period. But we're doing it. Maybe it will solve some kind of problem. On the occasion.
Measure? Doesn't happen here
I don't know what's worse - not given an f-word about the actual problem or inventing the artificial, intangible problem that can't be measured / verified just to make sure that the action is not transparent at all.
Quality? Reliability? Efficiency?
Can't be measured. How would you measure that?
Bullshit. Yes "bullshit" is the only thing that's impossible to get measured. It's just here or not. If there's a problem / if there's some kind of particular value to be added it HAS to be tangible, becasue otherwise no reasonable feedback is feasible.
[ End of part I - you can find the part II here ]
