Rabu, 13 Agustus 2008
Selasa, 12 Agustus 2008
Business Requirements are Bullshit
Some CEO emailed me the other day. I don't remember who it was; people mail me all the time about their blah blah yawn product service thingy, and on the rare occasions I bother to read mail from strangers, I don't usually remember anything about the email, even if I respond to it. I can remember broad categories of questions I get, but everything else is just a blur. That's senility for ya.
But this dude, or possibly dudette, asked me a really good question. One that made an impression. And by "really good", I mean it was one of the flat-out wrong-est business questions you could possibly ask. It was like asking: "How can I get the most out of my overseas child laborer pool?"
There's no right answer to a question that's just wrong.
But his question, well, people ask it a lot. In fact there are whole books that give answers to this inherently-wrong question.
His question was:
And my answer was: Business requirements are bullshit!
Well... actually it was: "gathering business requirements is bullshit", plus a bunch of accompanying explanation. But the shorter version sure is catchy, isn't it?
The rest of this little diatribe expands a bit on my reply to this guy. (I actually sent him an email with much of this material in it. When I do reply to strangers, I still try do a thorough job of it.)
Before we dig into the meat and potatoes of today's meal, let's talk about my credentials, and how it is that I am qualified to offer an opinion on this topic.
My Credentials
If you're a business person stumbling on my blog for the first time, welcome! Allow me to introduce myself: I don't matter. Not one teeny bit. You shouldn't care about my credentials! All that matters is the message, which is hopefully so self-evident that if you hadn't already realized it, you'll be kicking yourself.
It's OK, though. Kick away! In fact, give yourself an extra kick for me. Kicking yourself is a great way to remember a new lesson down in your bones. When you get actual bones involved, the painful throbbing for the next few days provides just enough of a reminder that you'll never forget again.
In any case, I make no claim to any credentials whatsoever, and this advice is all straight from my butt. Do what you like with it. The advice, that is.
With my credentials out of the way, let's see about this guy's question.
By the way, I'm specifically addressing this rant towards you only if you (or your team, or company) are building your own product or service offering, or at least defining it. If you're asking consultants to define the product for you, well, you're on your own. Good luck. And if you're a consultant, well, you don't get much choice about what to build, so you're also (mostly) on your own. Although I'd advise you to try to find work that fits the strategy I outline here, as you'll have more fun with it and do a better job overall.
Gathering Requirements 101
It's the first thing everyone wants to do! It's the first thing they teach you in Project Management Kindergarten: the very first thing you should do on a new project is look both ways before crossing the street to your building. Assuming you parked across the street. And the next thing is: start gathering business requirements!
Ah, the good old days of Project Management 101. Life seemed so easy back then.
The requirements-gathering process they teach you typically involves finding some "potential customers" for your product, and interviewing them in a nonscientific way to try to figure out what they want out of your proposed product. Or service. Or whatever. It doesn't really matter.
Potential customers can be hard to come by, especially since you're building something that nobody will ever, EVER want. Well, that's getting ahead of myself. Let's just agree that when you're setting out to Gather Business Requirements, your potential customers usually aren't already sitting in the room with you.
Sometimes it's a lot of effort to go find real customers and bring them in and get them to agree to be grilled for hours. Hence, requirements-gathering sometimes takes the form of "role play", where you get some poor saps in Accounts Receivable to pretend they're Potential Customers for your product, and you interview them instead.
You might be laughing about those poor Role Playing schmucks, but in reality it doesn't much matter who you interview, because by the time you get to this phase in the project, you've already screwed it up beyond all hope of repair.
That process of looking around for customers? It's a plot device that novelists like to call foreshadowing. If you don't have any readily available customers now, then they sure as hell won't be readily available when your product launches.
Allow me to illustrate with a Case Study.
An Illustrative Case Study
See? Credentials or no, I sure can talk the lingo, eh? I also like my incisive use of the popular business term "schmuck" in the previous section. It's a term that can apply to people in all phases of project catastrophes, not just Requirements Gathering.
For our Case Study, I will not do any research and the product will be entirely fictional. This is the approach used by most real companies.
Let's say that our Ideas Department has decided that we should get into Personal Nose Hair Grooming devices, because there's clearly a huge unmet need for nose hair grooming, as evidenced by Karl, our accountant, who has a thatch of nose hair that's almost long and thick enough to be a mustache, if only he would groom the thing a little. And we've seen lots of people like Karl. Clearly a nose-hair grooming kit would be the ideal addition to any man's personal grooming lineup, which typically consists of spitting into the sink and thinking he should get the mirror fixed someday.
So we need to gather some Business Requirements. Unfortunately nobody wants to talk directly to Karl, because, well, nose hair can sometimes be a mildly sensitive issue in some cultures. Plus nobody wants to make eye contact with him. So instead we hire some people to go out and do focus-group studies on the subset of people who are comfortable talking publicly about their nose-hair grooming problem, notwithstanding the fact that everyone in this tiny category is obviously too crazy to trust with important business questions.
The focus groups find a few nut-jobs who say: "Yeah, I'd love a nose-hair grooming appliance! Plucking your nose hair is painful, and trimming it involves jamming a small whirly Osterizer thing all the way up to your brain. Maybe if I just combed it into a mustache, nobody would notice!" And behold, we have the makings of some Business Requirements.
The product is a complete failure, of course. The project postmortem reveals that the user studies and focus groups failed to realize that only certain men, namely "men with significant others", ever even notice their nose hair, even when said hair becomes long enough to interfere with tying their shoelaces. The significant other must forcibly remove the nose hairs with garden shears at least twice before the man gets the hint and starts attending to the problem himself.
Not to mention the fact that a nose-hair mustache would be even more obvious and comical than a comb-over. Well, almost.
In the end, it doesn't matter how great a Nose Hair Groomer we build, because we failed at the business-requirements gathering phase: nobody actually wants this product. The people who might want it don't know they have a nose-hair issue, and the ones who do know just trim it.
The thing that might surprise you is that this fictitious (and yet eerily familiar) Case Study isn't just an illustration of how gathering business requirements can go afoul. We're not talking about a failure mode for Gathering Business Requirements (GBR). We're talking about something more fundamental: the GBR phase of a project is a leading indicator that the project will fail.
Put another way: GBR is a virtual guarantee that a project is building the wrong thing, so no amount of brilliant execution can save it.
From Business Requirements to Bad Idea
I learned a lot about the Fine Art of Building Shit that Nobody Wants back at Geoworks, when in 1993-1994 I was the Geoworks-side Engineering Project Lead for the HP OmniGo 100 and 110 palmtop organizer products. Both of them launched successfully, and nobody wanted either of them.
People spend a lot of time looking at why startups fail, and why projects fail. Requirements gathering is a different beast, though: it's a product failure. It happens during the project lifecycle, usually pretty early on, but it's the first step towards product failure, even if the project is a complete success.
Self-professed experts will tell you that requirements gathering is the most critical part of the project, because if you get it wrong, then all the rest of your work goes towards building the wrong thing. This is sooooort of true, in a skewed way, but it's not the complete picture.
The problem with this view is that requirements gathering basically never works. How many times have you seen a focus group gather requirements from customers, then the product team builds the product, and you show it to your customers and they sing: "Joy! This is exactly what we wanted! You understood me perfectly! I'll buy 500 of them immediately!" And the sun shines and the grass greens and birds chirp and end-credit music plays.
That never happens. What really happens is this: the focus group asks a bunch of questions; the customers have no frigging clue what they want, and they say contradictory things and change the subject all the time, and the focus group argues a lot about what the customers really meant. Then the product team says "we can't build this, not on our budget", and a negotiation process happens during which the product mutates in various unpleasant ways. Then, assuming the project doesn't fail, they show a demo to the original customers, who say: "This is utterly lame. Yuck!" Heck, even if you build exactly what the customer asked for, they'll say: "uh, yeah, I asked for that, but now that I see it, I clearly wanted something else."
So the experts give you all sorts of ways to try to get at the Right Thing, the thing a real customer would actually buy, without actually building it. You do mockups and prototypes and all sorts of bluffery that the potential customer can't actually use, and they have to imagine whether they'd like it. It's easy enough to measure usability this way, but virtually impossible to measure quality, since there are all sorts of intangibles that can't be expressed in the prototype. I mean, you can try — we sure tried on the OmniGo products — but in this phase nobody "imagines" that the thing will weigh too much, or be too slow, or will go through batteries like machine-gun rounds, or that its boot time will be 2 minutes, or any number of other things that ultimately affect its sales.
And even if you do a world-class job of prototyping and getting at the "real" desired feature set, it still goes through a series of iterations with the engineers and product team, who aren't the actual customers and have little interest in building what the customer really wants (because they're not being measured or evaluated on that — they're evaluated on delivering what everyone ultimately agrees to deliver). During each iteration they push back on things the customers asked for. As the proposal degrades, the customers like it less and less, but they want to be helpful, so eventually they say, "Yeah, I guess I could use that." (Which means: I wouldn't take one of these even if they were giving it away.)
Don't get me wrong: I'm not saying that usability teams can't do a good job. It's just that when the project implementation team and the target customer aren't exactly the same group of people, then there are inevitably negotiations and compromises that water an idea down about two levels of quality: great becomes mediocre, and ideas that start as "pretty good" come out "just plain bad."
So I'm tellin' ya: gathering requirements is the Wrong Way To Do It. At best, it results in mediocre offerings. To be wildly successful you need a completely different approach.
The investing analogy
Warren Buffett and Peter Lynch, both famous and successful investors, say pretty much the same thing about investing. Peter Lynch's mantra sums it up: "invest in what you know."
If you actually take the time to read Lynch's books (which I have), you'll see that this pithy mantra is a placeholder for something a bit more subtle: you should invest in what you know and like. You should invest in companies that make products or services that you are personally excited about buying or using right now.
When you invest with this strategy, you're taking advantage of your local knowledge, which tends to be more accurate than complicated quantitative packets put together by analysts. And your local knowledge is definitely more accurate than the reports produced by the companies, who want to paint themselves in the nicest light.
Warren took a lot of heat in the 1990s for not investing in the tech sector. But hey, he didn't feel comfortable with tech, so he didn't invest in it. One way to look at this is: "ha ha, what a dinosaur, he sure missed out, and now he's, uh, only the richest person in the world by a small margin." But another, more accurate way to look at it is this: he's the richest person in the world, you asshole. When he gives you investment advice, take it!
And Warren's advice is: don't invest in stuff you don't understand! Even if it seems like a sure thing.
That's the hard part. Sometimes it looks like a surefire winner for some large group of people that doesn't actually include you personally at this particular moment. But it's a really large group!
Let's say, for instance, that you hear that Subway (the sandwich franchise) is going to do an IPO. They've been privately held all these years and now they're going public. Should you invest? Well, let's see... the decision now isn't quite as cut-and-dried as it was in their rapid-expansion phase, so, um, let me see, with current economic conditions, I expect their sales to, uh... let me see if I can find their earnings statement and maybe some analyst reports...
No! No, No, NO!!! Bad investor! That's the kind of thinking that loses your money. The only question you should be asking yourself is: how many Subway sandwiches have I eaten in the past six months? If the number is nontrivial — say, at least six of them — and the rate of sandwiches per month that you eat is either constant or increasing, then you can think about looking at their financials. If you don't eat their sandwiches, then you'd better have a LOT of friends who eat them every day, or you're breaking the cardinal rule of Buffett and Lynch.
The investing analogy is an important one, because if you're a company or team planning to build something, then you're planning an investment. It's not exactly the same as buying stock, but it amounts to the same thing: you're betting your time, resources and money — all of which boil down to money (or equivalently time, depending on which one is in shorter supply.)
So when translated into project selection, Buffett's and Lynch's advice becomes: only build what you know. The longer, more accurate of the version of the investing rule — only invest in what you know and are excited about using yourself right now — has a simpler formulation for products and businesses. That formulation goes like this:
ONLY BUILD STUFF FOR YOURSELF
That's the Golden Rule of Building Stuff. If you're planning to build something for someone else, let someone else build it.
Building stuff for yourself
You can look at any phenomenally successful company, and it's pretty obvious that their success was founded on building on something they personally wanted. The extent that any company begins to deviate from this course is the extent to which their ship starts taking on water.
And the key leading indicator that they're getting ready to head off course? You guessed it: it's when they start talking about gathering business requirements.
Because, dude, face it: if it's something you want, then you already know what the requirements are. You don't need to "gather" them. You think about it all the time. You can list the requirements from memory. And usually it's pretty simple.
For instance, a few years ago I announced to some friends: "I sure wish someone would make a product you can spray on dog poop to make it, you know, just dissolve away." My friends laughed loudly and informed me that this was (apparently) the premise of some Adam Sandler movie I hadn't seen.
Well, OK, sure, but... I mean, they kinda missed the point. I still want the product. Its requirements list is pretty simple. Here's the business requirements list:
a) It should dissolve dog poop.
Gosh. Can that really be the entire list? You bet! Sure, there are lots of implicit requirements: it shouldn't cost a fortune, it should be environmentally friendly, it shouldn't kill kittens, etc. But those kinds of requirements are true for all products and services.
If I knew how to make this product, then Adam Sandler movie or no, I'd probably try to make it. The target market is larger than just pet owners; anyone living near a park would probably own a bottle or two. I would use the stuff like it's going out of style. I'd attach it to my shoes so that every time I took a step it would spray the area in front of me, like a walking garden hose.
Building a product for yourself is intrinsically easier, since you don't have to gather requirements; you already know what you want. And you also know, for any given compromise anyone suggests, whether it will ruin the product. If someone says, "I have a product that dissolves dog poop, but it takes 18 hours", then you'll know you've entered into "prolly not worth it" territory. You don't have to go ask the focus group. You just know.
The Mistake of Imagination
Despite its obvious advantages, following the rule of building stuff for yourself is actually really hard to carry out in practice. Why? Oddly enough, it's ego.
For one thing, people like to think they're unique and special, and that their tastes aren't necessarily widely shared by others. This is what drives fashion: the need to differentiate yourself from "the crowd", by identifying with some smaller, cooler crowd.
The reality is that for any given dimension of your personality, there are oodles of people just like you. If you want something, other people want it too. You define a market: a bunch of them, in fact.
You just have to be smart about which of your needs you want to fulfill, since if it's building yachts, well, it's not exactly going to be mass-market, unless you find a way to build a mass-market yacht. Which would be pretty cool, incidentally. I'll buy one if you make it.
It's also really easy to fool yourself into thinking that this is a product or service you would use, because, hey, you have a great imagination. When you lose your car keys, you can picture them in all sorts of places: the kitchen drawer, the coffee table, on top of the fridge, and when you picture them there, it's just as vivid as a memory. So you wind up looking for them everywhere! Your powerful imagination is pretty much your worst enemy when it comes to deciding whether you'd like something enough to use it yourself.
We all made the Mistake of Imagination on the OmniGo projects. "I could see myself using this product," we'd tell ourselves, "if, that is, I were the kind of person who used this product, which I could sort of envision." You'll tell yourself almost anything to justify the work you're doing. Giving up in mid-project is a big loss of face for an individual, harder for whole teams, virtually impossible for most companies. The OmniGo had four companies involved, making it the hardest possible project to back out of, even though by the halfway point virtually everyone involved knew the product would kind of suck.
What we really wanted, while we were building the OmniGo, was summed up by our brilliant product manager Jeff Peterson. We were having beers one day, and he said, "You know, this thing is just getting way too complicated! It doesn't need a 12C calculator emulator! It doesn't need a spreadsheet! It doesn't need a database application! I mean, come on! All it needs is a notepad, a simple calendar, an alarm clock, and maybe a pocket calculator, and it should fit in your front shirt pocket, and it should be a phone."
It was 1994 and he was describing the iPhone. And you know what? He was right! That was what we wanted. But HP was driving the spec, and they weren't building it for themselves. They were building the product specifically for this imaginary group of high-power on-the-go consumer accountants who use 12C calculators and want a whole desktop suite crammed onto their 1994-era mobile device. And that's just who bought the thing: pretty much nobody. (They sold a few thousand units, which in mass-market terms is "pretty much nobody.")
Trimming the Requirements
Who was it who said that you're done writing not when there's nothing left to add, but when there's nothing left to take away? Was it St. Exupéry? I promised not to do any research for this rant, but I think it might have been him.
Ideally the product you're building for yourself should be simple to describe, so that other people can quickly evaluate whether they, too, want this thing. It's often called the "elevator pitch", because you should be able to describe the product in the time between when the cable snaps and the elevator hits the ground. "Dissolves dog poooooop!!! <crash>" It used to just be the time for an elevator ride, but those investors keep raising the bar.
You can almost always make a product better by trimming the requirements list. We're talking brutal triage: throwing out stuff that's really painful to lose, such as the ability to change the battery.
If you're lucky, you should be building a product that so excites everyone involved that everyone has an opinion, and you wind up spending most of your time in triage.
When you're trimming the business requirements, then you're exhibiting healthy project behavior. This contrasts directly with gathering requirements, which has both the connotation that you're clueless about the product and the connotation that you're inflating the requirements list in direct conflict with schedule, usability and fashion. Trimming: good. Gathering: bad.
Trimming the requirements list is a leading indicator that you're a smart company who's about to launch something major. An ideal requirements list looks something like this:
a) It should dissolve dog poop.
As a great real-life example, consider the the Flip camcorder, which kinda came out of nowhere and "stole" 13% of the camcorder market (although I'd bet good money that it actually created new market share). Does it dissolve dog poop? Well, no, but it's still pretty cool:
1) it costs $150 or less. (A lot less, actually.)
2) it has no cables or wires. Just one flip-up USB connector.
3) it has one big red button: RECORD, plus a teeny one for playback.
4) it doesn't take cartridges or cassettes or discs or cards or anything
5) it doesn't have any controls or settings or anything
6) it stores one hour of video and has roughly one hour of battery life
7) it's about the size of a cell phone
8) it records videos that work well with YouTube
9) it comes in pretty colors
I mean, DAMN, those guys knew what they were doing. We always used to joke about a product so simple that it only had one button, which we pressed for you before it left the factory. That's how simple a product needs to be in order to make the mass market. One button, pretty colors. They nailed it. Talk about a missed startup opportunity. (Flip guys: if your equity plan is still reasonable and you want someone to make your desktop software not suck, and yes, it really sucks, please give me a call.)
You don't need an original idea to be successful. You really don't. You just need to make something that people want. Even if someone else appears to be making something popular, it's usually possible to improve on the idea and grab market share. And it's painfully counterintuitive at times, but the best improvements often come from simplifying.
The easiest way to build a product that kicks ass is to start with someone else's great idea (camcorders, for instance), and take stuff away.
In any event, originality is overrated. Coming up with something completely original isn't just hard to do: it's also hard to sell, because investors (and possibly customers) will need to be educated on what this new thing is and why people would want it. And when it comes to buying stuff, nobody likes to be educated. If the product isn't immediately obvious, investors and customers will pass it up.
It's easy to come up with new product ideas if you start with the understanding that everything sucks. There are no completely solved problems. Just because someone appears to be dominating a market with an "ideal" offering doesn't mean you can't take market share from them by building a better one. Everything can stand improvement. Just think about what you'd change if you were doing it for yourself, and everything should start falling into place.
If nothing else, building things for yourself is more fun, so you're successful regardless of what happens. But it also has great product-survival characteristics, because people can't bluff you into making something lame.
Sometimes you just can't win
By way of don't-sue-me disclaimer, I should point out that building something for yourself doesn't guarantee success. Even if you build a product that most of your target market really really wants, and you hit the right price point and release date and everything, your product can still fail catastrophically.
The example that leaps to mind is that company in the 1990s (can anyone remind me of the name? I've forgotten) that built a mountain-bike seat extender. I ride mountain bikes, yes, on actual mountains, so this product made immediate sense to me. I really wanted one. Sounds like a winner, right?
The basic physics problem this company was solving is that a lower seat position gives you better balance, and a higher seat position gives you more power. It's a trade-off. You generally want more power when you're grinding uphill, and you want more balance when you're speeding downhill. But during a race you would have to give up precious seconds to adjust your seat between every uphill and downill transition; you'd get your butt kicked. Even as a casual rider, adjusting your seat height all the time is annoying enough that most people just don't do it, resulting in some sacrifice of balance, power, or both.
So this brilliant, innovative company came out with a well-made product that lets you adjust your seat height "in flight", as it were, without slowing down, and without adding much (if any) weight to the bike. I don't remember exactly how it worked, but it was a reasonable implementation.
Interestingly, it didn't matter how it worked. It could have been actual magic: a product that read your mind and raised or lowered your seat by exactly the right amount, at exactly the right speed (you don't want it to rabbit-punch you in the nuts, for example — remind me sometime to tell you about how I found that out), as frequently or infrequently as necessary to strike the perfect trade-off of balance and power for any slope, at any time.
And it still would have failed, even if 90% of the mountain biker population, like me, secretly coveted the product. It could have cost fifty cents, been available everywhere, and been installable by a four-year-old with one hand in under two seconds. It could have come pre-installed on all bike models, via a brilliant channel deal with all the main manufacturers (or retailers), and bikers would have ripped the thing off the bike faster than their kickstand (which is usually the first thing to go.)
So, uh, what happened, exactly? Wasn't I just ranting that building a product for yourself, one that you know is the Right Thing for some well-defined audience consisting of people just like you in some dimension — wasn't I ranting that this would always work?
Well, no. It's just the best way to pick projects. But they can still fail for surprising reasons.
In this case, the fundamental marketing force that the company failed to take into account was fashion. People don't often think of mountain biking (or programming, for that matter) as a fashion industry, but failing to understand the role of fashion is a recipe for random disasters.
What happened was this: while they were hyping the product — by demoing it at trade shows, letting bike magazines check it out, and generally working their way towards getting retailer shelf space — the pro bikers took one look at the thing and said: "Hey, looks pretty cool. Maybe I'll get one for my girlfriend. Or my fugging grandma. How much is it?"
At which point, everyone (me included) who had been ranting about standing in line to buy one when they came out, we, ah, we were very quick to point out that we were also excited to buy them for our grandmothers, whom we loved just as much as the pros love their grandmothers, thank you very much. In fact, our grandmothers are too macho to use this thing. Maybe we'll put one on our kid's stroller! So there!
And that's how a great product, one that probably would have changed biking nearly as fundamentally as the derailleur, was doomed from birth because the trendsetters of Mountain Biking Fashion pronounced it a Product for Sissies, and that was that.
Heck, even derailleurs are falling out of fashion in some circles. Go figure. Someone took the time-tested "solved problem" of bicycles, removed something, and wound up creating a new market.
Fashion is generally hard to predict, but it usually means "sacrificing comfort or convenience for the sake of style". Take another look at the iPod: it has almost no features. It doesn't have an "off" button. Heck, you can't even change the battery. Not exactly convenient in many ways. But it sure has style!
Fashion's not the only way your otherwise perfect product can fail, but it's definitely one to keep an eye on.
Less is more... more or less
OK, fine, I haven't exactly been following my own advice about minimalism. But I have been writing my blog the way I like it, haven't I? So even if nobody reads it, I'm still having fun. If you're going to create something that has a nonzero chance of failure — and believe you me, it's nonzero — then you might as well have fun doing it, right?
Anyway, there you have it: the slightly expanded version of the email I sent that CEO guy. Gathering business requirements is hokum. Hooey. Horseshit. Call it what you want, but it's a sign of organizational (or individual) cluelessness. If you don't already know exactly what to build, then you're in the wrong business. At the very least, you should hire someone who does know. Don't gather business requirements: hire domain experts.
If you can't think of anything in your company's "space" that you personally would use, then you should think seriously about (a) changing your company's direction, or (b) finding another company. This is true no matter what level you're at. You should be working on something you love, or failing that, at least working on something that you know really well.
"But... but..." I hear you saying. I hear you! You sort of get what I'm saying, but you have all these reservations and objections and questions and stuff.
Well, that's what the comments section is for. I'm sure you can think of some other explanation for why Warren Buffett is the richest person in the world. Let's hear it!
But this dude, or possibly dudette, asked me a really good question. One that made an impression. And by "really good", I mean it was one of the flat-out wrong-est business questions you could possibly ask. It was like asking: "How can I get the most out of my overseas child laborer pool?"
There's no right answer to a question that's just wrong.
But his question, well, people ask it a lot. In fact there are whole books that give answers to this inherently-wrong question.
His question was:
"Hello, blah blah, I'm the CEO or C-something-O or whatever of a company that blah blah BLAH, and I read your blog about Agile from almost 2 years ago, which kinda resonated with me in a scary way, inasmuch as I realized perhaps belatedly that I was being duped, BUT I was sort of wondering:(Note: not a verbatim transcript. But close enough.)How do you go about gathering business requirements, so you know what to deliver to the customer?
Signed, blah blah blaaaaaaaaaah."
And my answer was: Business requirements are bullshit!
Well... actually it was: "gathering business requirements is bullshit", plus a bunch of accompanying explanation. But the shorter version sure is catchy, isn't it?
The rest of this little diatribe expands a bit on my reply to this guy. (I actually sent him an email with much of this material in it. When I do reply to strangers, I still try do a thorough job of it.)
Before we dig into the meat and potatoes of today's meal, let's talk about my credentials, and how it is that I am qualified to offer an opinion on this topic.
My Credentials
If you're a business person stumbling on my blog for the first time, welcome! Allow me to introduce myself: I don't matter. Not one teeny bit. You shouldn't care about my credentials! All that matters is the message, which is hopefully so self-evident that if you hadn't already realized it, you'll be kicking yourself.
It's OK, though. Kick away! In fact, give yourself an extra kick for me. Kicking yourself is a great way to remember a new lesson down in your bones. When you get actual bones involved, the painful throbbing for the next few days provides just enough of a reminder that you'll never forget again.
In any case, I make no claim to any credentials whatsoever, and this advice is all straight from my butt. Do what you like with it. The advice, that is.
With my credentials out of the way, let's see about this guy's question.
By the way, I'm specifically addressing this rant towards you only if you (or your team, or company) are building your own product or service offering, or at least defining it. If you're asking consultants to define the product for you, well, you're on your own. Good luck. And if you're a consultant, well, you don't get much choice about what to build, so you're also (mostly) on your own. Although I'd advise you to try to find work that fits the strategy I outline here, as you'll have more fun with it and do a better job overall.
Gathering Requirements 101
It's the first thing everyone wants to do! It's the first thing they teach you in Project Management Kindergarten: the very first thing you should do on a new project is look both ways before crossing the street to your building. Assuming you parked across the street. And the next thing is: start gathering business requirements!
Ah, the good old days of Project Management 101. Life seemed so easy back then.
The requirements-gathering process they teach you typically involves finding some "potential customers" for your product, and interviewing them in a nonscientific way to try to figure out what they want out of your proposed product. Or service. Or whatever. It doesn't really matter.
Potential customers can be hard to come by, especially since you're building something that nobody will ever, EVER want. Well, that's getting ahead of myself. Let's just agree that when you're setting out to Gather Business Requirements, your potential customers usually aren't already sitting in the room with you.
Sometimes it's a lot of effort to go find real customers and bring them in and get them to agree to be grilled for hours. Hence, requirements-gathering sometimes takes the form of "role play", where you get some poor saps in Accounts Receivable to pretend they're Potential Customers for your product, and you interview them instead.
You might be laughing about those poor Role Playing schmucks, but in reality it doesn't much matter who you interview, because by the time you get to this phase in the project, you've already screwed it up beyond all hope of repair.
That process of looking around for customers? It's a plot device that novelists like to call foreshadowing. If you don't have any readily available customers now, then they sure as hell won't be readily available when your product launches.
Allow me to illustrate with a Case Study.
An Illustrative Case Study
See? Credentials or no, I sure can talk the lingo, eh? I also like my incisive use of the popular business term "schmuck" in the previous section. It's a term that can apply to people in all phases of project catastrophes, not just Requirements Gathering.
For our Case Study, I will not do any research and the product will be entirely fictional. This is the approach used by most real companies.
Let's say that our Ideas Department has decided that we should get into Personal Nose Hair Grooming devices, because there's clearly a huge unmet need for nose hair grooming, as evidenced by Karl, our accountant, who has a thatch of nose hair that's almost long and thick enough to be a mustache, if only he would groom the thing a little. And we've seen lots of people like Karl. Clearly a nose-hair grooming kit would be the ideal addition to any man's personal grooming lineup, which typically consists of spitting into the sink and thinking he should get the mirror fixed someday.
So we need to gather some Business Requirements. Unfortunately nobody wants to talk directly to Karl, because, well, nose hair can sometimes be a mildly sensitive issue in some cultures. Plus nobody wants to make eye contact with him. So instead we hire some people to go out and do focus-group studies on the subset of people who are comfortable talking publicly about their nose-hair grooming problem, notwithstanding the fact that everyone in this tiny category is obviously too crazy to trust with important business questions.
The focus groups find a few nut-jobs who say: "Yeah, I'd love a nose-hair grooming appliance! Plucking your nose hair is painful, and trimming it involves jamming a small whirly Osterizer thing all the way up to your brain. Maybe if I just combed it into a mustache, nobody would notice!" And behold, we have the makings of some Business Requirements.
The product is a complete failure, of course. The project postmortem reveals that the user studies and focus groups failed to realize that only certain men, namely "men with significant others", ever even notice their nose hair, even when said hair becomes long enough to interfere with tying their shoelaces. The significant other must forcibly remove the nose hairs with garden shears at least twice before the man gets the hint and starts attending to the problem himself.
Not to mention the fact that a nose-hair mustache would be even more obvious and comical than a comb-over. Well, almost.
In the end, it doesn't matter how great a Nose Hair Groomer we build, because we failed at the business-requirements gathering phase: nobody actually wants this product. The people who might want it don't know they have a nose-hair issue, and the ones who do know just trim it.
The thing that might surprise you is that this fictitious (and yet eerily familiar) Case Study isn't just an illustration of how gathering business requirements can go afoul. We're not talking about a failure mode for Gathering Business Requirements (GBR). We're talking about something more fundamental: the GBR phase of a project is a leading indicator that the project will fail.
Put another way: GBR is a virtual guarantee that a project is building the wrong thing, so no amount of brilliant execution can save it.
From Business Requirements to Bad Idea
I learned a lot about the Fine Art of Building Shit that Nobody Wants back at Geoworks, when in 1993-1994 I was the Geoworks-side Engineering Project Lead for the HP OmniGo 100 and 110 palmtop organizer products. Both of them launched successfully, and nobody wanted either of them.
People spend a lot of time looking at why startups fail, and why projects fail. Requirements gathering is a different beast, though: it's a product failure. It happens during the project lifecycle, usually pretty early on, but it's the first step towards product failure, even if the project is a complete success.
Self-professed experts will tell you that requirements gathering is the most critical part of the project, because if you get it wrong, then all the rest of your work goes towards building the wrong thing. This is sooooort of true, in a skewed way, but it's not the complete picture.
The problem with this view is that requirements gathering basically never works. How many times have you seen a focus group gather requirements from customers, then the product team builds the product, and you show it to your customers and they sing: "Joy! This is exactly what we wanted! You understood me perfectly! I'll buy 500 of them immediately!" And the sun shines and the grass greens and birds chirp and end-credit music plays.
That never happens. What really happens is this: the focus group asks a bunch of questions; the customers have no frigging clue what they want, and they say contradictory things and change the subject all the time, and the focus group argues a lot about what the customers really meant. Then the product team says "we can't build this, not on our budget", and a negotiation process happens during which the product mutates in various unpleasant ways. Then, assuming the project doesn't fail, they show a demo to the original customers, who say: "This is utterly lame. Yuck!" Heck, even if you build exactly what the customer asked for, they'll say: "uh, yeah, I asked for that, but now that I see it, I clearly wanted something else."
So the experts give you all sorts of ways to try to get at the Right Thing, the thing a real customer would actually buy, without actually building it. You do mockups and prototypes and all sorts of bluffery that the potential customer can't actually use, and they have to imagine whether they'd like it. It's easy enough to measure usability this way, but virtually impossible to measure quality, since there are all sorts of intangibles that can't be expressed in the prototype. I mean, you can try — we sure tried on the OmniGo products — but in this phase nobody "imagines" that the thing will weigh too much, or be too slow, or will go through batteries like machine-gun rounds, or that its boot time will be 2 minutes, or any number of other things that ultimately affect its sales.
And even if you do a world-class job of prototyping and getting at the "real" desired feature set, it still goes through a series of iterations with the engineers and product team, who aren't the actual customers and have little interest in building what the customer really wants (because they're not being measured or evaluated on that — they're evaluated on delivering what everyone ultimately agrees to deliver). During each iteration they push back on things the customers asked for. As the proposal degrades, the customers like it less and less, but they want to be helpful, so eventually they say, "Yeah, I guess I could use that." (Which means: I wouldn't take one of these even if they were giving it away.)
Don't get me wrong: I'm not saying that usability teams can't do a good job. It's just that when the project implementation team and the target customer aren't exactly the same group of people, then there are inevitably negotiations and compromises that water an idea down about two levels of quality: great becomes mediocre, and ideas that start as "pretty good" come out "just plain bad."
So I'm tellin' ya: gathering requirements is the Wrong Way To Do It. At best, it results in mediocre offerings. To be wildly successful you need a completely different approach.
The investing analogy
Warren Buffett and Peter Lynch, both famous and successful investors, say pretty much the same thing about investing. Peter Lynch's mantra sums it up: "invest in what you know."
If you actually take the time to read Lynch's books (which I have), you'll see that this pithy mantra is a placeholder for something a bit more subtle: you should invest in what you know and like. You should invest in companies that make products or services that you are personally excited about buying or using right now.
When you invest with this strategy, you're taking advantage of your local knowledge, which tends to be more accurate than complicated quantitative packets put together by analysts. And your local knowledge is definitely more accurate than the reports produced by the companies, who want to paint themselves in the nicest light.
Warren took a lot of heat in the 1990s for not investing in the tech sector. But hey, he didn't feel comfortable with tech, so he didn't invest in it. One way to look at this is: "ha ha, what a dinosaur, he sure missed out, and now he's, uh, only the richest person in the world by a small margin." But another, more accurate way to look at it is this: he's the richest person in the world, you asshole. When he gives you investment advice, take it!
And Warren's advice is: don't invest in stuff you don't understand! Even if it seems like a sure thing.
That's the hard part. Sometimes it looks like a surefire winner for some large group of people that doesn't actually include you personally at this particular moment. But it's a really large group!
Let's say, for instance, that you hear that Subway (the sandwich franchise) is going to do an IPO. They've been privately held all these years and now they're going public. Should you invest? Well, let's see... the decision now isn't quite as cut-and-dried as it was in their rapid-expansion phase, so, um, let me see, with current economic conditions, I expect their sales to, uh... let me see if I can find their earnings statement and maybe some analyst reports...
No! No, No, NO!!! Bad investor! That's the kind of thinking that loses your money. The only question you should be asking yourself is: how many Subway sandwiches have I eaten in the past six months? If the number is nontrivial — say, at least six of them — and the rate of sandwiches per month that you eat is either constant or increasing, then you can think about looking at their financials. If you don't eat their sandwiches, then you'd better have a LOT of friends who eat them every day, or you're breaking the cardinal rule of Buffett and Lynch.
The investing analogy is an important one, because if you're a company or team planning to build something, then you're planning an investment. It's not exactly the same as buying stock, but it amounts to the same thing: you're betting your time, resources and money — all of which boil down to money (or equivalently time, depending on which one is in shorter supply.)
So when translated into project selection, Buffett's and Lynch's advice becomes: only build what you know. The longer, more accurate of the version of the investing rule — only invest in what you know and are excited about using yourself right now — has a simpler formulation for products and businesses. That formulation goes like this:
That's the Golden Rule of Building Stuff. If you're planning to build something for someone else, let someone else build it.
Building stuff for yourself
You can look at any phenomenally successful company, and it's pretty obvious that their success was founded on building on something they personally wanted. The extent that any company begins to deviate from this course is the extent to which their ship starts taking on water.
And the key leading indicator that they're getting ready to head off course? You guessed it: it's when they start talking about gathering business requirements.
Because, dude, face it: if it's something you want, then you already know what the requirements are. You don't need to "gather" them. You think about it all the time. You can list the requirements from memory. And usually it's pretty simple.
For instance, a few years ago I announced to some friends: "I sure wish someone would make a product you can spray on dog poop to make it, you know, just dissolve away." My friends laughed loudly and informed me that this was (apparently) the premise of some Adam Sandler movie I hadn't seen.
Well, OK, sure, but... I mean, they kinda missed the point. I still want the product. Its requirements list is pretty simple. Here's the business requirements list:
a) It should dissolve dog poop.
Gosh. Can that really be the entire list? You bet! Sure, there are lots of implicit requirements: it shouldn't cost a fortune, it should be environmentally friendly, it shouldn't kill kittens, etc. But those kinds of requirements are true for all products and services.
If I knew how to make this product, then Adam Sandler movie or no, I'd probably try to make it. The target market is larger than just pet owners; anyone living near a park would probably own a bottle or two. I would use the stuff like it's going out of style. I'd attach it to my shoes so that every time I took a step it would spray the area in front of me, like a walking garden hose.
Building a product for yourself is intrinsically easier, since you don't have to gather requirements; you already know what you want. And you also know, for any given compromise anyone suggests, whether it will ruin the product. If someone says, "I have a product that dissolves dog poop, but it takes 18 hours", then you'll know you've entered into "prolly not worth it" territory. You don't have to go ask the focus group. You just know.
The Mistake of Imagination
Despite its obvious advantages, following the rule of building stuff for yourself is actually really hard to carry out in practice. Why? Oddly enough, it's ego.
For one thing, people like to think they're unique and special, and that their tastes aren't necessarily widely shared by others. This is what drives fashion: the need to differentiate yourself from "the crowd", by identifying with some smaller, cooler crowd.
The reality is that for any given dimension of your personality, there are oodles of people just like you. If you want something, other people want it too. You define a market: a bunch of them, in fact.
You just have to be smart about which of your needs you want to fulfill, since if it's building yachts, well, it's not exactly going to be mass-market, unless you find a way to build a mass-market yacht. Which would be pretty cool, incidentally. I'll buy one if you make it.
It's also really easy to fool yourself into thinking that this is a product or service you would use, because, hey, you have a great imagination. When you lose your car keys, you can picture them in all sorts of places: the kitchen drawer, the coffee table, on top of the fridge, and when you picture them there, it's just as vivid as a memory. So you wind up looking for them everywhere! Your powerful imagination is pretty much your worst enemy when it comes to deciding whether you'd like something enough to use it yourself.
We all made the Mistake of Imagination on the OmniGo projects. "I could see myself using this product," we'd tell ourselves, "if, that is, I were the kind of person who used this product, which I could sort of envision." You'll tell yourself almost anything to justify the work you're doing. Giving up in mid-project is a big loss of face for an individual, harder for whole teams, virtually impossible for most companies. The OmniGo had four companies involved, making it the hardest possible project to back out of, even though by the halfway point virtually everyone involved knew the product would kind of suck.
What we really wanted, while we were building the OmniGo, was summed up by our brilliant product manager Jeff Peterson. We were having beers one day, and he said, "You know, this thing is just getting way too complicated! It doesn't need a 12C calculator emulator! It doesn't need a spreadsheet! It doesn't need a database application! I mean, come on! All it needs is a notepad, a simple calendar, an alarm clock, and maybe a pocket calculator, and it should fit in your front shirt pocket, and it should be a phone."
It was 1994 and he was describing the iPhone. And you know what? He was right! That was what we wanted. But HP was driving the spec, and they weren't building it for themselves. They were building the product specifically for this imaginary group of high-power on-the-go consumer accountants who use 12C calculators and want a whole desktop suite crammed onto their 1994-era mobile device. And that's just who bought the thing: pretty much nobody. (They sold a few thousand units, which in mass-market terms is "pretty much nobody.")
Trimming the Requirements
Who was it who said that you're done writing not when there's nothing left to add, but when there's nothing left to take away? Was it St. Exupéry? I promised not to do any research for this rant, but I think it might have been him.
Ideally the product you're building for yourself should be simple to describe, so that other people can quickly evaluate whether they, too, want this thing. It's often called the "elevator pitch", because you should be able to describe the product in the time between when the cable snaps and the elevator hits the ground. "Dissolves dog poooooop!!! <crash>" It used to just be the time for an elevator ride, but those investors keep raising the bar.
You can almost always make a product better by trimming the requirements list. We're talking brutal triage: throwing out stuff that's really painful to lose, such as the ability to change the battery.
If you're lucky, you should be building a product that so excites everyone involved that everyone has an opinion, and you wind up spending most of your time in triage.
When you're trimming the business requirements, then you're exhibiting healthy project behavior. This contrasts directly with gathering requirements, which has both the connotation that you're clueless about the product and the connotation that you're inflating the requirements list in direct conflict with schedule, usability and fashion. Trimming: good. Gathering: bad.
Trimming the requirements list is a leading indicator that you're a smart company who's about to launch something major. An ideal requirements list looks something like this:
a) It should dissolve dog poop.
As a great real-life example, consider the the Flip camcorder, which kinda came out of nowhere and "stole" 13% of the camcorder market (although I'd bet good money that it actually created new market share). Does it dissolve dog poop? Well, no, but it's still pretty cool:
1) it costs $150 or less. (A lot less, actually.)
2) it has no cables or wires. Just one flip-up USB connector.
3) it has one big red button: RECORD, plus a teeny one for playback.
4) it doesn't take cartridges or cassettes or discs or cards or anything
5) it doesn't have any controls or settings or anything
6) it stores one hour of video and has roughly one hour of battery life
7) it's about the size of a cell phone
8) it records videos that work well with YouTube
9) it comes in pretty colors
I mean, DAMN, those guys knew what they were doing. We always used to joke about a product so simple that it only had one button, which we pressed for you before it left the factory. That's how simple a product needs to be in order to make the mass market. One button, pretty colors. They nailed it. Talk about a missed startup opportunity. (Flip guys: if your equity plan is still reasonable and you want someone to make your desktop software not suck, and yes, it really sucks, please give me a call.)
You don't need an original idea to be successful. You really don't. You just need to make something that people want. Even if someone else appears to be making something popular, it's usually possible to improve on the idea and grab market share. And it's painfully counterintuitive at times, but the best improvements often come from simplifying.
The easiest way to build a product that kicks ass is to start with someone else's great idea (camcorders, for instance), and take stuff away.
In any event, originality is overrated. Coming up with something completely original isn't just hard to do: it's also hard to sell, because investors (and possibly customers) will need to be educated on what this new thing is and why people would want it. And when it comes to buying stuff, nobody likes to be educated. If the product isn't immediately obvious, investors and customers will pass it up.
It's easy to come up with new product ideas if you start with the understanding that everything sucks. There are no completely solved problems. Just because someone appears to be dominating a market with an "ideal" offering doesn't mean you can't take market share from them by building a better one. Everything can stand improvement. Just think about what you'd change if you were doing it for yourself, and everything should start falling into place.
If nothing else, building things for yourself is more fun, so you're successful regardless of what happens. But it also has great product-survival characteristics, because people can't bluff you into making something lame.
Sometimes you just can't win
By way of don't-sue-me disclaimer, I should point out that building something for yourself doesn't guarantee success. Even if you build a product that most of your target market really really wants, and you hit the right price point and release date and everything, your product can still fail catastrophically.
The example that leaps to mind is that company in the 1990s (can anyone remind me of the name? I've forgotten) that built a mountain-bike seat extender. I ride mountain bikes, yes, on actual mountains, so this product made immediate sense to me. I really wanted one. Sounds like a winner, right?
The basic physics problem this company was solving is that a lower seat position gives you better balance, and a higher seat position gives you more power. It's a trade-off. You generally want more power when you're grinding uphill, and you want more balance when you're speeding downhill. But during a race you would have to give up precious seconds to adjust your seat between every uphill and downill transition; you'd get your butt kicked. Even as a casual rider, adjusting your seat height all the time is annoying enough that most people just don't do it, resulting in some sacrifice of balance, power, or both.
So this brilliant, innovative company came out with a well-made product that lets you adjust your seat height "in flight", as it were, without slowing down, and without adding much (if any) weight to the bike. I don't remember exactly how it worked, but it was a reasonable implementation.
Interestingly, it didn't matter how it worked. It could have been actual magic: a product that read your mind and raised or lowered your seat by exactly the right amount, at exactly the right speed (you don't want it to rabbit-punch you in the nuts, for example — remind me sometime to tell you about how I found that out), as frequently or infrequently as necessary to strike the perfect trade-off of balance and power for any slope, at any time.
And it still would have failed, even if 90% of the mountain biker population, like me, secretly coveted the product. It could have cost fifty cents, been available everywhere, and been installable by a four-year-old with one hand in under two seconds. It could have come pre-installed on all bike models, via a brilliant channel deal with all the main manufacturers (or retailers), and bikers would have ripped the thing off the bike faster than their kickstand (which is usually the first thing to go.)
So, uh, what happened, exactly? Wasn't I just ranting that building a product for yourself, one that you know is the Right Thing for some well-defined audience consisting of people just like you in some dimension — wasn't I ranting that this would always work?
Well, no. It's just the best way to pick projects. But they can still fail for surprising reasons.
In this case, the fundamental marketing force that the company failed to take into account was fashion. People don't often think of mountain biking (or programming, for that matter) as a fashion industry, but failing to understand the role of fashion is a recipe for random disasters.
What happened was this: while they were hyping the product — by demoing it at trade shows, letting bike magazines check it out, and generally working their way towards getting retailer shelf space — the pro bikers took one look at the thing and said: "Hey, looks pretty cool. Maybe I'll get one for my girlfriend. Or my fugging grandma. How much is it?"
At which point, everyone (me included) who had been ranting about standing in line to buy one when they came out, we, ah, we were very quick to point out that we were also excited to buy them for our grandmothers, whom we loved just as much as the pros love their grandmothers, thank you very much. In fact, our grandmothers are too macho to use this thing. Maybe we'll put one on our kid's stroller! So there!
And that's how a great product, one that probably would have changed biking nearly as fundamentally as the derailleur, was doomed from birth because the trendsetters of Mountain Biking Fashion pronounced it a Product for Sissies, and that was that.
Heck, even derailleurs are falling out of fashion in some circles. Go figure. Someone took the time-tested "solved problem" of bicycles, removed something, and wound up creating a new market.
Fashion is generally hard to predict, but it usually means "sacrificing comfort or convenience for the sake of style". Take another look at the iPod: it has almost no features. It doesn't have an "off" button. Heck, you can't even change the battery. Not exactly convenient in many ways. But it sure has style!
Fashion's not the only way your otherwise perfect product can fail, but it's definitely one to keep an eye on.
Less is more... more or less
OK, fine, I haven't exactly been following my own advice about minimalism. But I have been writing my blog the way I like it, haven't I? So even if nobody reads it, I'm still having fun. If you're going to create something that has a nonzero chance of failure — and believe you me, it's nonzero — then you might as well have fun doing it, right?
Anyway, there you have it: the slightly expanded version of the email I sent that CEO guy. Gathering business requirements is hokum. Hooey. Horseshit. Call it what you want, but it's a sign of organizational (or individual) cluelessness. If you don't already know exactly what to build, then you're in the wrong business. At the very least, you should hire someone who does know. Don't gather business requirements: hire domain experts.
If you can't think of anything in your company's "space" that you personally would use, then you should think seriously about (a) changing your company's direction, or (b) finding another company. This is true no matter what level you're at. You should be working on something you love, or failing that, at least working on something that you know really well.
"But... but..." I hear you saying. I hear you! You sort of get what I'm saying, but you have all these reservations and objections and questions and stuff.
Well, that's what the comments section is for. I'm sure you can think of some other explanation for why Warren Buffett is the richest person in the world. Let's hear it!
Minggu, 10 Agustus 2008
Rabu, 06 Agustus 2008
MIPA Tidak Membumi (?)
Kompas, 31 Agustus 2002 yang lalu memuat tulisan seorang siswa SD yang berjudul “Monster Matematika”. Tulisan itu mengungkapkan bahwa matematika yang diajarkan di sekolah itu membosankan, nyebelin, dan tidak menyenangkan. Gurunya kadang galak, dan suka mencela apabila siswa tidak bisa mengerjakan soal. Meskipun sudah berusaha dengan mengikuti les, memperhatikan ketika guru mengajar, mengerjakan PR ataupun soal-soal latihan, tapi nilai yang diperoleh siswa tetap saja “jeblok”. Sebuah ungkapan hati yang polos dan jujur tentang matematika. Sebagai seorang guru matematika, penulis merasa tersentuh, trenyuh dan prihatin sekaligus tertampar. Itulah potret pembelajaran matematika di sekolah kita.
Selama ini pelajaran matematika dan Ilmu Pengetahuan Alam (MIPA) seringkali menjadi “momok” bagi sebagian besar siswa. Siswa merasa takut dengan pelajaran MIPA, khususnya matematika. Stereotif bahwa pelajaran MIPA adalah pelajaran sulit telah menyebabkan pelajaran MIPA tidak dipandang secara obyektif lagi. Seolah MIPA identik dengan “sulit”. Ketidaknetralan MIPA sebagai ilmu pengetahuan salah satunya dipengaruhi oleh guru yang mengajarkan MIPA. Seringkali sebenarnya ketidaksenangan siswa terhadap pelajaran MIPA disebabkan oleh guru yang galak, terlalu cepat dalam menyampaikan materi ajar ataupun monoton, kurangnya variasi dalam pengajaran. Sehingga siswa merasa takut, jenuh dan tidak tertarik untuk mempelajarinya secara lebih mendalam. Jadi sebenarnya, yang menjadi “momok” adalah guru, bukan pelajaran MIPA itu sendiri. Karena pada dasarnya sebagai ilmu pengetahuan MIPA bersifat netral.
Terkait dengan pengajaran MIPA, Mendiknas A. Malik Fadjar menilai bahwa cara pengajaran MIPA yang dilakukan guru selama ini hanya melahirkan hafalan dan bukan melatih olah pikir. Akibatnya, meskipun sudah mempelajari MIPA, siswa tetap saja tidak bisa berasosiasi atau memiliki gambaran yang jelas yang dihasilkan oleh olah pikirnya. Tidak mengherankan apabila pelajaran MIPA menjadi sesuatu yang membosankan(Kompas, 3 September 2002).
Namun tidak adil rasanya, kalau permasalahan yang terjadi dalam pembelajaran MIPA hanya ditimpakan kepada para guru sebagai faktor penyebabnya. Perlu kiranya untuk mengedepankan pertanyaan, mengapa cara pengajaran guru MIPA hanya melahirkan hafalan dan bukan melatih olah pikir siswa? Untuk menjawab pertanyaan tersebut, tidak bisa hanya melihat MIPA secara partial saja. Tetapi MIPA harus dilihat sebagai bagian integral dari proses pendidikan yang berlangsung di negeri ini. Dan hubungannya dengan itu, materi pelajaran MIPA yang sangat padat tidak terlepas dari kurikulum pendidikan yang digunakan. Harus diakui bahwa kurikulum pendidikan yang berlaku sangat padat dan cukup sulit. Menurut Drost (1998), kurikulum SMU 1994 hanya dapat diikuti oleh 30% siswa. Tanpa kecuali kurikulum MIPA. Seolah semua materi ingin diberikan kepada siswa. Selain itu kurikulum MIPA juga tidak sisematis dan tidak berkelanjutan.
Akibatnya praksis pengajaran MIPA di sekolah masih didominasi proses transfer pengetahuan. Materi yang banyak dan sulit dan tuntutan menyelesaikan seluruh materi ajar telah membuat guru kehilangan kreativitasnya dalam pengajaran. Yang terjadi adalah guru mengajar dengan cepat, namun tidak mendalam. Tidak berani bereksplorasi dengan berbagai variasi metode pengajaran. Pembelajaran MIPA dilakukan dengan pola instruksi bukan konstruksi dan rekonstruksi pengetahuan (Rohandi, 1998). Bahkan tanpa memberikan tempat bagi siswa untuk menentukan sendiri kearah mana siswa ingin bereksplorasi dalam menemukan pengetahuan yang bermakna bagi dirinya. Tuntutan untuk memperoleh nilai tinggi dalam ujian, telah menghasilkan pembelajaran yang melahirkan siswa yang pandai menghafal konsep-konsep dan rumus-rumus. Siswa hanya berlatih soal-soal yang biasanya digunakan dalam berbagai tes, tanpa mampu menggali pengetahuan sendiri dan menerapkannya dalam memecahkan persoalan yang dialami dalam kehidupan kesehariannya.
Pada hakekatnya pelajaran MIPA mencakup tiga aspek. (1) aspek produk, yaitu prinsip-prinsip, hukum-hukum dan teori atau konsep di dalam pelajaran MIPA. (2) aspek proses, yaitu metode atau cara yang digunakan untuk memperoleh pengetahuan. (3) aspek sikap, yaitu sikap keilmuan yang merupakan berbagai keyakinan, opini dan nilai-nilai yang harus dipertahankan oleh orang yang mempelajarinya. Namun kecenderungan yang terjadi dalam pengajaran MIPA di Indonesia lebih menekankan pada aspek produk MIPA. Prinsip, hukum dan teori lebih ditekankan dan mendapatkan porsi yang lebih besar dan dominan, sehingga aspek proses dan aspek sikap kurang mendapatkan perhatian yang cukup. Akibatnya pembelajaran MIPA menjadi “kering” dan membosankan. Pelajaran MIPA seolah dianggap terpisah dan terlepas dari realitas kehidupan sehari-hari.
Tantangan pembelajaran MIPA ke depan adalah bagaimana mencari bentuk pembelajaran MIPA dimana seluruh aspek yang tercakup didalamnya dapat dipelajari secara utuh. Konsep, prinsip dan teori tidak hanya diberikan dalam bentuk jadi, tapi diusahakan agar para siswa dalam pembelajaran juga menjalani proses mengalami dan menemukan pengetahuan tersebut. Dalam proses mengalami dan menemukan itulah, guru mempunyai kesempatan untuk memperhatikan dan membimbing sikap dan perilaku siswa. Apabila pembelajaran MIPA dilakukan dengan berpegang pada hakekat MIPA sendiri, maka sebenarnya pembelajaran MIPA tidak akan pernah mengasingkan peserta didik dari realitas kehidupannya.
Beberapa pemikiran yang bisa dilakukan untuk pembelajaran MIPA saat ini, agar pembelajaran MIPA bermakna dan berdampak bagi peserta didik adalah: Pertama, kreativitas guru untuk menyiasati kurikulum yang sedang berlaku. Karena apabila guru hanya mengajar sesuai dengan juklak atau juknis kurikulum, maka seperti yang diuraikan diatas, guru hanya cenderung mengejar penyelesaian materi ajar tanpa memperhatikan kesulitan yang dihadapi siswa. Untuk itu, guru perlu menyiasati kurikulum dengan cara memilih dan memilah materi yang penting bagi siswa dan memberikan materi tersebut secara berkelanjutan. Bahkan kalau perlu membuang materi yang tidak penting. Sehingga tidak terlalu banyak materi yang diberikan, tapi materi dapat diajarkan dengan lebih mendalam. Pembelajaran MIPA untuk ke depan harus mengarah pada aspek kedalaman dari pada aspek keluasan. Hal ini juga akan memberikan waktu yang lebih leluasa bagi guru dan siswa untuk bereksplorasi. Seiring dengan bergulirnya otonomi pendidikan, seharusnya sekolah lebih leluasa untuk mengolah kurikulum yang ada untuk disesuaikan dengan kebutuhan.
Kedua, inovasi guru dalam pembelajaran. Variasi metode pembelajaran memegang peranan penting untuk menarik minat siswa dalam pembelajaran MIPA. Inilah kiranya yang dibutuhkan saat ini, yaitu mengembalikan minat siswa pada pelajaran MIPA, mengingat selama ini pelajaran MIPA dianggap sebagai “momok” bagi sebagian besar siswa. Inovasi dalam metode pembelajaran dengan berbagai variasi sesuai dengan materi ajar, akan membuat siswa tidak jenuh atau bosan dalam mengikuti pembelajaran. Proses mengalami dan menemukan dapat dilakukan dengan latihan ataupun menurunkan rumus-rumus. Dengan memanfaatkan fasilitas Audio Visual untuk beberapa materi ajar, kiranya lebih menarik dari pada disampaikan dengan ceramah.
Demikian juga dengan metode observasi lapangan, dimana pembelajaran tidak melulu dilaksanakan di kelas, merupakan salah satu variasi pembelajaran yang akan membantu meningkatkan minat siswa terhadap pelajaran MIPA. Hal ini juga akan lebih memberi kesempatan kepada siswa untuk lebih banyak berekplorasi, selain mengurangi kejenuhan dalam pembelajaran.
Ketiga, mengaitkan materi ajar dengan peristiwa atau kejadian dalam kehidupan nyata sehari-hari. Hal ini penting untuk menghindari pelajaran MIPA hanya sebagai konsep atau teori belaka. Dengan menunjukkan keterkaitan MIPA dengan realitas kehidupan, akan menjadikan pelajaran MIPA bermakna bagi siswa. Siswa dapat menerapkan konsep atau teori yang dipelajarinya untuk memecahkan persoalan riil yang dihadapi dalam keseharian. Metode problem solving kiranya cukup mambantu dalam hal ini, dimana soal-soal yang diambil terkait dengan permasalahan nyata dalam kehidupan masyarakat. Dengan demikian pelajaran MIPA akan lebih membumi.@
HJ. Sriyanto
Guru Matematika di SMU Kolese Debritto
Jl. Laksda Adisucipto 161 Yogyakarta 55281
Selama ini pelajaran matematika dan Ilmu Pengetahuan Alam (MIPA) seringkali menjadi “momok” bagi sebagian besar siswa. Siswa merasa takut dengan pelajaran MIPA, khususnya matematika. Stereotif bahwa pelajaran MIPA adalah pelajaran sulit telah menyebabkan pelajaran MIPA tidak dipandang secara obyektif lagi. Seolah MIPA identik dengan “sulit”. Ketidaknetralan MIPA sebagai ilmu pengetahuan salah satunya dipengaruhi oleh guru yang mengajarkan MIPA. Seringkali sebenarnya ketidaksenangan siswa terhadap pelajaran MIPA disebabkan oleh guru yang galak, terlalu cepat dalam menyampaikan materi ajar ataupun monoton, kurangnya variasi dalam pengajaran. Sehingga siswa merasa takut, jenuh dan tidak tertarik untuk mempelajarinya secara lebih mendalam. Jadi sebenarnya, yang menjadi “momok” adalah guru, bukan pelajaran MIPA itu sendiri. Karena pada dasarnya sebagai ilmu pengetahuan MIPA bersifat netral.
Terkait dengan pengajaran MIPA, Mendiknas A. Malik Fadjar menilai bahwa cara pengajaran MIPA yang dilakukan guru selama ini hanya melahirkan hafalan dan bukan melatih olah pikir. Akibatnya, meskipun sudah mempelajari MIPA, siswa tetap saja tidak bisa berasosiasi atau memiliki gambaran yang jelas yang dihasilkan oleh olah pikirnya. Tidak mengherankan apabila pelajaran MIPA menjadi sesuatu yang membosankan(Kompas, 3 September 2002).
Namun tidak adil rasanya, kalau permasalahan yang terjadi dalam pembelajaran MIPA hanya ditimpakan kepada para guru sebagai faktor penyebabnya. Perlu kiranya untuk mengedepankan pertanyaan, mengapa cara pengajaran guru MIPA hanya melahirkan hafalan dan bukan melatih olah pikir siswa? Untuk menjawab pertanyaan tersebut, tidak bisa hanya melihat MIPA secara partial saja. Tetapi MIPA harus dilihat sebagai bagian integral dari proses pendidikan yang berlangsung di negeri ini. Dan hubungannya dengan itu, materi pelajaran MIPA yang sangat padat tidak terlepas dari kurikulum pendidikan yang digunakan. Harus diakui bahwa kurikulum pendidikan yang berlaku sangat padat dan cukup sulit. Menurut Drost (1998), kurikulum SMU 1994 hanya dapat diikuti oleh 30% siswa. Tanpa kecuali kurikulum MIPA. Seolah semua materi ingin diberikan kepada siswa. Selain itu kurikulum MIPA juga tidak sisematis dan tidak berkelanjutan.
Akibatnya praksis pengajaran MIPA di sekolah masih didominasi proses transfer pengetahuan. Materi yang banyak dan sulit dan tuntutan menyelesaikan seluruh materi ajar telah membuat guru kehilangan kreativitasnya dalam pengajaran. Yang terjadi adalah guru mengajar dengan cepat, namun tidak mendalam. Tidak berani bereksplorasi dengan berbagai variasi metode pengajaran. Pembelajaran MIPA dilakukan dengan pola instruksi bukan konstruksi dan rekonstruksi pengetahuan (Rohandi, 1998). Bahkan tanpa memberikan tempat bagi siswa untuk menentukan sendiri kearah mana siswa ingin bereksplorasi dalam menemukan pengetahuan yang bermakna bagi dirinya. Tuntutan untuk memperoleh nilai tinggi dalam ujian, telah menghasilkan pembelajaran yang melahirkan siswa yang pandai menghafal konsep-konsep dan rumus-rumus. Siswa hanya berlatih soal-soal yang biasanya digunakan dalam berbagai tes, tanpa mampu menggali pengetahuan sendiri dan menerapkannya dalam memecahkan persoalan yang dialami dalam kehidupan kesehariannya.
Pada hakekatnya pelajaran MIPA mencakup tiga aspek. (1) aspek produk, yaitu prinsip-prinsip, hukum-hukum dan teori atau konsep di dalam pelajaran MIPA. (2) aspek proses, yaitu metode atau cara yang digunakan untuk memperoleh pengetahuan. (3) aspek sikap, yaitu sikap keilmuan yang merupakan berbagai keyakinan, opini dan nilai-nilai yang harus dipertahankan oleh orang yang mempelajarinya. Namun kecenderungan yang terjadi dalam pengajaran MIPA di Indonesia lebih menekankan pada aspek produk MIPA. Prinsip, hukum dan teori lebih ditekankan dan mendapatkan porsi yang lebih besar dan dominan, sehingga aspek proses dan aspek sikap kurang mendapatkan perhatian yang cukup. Akibatnya pembelajaran MIPA menjadi “kering” dan membosankan. Pelajaran MIPA seolah dianggap terpisah dan terlepas dari realitas kehidupan sehari-hari.
Tantangan pembelajaran MIPA ke depan adalah bagaimana mencari bentuk pembelajaran MIPA dimana seluruh aspek yang tercakup didalamnya dapat dipelajari secara utuh. Konsep, prinsip dan teori tidak hanya diberikan dalam bentuk jadi, tapi diusahakan agar para siswa dalam pembelajaran juga menjalani proses mengalami dan menemukan pengetahuan tersebut. Dalam proses mengalami dan menemukan itulah, guru mempunyai kesempatan untuk memperhatikan dan membimbing sikap dan perilaku siswa. Apabila pembelajaran MIPA dilakukan dengan berpegang pada hakekat MIPA sendiri, maka sebenarnya pembelajaran MIPA tidak akan pernah mengasingkan peserta didik dari realitas kehidupannya.
Beberapa pemikiran yang bisa dilakukan untuk pembelajaran MIPA saat ini, agar pembelajaran MIPA bermakna dan berdampak bagi peserta didik adalah: Pertama, kreativitas guru untuk menyiasati kurikulum yang sedang berlaku. Karena apabila guru hanya mengajar sesuai dengan juklak atau juknis kurikulum, maka seperti yang diuraikan diatas, guru hanya cenderung mengejar penyelesaian materi ajar tanpa memperhatikan kesulitan yang dihadapi siswa. Untuk itu, guru perlu menyiasati kurikulum dengan cara memilih dan memilah materi yang penting bagi siswa dan memberikan materi tersebut secara berkelanjutan. Bahkan kalau perlu membuang materi yang tidak penting. Sehingga tidak terlalu banyak materi yang diberikan, tapi materi dapat diajarkan dengan lebih mendalam. Pembelajaran MIPA untuk ke depan harus mengarah pada aspek kedalaman dari pada aspek keluasan. Hal ini juga akan memberikan waktu yang lebih leluasa bagi guru dan siswa untuk bereksplorasi. Seiring dengan bergulirnya otonomi pendidikan, seharusnya sekolah lebih leluasa untuk mengolah kurikulum yang ada untuk disesuaikan dengan kebutuhan.
Kedua, inovasi guru dalam pembelajaran. Variasi metode pembelajaran memegang peranan penting untuk menarik minat siswa dalam pembelajaran MIPA. Inilah kiranya yang dibutuhkan saat ini, yaitu mengembalikan minat siswa pada pelajaran MIPA, mengingat selama ini pelajaran MIPA dianggap sebagai “momok” bagi sebagian besar siswa. Inovasi dalam metode pembelajaran dengan berbagai variasi sesuai dengan materi ajar, akan membuat siswa tidak jenuh atau bosan dalam mengikuti pembelajaran. Proses mengalami dan menemukan dapat dilakukan dengan latihan ataupun menurunkan rumus-rumus. Dengan memanfaatkan fasilitas Audio Visual untuk beberapa materi ajar, kiranya lebih menarik dari pada disampaikan dengan ceramah.
Demikian juga dengan metode observasi lapangan, dimana pembelajaran tidak melulu dilaksanakan di kelas, merupakan salah satu variasi pembelajaran yang akan membantu meningkatkan minat siswa terhadap pelajaran MIPA. Hal ini juga akan lebih memberi kesempatan kepada siswa untuk lebih banyak berekplorasi, selain mengurangi kejenuhan dalam pembelajaran.
Ketiga, mengaitkan materi ajar dengan peristiwa atau kejadian dalam kehidupan nyata sehari-hari. Hal ini penting untuk menghindari pelajaran MIPA hanya sebagai konsep atau teori belaka. Dengan menunjukkan keterkaitan MIPA dengan realitas kehidupan, akan menjadikan pelajaran MIPA bermakna bagi siswa. Siswa dapat menerapkan konsep atau teori yang dipelajarinya untuk memecahkan persoalan riil yang dihadapi dalam keseharian. Metode problem solving kiranya cukup mambantu dalam hal ini, dimana soal-soal yang diambil terkait dengan permasalahan nyata dalam kehidupan masyarakat. Dengan demikian pelajaran MIPA akan lebih membumi.@
HJ. Sriyanto
Guru Matematika di SMU Kolese Debritto
Jl. Laksda Adisucipto 161 Yogyakarta 55281
Membaca Kecemasan Anak Terhadap Matematika
Seringkali matematika dianggap sebagai “momok”, dipersepsi sebagai pelajaran yang sulit oleh sebagian siswa sekolah. Anak merasa deg-degan, cemas dan takut setiap kali mengikuti pelajaran matematika di sekolah. Bahkan ada anak yang karena begitu takutnya terhadap matematika, sampai “mandi keringat” ketika diminta untuk mengerjakan soal di papan tulis. Matematika bagi sebagian anak telah menimbulkan kecemasan tersendiri.
Ada beberapa hal yang kiranya dapat diajukan sebagai faktor penyebab timbulnya kecemasan anak terhadap matematika. Pertama, matematika sebagai salah satu bidang studi yang diajarkan di sekolah merupakan cabang ilmu yang spesifik. Berbeda dengan ilmu pengetahuan lain, matematika tidak mempelajari obyek-obyek yang secara langsung dapat ditangkap oleh indera manusia. Substansi matematika adalah benda-benda pikir yang bersifat abstrak. Walaupun pada awalnya matematika lahir dari hasil pengamatan empiris terhadap benda-benda konkret (geometri), namun dalam perkembangannya matematika lebih memasuki dunianya yang abstrak. Obyek matematika adalah fakta, konsep, operasi dan prinsip yang kesemuannya itu berperan dalam membentuk proses berpikir matematis, dengan salah satu cirinya adalah adanya alur penalaran yang logis. Sehingga apabila dibandingkan dengan bidang studi lain, matematika relatif dianggap lebih sulit, karena dibutuhkan konsistensi dalam mempelajarinya.
Kedua, persepsi yang berkembang dalam masyarakat bahwa matematika sulit, telah mengkooptasi pikiran sebagian anak. Sehingga anak akan beranggapan seperti demikian, ketika berhadapan dengan matematika. Pandangan bahwa matematika merupakan ilmu yang kering, abstrak, teoritis, banyak rumus yang sulit dan membingungkan, yang didasarkan atas pengalaman kurang menyenangkan ketika belajar matematika di sekolah, telah membangun persepsi negatif pada diri anak. Hal ini telah membangun jarak antara anak dengan matematika. Sehingga sebagai ilmu pengetahuan matematika tidak dipandang secara netral lagi.
Ketiga, pembelajaran matematika yang “kering”, monoton dan guru yang cenderung represif, membuat anak merasa tertekan. Anak cenderung menutup diri, kurang dapat bereksplorasi dan mengekspresikan dirinya dalam proses pembelajaran. Pembelajaran matematika pun akhirnya tidak menjadi media untuk melatih olah pikir, melainkan matematika dipahami dengan cara menghafal.
Keempat, tuntutan untuk mendapatkan nilai yang baik dalam pelajaran matematika dari orang tua dan juga guru, tanpa disadari telah membuat anak cenderung berorientasi pada hasil atau nilai yang tinggi dalam matematika, tetapi mengabaikan proses. Dan ketika anak mendapatkan hasil yang kurang memuaskan, mereka akan merasa tertekan dan menganggap dirinya bodoh. Meskipun nilai yang diperoleh baik, tapi pengetahuan yang dikuasainya sangat minim, karena secara konseptual memang sebenarnya anak tidak banyak paham.
Matematika memegang peranan yang cukup penting dalam kehidupan manusia. Sebenarnya hampir setiap hari manusia bersentuhan dengan matematika. Banyak yang telah disumbangkan matematika untuk kemajuan perababan manusia. Perkembangan teknologi dan juga ilmu pengetahuan lain, tidak lepas dari peranan matematika. Oleh karenanya mempelajari dan menguasai matematika dengan baik adalah sebuah keharusan. Permasalahannya sekarang, bagaimana anak-anak kita dapat mempelajari matematika dengan baik, kalau setiap kali berhadapan dengan matematika selalu merasa cemas dan ketakutan?
Membaca situasi demikian, dimana kecemasan anak terhadap matematika begitu besar, kiranya perlu untuk menghadirkan matematika yang lebih manusiawi. Sehingga kecemasan tersebut dapat dikurangi. Dan pada akhirnya nanti matematika kembali dipandang secara wajar, tidak dilihat sebagai “momok” yang menakutkan.
Beberapa pemikiran yang kiranya dapat disumbangkan untuk membantu mengurangi kecemasan anak terhadap matematika adalah: Pertama, bagaimana menumbuhkan kembali minat anak terhadap matematika. Ini dapat dilakukan apabila pelajaran matematika disajikan secara menarik. Selama ini matematika dianggap sebagai ilmu “kering” karena dalam pembelajarannya kurang menarik. Kurangnya inovasi dan kreatifitas guru dalam pembelajaran matematika menyebabkan anak bosan. Metode pembelajaran yang lebih variatif dan kaya, kiranya dapat membantu mengurangi kejenuhan anak dalam mempelajari matematika.
Kedua, perlunya guru untuk mengaitkan materi dengan peristiwa atau kejadian dalam kehidupan sehari-hari. Hal ini penting untuk menghindari pandangan bahwa matematika hanya melulu konsep/teori. Dengan menunjukkan keterkaitan matematika dengan realitas kehidupan, akan menjadikan pelajaran matematika bermakna bagi anak. Anak dapat menerapkan konsep/teori yang dipelajarinya untuk memecahkan persoalan riil yang dihadapi dalam keseharian. Dengan demikian anak melihat kegunaan matematika bagi kehidupan mereka.
Ketiga, perlunya menampilkan sisi lain matematika yang kurang dikenal anak dalam pembelajaran. Tuntutan dan beban kurikulum, seringkali mematikan kretifitas guru dan anak dalam pembelajaran matematika. Guru cenderung mengejar target penyelesaian materi, sehingga banyak sisi lain dari matematika yang tidak dihadirkan dalam pembelajaran. Akibatnya anak mengenal matematika tidak secara utuh. Matematika sebagai bagian integral dari kebudayaan manusia, mengandung dimensi kemanusiaan dan memiliki keindahannya tersendiri. Namun hal itu jarang sekali disentuh dalam pembelajaran matematika di sekolah. Sebagai contoh, sejarah matematika dengan segala pergulatan para tokohnya jarang dipelajari di sekolah. Padahal dari sini, anak bisa belajar membangun sikap dan minat yang positip terhadap matematika. Pengalaman penulis, di kelas matematika ternyata kami bisa tertawa bersama, ketika ada teman yang membacakan “puisi matematika”nya. Dari puisi yang ditulis dengan menggunakan istilah-istilah matematika ini, terlihat sejauh mana anak menguasai dan memahami konsep matematika. Dalam puisi tersebut konsep matematika berperan sebagai bahasa ungkap. Tanpa menguasai konsep matematika, anak akan kesulitan mengungkapkan idenya kedalam puisi matematika.
Keempat, perlunya keberpihakan guru kepada anak dalam pembelajaran matematika. Seringkali dalam pembelajaran terjadi dikotomi antara guru dan anak. Guru berperan sebagai subyek pembelajaran, sementara anak menjadi obyeknya. Dikotomi ini harus digeser, sehingga yang ada, baik guru maupun anak bersama-sama menjadi subyek pembelajaran. Guru dan anak bukanlah dua pihak yang saling berhadapan, karena jika demikian halnya akan terbentang jarak antara keduanya. Tetapi bagaimana guru dapat berperan sebagai teman yang berpihak pada anak, mau terbuka untuk mendengarkan, dan membantu setiap kesulitan yang dihadapi anak. Bukan berdiri sebagai pihak yang menghukum ketika anak dalam kesulitan. Kondisi demikian akan mendorong anak untuk terlibat aktif dalam proses pembelajaran, menggali secara lebih dalam potensi dan kemampuannya, serta dapat menumbuhkan sikap dan minat positip anak terhadap matematika.
Kelima, dibutuhkan peran serta aktif orangtua dalam membantu anak mengatasi kecemasannya terhadap matematika. Seringkali tanpa disadari tuntutan orang tua agar anak mendapatkan nilai yang baik, membuat anak merasa tertekan dan terbebani. Kadang orangtua tidak memahami kesulitan yang dihadapi anak. Sebaliknya orangtua malah memperparahnya dengan memarahi dan menyalahkan, akibatnya anak semakin frustasi dan semakin membenci matematika. Sebenarnya yang dibutuhkan anak dari orangtua adalah pengertian, keberpihakan dalam wujud dukungan, dan pendampingan. Orangtua dapat bekerjasama dengan guru di sekolah untuk mengetahui sejauh mana perkembangan anak, mendiskusikan kesulitan anak. Hal ini penting agar ada sinergi antara guru dan orangtua dalam pendampingan anak.
Akhirnya, anak hanya dapat berkembang secara optimal, dapat mengekspresikan dirinya dengan penuh kreatifitas, jika ia tidak menyimpan kecemasan. Sebab anak yang cemas berarti dia tidak bebas, dan ketika anak tidak bebas maka dia tidak bisa tumbuh dan berkembang secara optimal. Karena hanya orang bebaslah yang mampu mencipta, berkreasi dan mengembangkan dirinya secara optimal.@
HJ. Sriyanto
Guru Matematika di SMU Kolese Debritto
Jl. Laksda Adisucipto 161 Yogyakarta 55281
Ada beberapa hal yang kiranya dapat diajukan sebagai faktor penyebab timbulnya kecemasan anak terhadap matematika. Pertama, matematika sebagai salah satu bidang studi yang diajarkan di sekolah merupakan cabang ilmu yang spesifik. Berbeda dengan ilmu pengetahuan lain, matematika tidak mempelajari obyek-obyek yang secara langsung dapat ditangkap oleh indera manusia. Substansi matematika adalah benda-benda pikir yang bersifat abstrak. Walaupun pada awalnya matematika lahir dari hasil pengamatan empiris terhadap benda-benda konkret (geometri), namun dalam perkembangannya matematika lebih memasuki dunianya yang abstrak. Obyek matematika adalah fakta, konsep, operasi dan prinsip yang kesemuannya itu berperan dalam membentuk proses berpikir matematis, dengan salah satu cirinya adalah adanya alur penalaran yang logis. Sehingga apabila dibandingkan dengan bidang studi lain, matematika relatif dianggap lebih sulit, karena dibutuhkan konsistensi dalam mempelajarinya.
Kedua, persepsi yang berkembang dalam masyarakat bahwa matematika sulit, telah mengkooptasi pikiran sebagian anak. Sehingga anak akan beranggapan seperti demikian, ketika berhadapan dengan matematika. Pandangan bahwa matematika merupakan ilmu yang kering, abstrak, teoritis, banyak rumus yang sulit dan membingungkan, yang didasarkan atas pengalaman kurang menyenangkan ketika belajar matematika di sekolah, telah membangun persepsi negatif pada diri anak. Hal ini telah membangun jarak antara anak dengan matematika. Sehingga sebagai ilmu pengetahuan matematika tidak dipandang secara netral lagi.
Ketiga, pembelajaran matematika yang “kering”, monoton dan guru yang cenderung represif, membuat anak merasa tertekan. Anak cenderung menutup diri, kurang dapat bereksplorasi dan mengekspresikan dirinya dalam proses pembelajaran. Pembelajaran matematika pun akhirnya tidak menjadi media untuk melatih olah pikir, melainkan matematika dipahami dengan cara menghafal.
Keempat, tuntutan untuk mendapatkan nilai yang baik dalam pelajaran matematika dari orang tua dan juga guru, tanpa disadari telah membuat anak cenderung berorientasi pada hasil atau nilai yang tinggi dalam matematika, tetapi mengabaikan proses. Dan ketika anak mendapatkan hasil yang kurang memuaskan, mereka akan merasa tertekan dan menganggap dirinya bodoh. Meskipun nilai yang diperoleh baik, tapi pengetahuan yang dikuasainya sangat minim, karena secara konseptual memang sebenarnya anak tidak banyak paham.
Matematika memegang peranan yang cukup penting dalam kehidupan manusia. Sebenarnya hampir setiap hari manusia bersentuhan dengan matematika. Banyak yang telah disumbangkan matematika untuk kemajuan perababan manusia. Perkembangan teknologi dan juga ilmu pengetahuan lain, tidak lepas dari peranan matematika. Oleh karenanya mempelajari dan menguasai matematika dengan baik adalah sebuah keharusan. Permasalahannya sekarang, bagaimana anak-anak kita dapat mempelajari matematika dengan baik, kalau setiap kali berhadapan dengan matematika selalu merasa cemas dan ketakutan?
Membaca situasi demikian, dimana kecemasan anak terhadap matematika begitu besar, kiranya perlu untuk menghadirkan matematika yang lebih manusiawi. Sehingga kecemasan tersebut dapat dikurangi. Dan pada akhirnya nanti matematika kembali dipandang secara wajar, tidak dilihat sebagai “momok” yang menakutkan.
Beberapa pemikiran yang kiranya dapat disumbangkan untuk membantu mengurangi kecemasan anak terhadap matematika adalah: Pertama, bagaimana menumbuhkan kembali minat anak terhadap matematika. Ini dapat dilakukan apabila pelajaran matematika disajikan secara menarik. Selama ini matematika dianggap sebagai ilmu “kering” karena dalam pembelajarannya kurang menarik. Kurangnya inovasi dan kreatifitas guru dalam pembelajaran matematika menyebabkan anak bosan. Metode pembelajaran yang lebih variatif dan kaya, kiranya dapat membantu mengurangi kejenuhan anak dalam mempelajari matematika.
Kedua, perlunya guru untuk mengaitkan materi dengan peristiwa atau kejadian dalam kehidupan sehari-hari. Hal ini penting untuk menghindari pandangan bahwa matematika hanya melulu konsep/teori. Dengan menunjukkan keterkaitan matematika dengan realitas kehidupan, akan menjadikan pelajaran matematika bermakna bagi anak. Anak dapat menerapkan konsep/teori yang dipelajarinya untuk memecahkan persoalan riil yang dihadapi dalam keseharian. Dengan demikian anak melihat kegunaan matematika bagi kehidupan mereka.
Ketiga, perlunya menampilkan sisi lain matematika yang kurang dikenal anak dalam pembelajaran. Tuntutan dan beban kurikulum, seringkali mematikan kretifitas guru dan anak dalam pembelajaran matematika. Guru cenderung mengejar target penyelesaian materi, sehingga banyak sisi lain dari matematika yang tidak dihadirkan dalam pembelajaran. Akibatnya anak mengenal matematika tidak secara utuh. Matematika sebagai bagian integral dari kebudayaan manusia, mengandung dimensi kemanusiaan dan memiliki keindahannya tersendiri. Namun hal itu jarang sekali disentuh dalam pembelajaran matematika di sekolah. Sebagai contoh, sejarah matematika dengan segala pergulatan para tokohnya jarang dipelajari di sekolah. Padahal dari sini, anak bisa belajar membangun sikap dan minat yang positip terhadap matematika. Pengalaman penulis, di kelas matematika ternyata kami bisa tertawa bersama, ketika ada teman yang membacakan “puisi matematika”nya. Dari puisi yang ditulis dengan menggunakan istilah-istilah matematika ini, terlihat sejauh mana anak menguasai dan memahami konsep matematika. Dalam puisi tersebut konsep matematika berperan sebagai bahasa ungkap. Tanpa menguasai konsep matematika, anak akan kesulitan mengungkapkan idenya kedalam puisi matematika.
Keempat, perlunya keberpihakan guru kepada anak dalam pembelajaran matematika. Seringkali dalam pembelajaran terjadi dikotomi antara guru dan anak. Guru berperan sebagai subyek pembelajaran, sementara anak menjadi obyeknya. Dikotomi ini harus digeser, sehingga yang ada, baik guru maupun anak bersama-sama menjadi subyek pembelajaran. Guru dan anak bukanlah dua pihak yang saling berhadapan, karena jika demikian halnya akan terbentang jarak antara keduanya. Tetapi bagaimana guru dapat berperan sebagai teman yang berpihak pada anak, mau terbuka untuk mendengarkan, dan membantu setiap kesulitan yang dihadapi anak. Bukan berdiri sebagai pihak yang menghukum ketika anak dalam kesulitan. Kondisi demikian akan mendorong anak untuk terlibat aktif dalam proses pembelajaran, menggali secara lebih dalam potensi dan kemampuannya, serta dapat menumbuhkan sikap dan minat positip anak terhadap matematika.
Kelima, dibutuhkan peran serta aktif orangtua dalam membantu anak mengatasi kecemasannya terhadap matematika. Seringkali tanpa disadari tuntutan orang tua agar anak mendapatkan nilai yang baik, membuat anak merasa tertekan dan terbebani. Kadang orangtua tidak memahami kesulitan yang dihadapi anak. Sebaliknya orangtua malah memperparahnya dengan memarahi dan menyalahkan, akibatnya anak semakin frustasi dan semakin membenci matematika. Sebenarnya yang dibutuhkan anak dari orangtua adalah pengertian, keberpihakan dalam wujud dukungan, dan pendampingan. Orangtua dapat bekerjasama dengan guru di sekolah untuk mengetahui sejauh mana perkembangan anak, mendiskusikan kesulitan anak. Hal ini penting agar ada sinergi antara guru dan orangtua dalam pendampingan anak.
Akhirnya, anak hanya dapat berkembang secara optimal, dapat mengekspresikan dirinya dengan penuh kreatifitas, jika ia tidak menyimpan kecemasan. Sebab anak yang cemas berarti dia tidak bebas, dan ketika anak tidak bebas maka dia tidak bisa tumbuh dan berkembang secara optimal. Karena hanya orang bebaslah yang mampu mencipta, berkreasi dan mengembangkan dirinya secara optimal.@
HJ. Sriyanto
Guru Matematika di SMU Kolese Debritto
Jl. Laksda Adisucipto 161 Yogyakarta 55281
Selasa, 05 Agustus 2008
Akreditasi
Sepertinya sudah hampir lebih dari dua minggu sejak postingan saya yang terakhir, akhirnya saya mencoba menyempatkan kembali mengisi postingan di blog ini. Ada pekerjaan yang cukup menyita waktu sehingga saya sulit untuk melakukan posting di blog ini. Yup, akreditasi sebuah siklus 4 tahunan itu akhirnya kembali menyambangi sekolah tempat saya bertugas. Kegiatan ini cukup banyak menyita waktu,
Senin, 04 Agustus 2008
Bermain Sulap Dengan Matematika
Bermain Sulap dengan Matematika
Bermain merupakan hal yang menyenangkan karena bisa menghilangkan kejenuhan sehingga bisa lebih rileks dan santai. Tetapi bermain dengan matematika? Gak mungkin! Matematika itu serius butuh berpikir keras. Jangan salah, matematika bisa juga membuat kita fun lho. Lewat permainan angka yang diulas dalam buku ini, seperti menebak umur, tanggal ulang tahun, menguji cinta pacar, mendeteksi kebohongan, strategi selingkuh aman, bahkan sampai pada permainan yang bermanfaat seperti menghemat pulsa, uang belanja, dan mengatur uang saku bulanan. Buku ini mampu meyakinkan bahwa matematika sangat berguna untuk kehidupan kita sehari-hari. Asyik, bukan? Buku ini membuktikan bahwa matematika tidak melulu bergulat dengan rumus, soal, dan teori, tetapi bisa dikaitkan dengan kehidupan keseharian kita kemudian dijadikan permainan yang menarik. Dijamin akan asyik bermain dengan angka. Laksana sulap, angka-angka yang rumit bisa kita bim-sala-bim menjadi mudah! Abra-kada-bra, wow, menyenangkan...
Bermain merupakan hal yang menyenangkan karena bisa menghilangkan kejenuhan sehingga bisa lebih rileks dan santai. Tetapi bermain dengan matematika? Gak mungkin! Matematika itu serius butuh berpikir keras. Jangan salah, matematika bisa juga membuat kita fun lho. Lewat permainan angka yang diulas dalam buku ini, seperti menebak umur, tanggal ulang tahun, menguji cinta pacar, mendeteksi kebohongan, strategi selingkuh aman, bahkan sampai pada permainan yang bermanfaat seperti menghemat pulsa, uang belanja, dan mengatur uang saku bulanan. Buku ini mampu meyakinkan bahwa matematika sangat berguna untuk kehidupan kita sehari-hari. Asyik, bukan? Buku ini membuktikan bahwa matematika tidak melulu bergulat dengan rumus, soal, dan teori, tetapi bisa dikaitkan dengan kehidupan keseharian kita kemudian dijadikan permainan yang menarik. Dijamin akan asyik bermain dengan angka. Laksana sulap, angka-angka yang rumit bisa kita bim-sala-bim menjadi mudah! Abra-kada-bra, wow, menyenangkan...
Jurus Sukses Mengerjakan Soal-soal Ujian Nasional Matematika SMA
Penulis: M. Sri Mihardja
Ukuran: 21 x 29 cm
Tebal: viii + 196 hlm
ISBN: 979-775-042-6
Harga: Rp 36.000
Buku ini menyajikan kumpulan soal ujian nasional matematika dari tahun ke tahun dengan pembahasannya, dan disertai dengan prediksi soal ujian nasional beserta pembahasannya.
Pembahasan atau penyelesaian tiap soal ujian disajikan dengan alur yang sederhana, sehingga siswa diharapkan mampu mengerjakan soal-soal dengan mudah dan cepat.
Penulis: M. Sri Mihardja
Ukuran: 21 x 29 cm
Tebal: viii + 196 hlm
ISBN: 979-775-042-6
Harga: Rp 36.000
Buku ini menyajikan kumpulan soal ujian nasional matematika dari tahun ke tahun dengan pembahasannya, dan disertai dengan prediksi soal ujian nasional beserta pembahasannya.
Pembahasan atau penyelesaian tiap soal ujian disajikan dengan alur yang sederhana, sehingga siswa diharapkan mampu mengerjakan soal-soal dengan mudah dan cepat.
Langkah Jitu Menghadapi Ujian Nasional SMP
Penulis : HJ Sriyanto, Silvester Goridus Sukur, dan Gunawan Sudarsana
Ukuran : 21 x 29 cm
Tebal : 196 hal
ISBN : 979-775-012-4
Harga : Rp. 49.000.-
Buku ini berisi kumpulan soal Ujian Nasional tahun-tahun sebelumnya yang dilengkapi pembahasan yang komprehensif dan mudah dicerna oleh siswa. Jawaban yang diberikan tidak sekadar kunci jawaban, tetapi lebih kepada mengapa jawabannya seperti itu. Selain itu, buku ini juga dilengkapi dengan prediksi soal Ujian Nasional, sehingga dengan berlatih banyak dengan buku ini, peluang emas untuk melewati Ujian Nasional secara cemerlang semakin luas.
Penulis : HJ Sriyanto, Silvester Goridus Sukur, dan Gunawan Sudarsana
Ukuran : 21 x 29 cm
Tebal : 196 hal
ISBN : 979-775-012-4
Harga : Rp. 49.000.-
Buku ini berisi kumpulan soal Ujian Nasional tahun-tahun sebelumnya yang dilengkapi pembahasan yang komprehensif dan mudah dicerna oleh siswa. Jawaban yang diberikan tidak sekadar kunci jawaban, tetapi lebih kepada mengapa jawabannya seperti itu. Selain itu, buku ini juga dilengkapi dengan prediksi soal Ujian Nasional, sehingga dengan berlatih banyak dengan buku ini, peluang emas untuk melewati Ujian Nasional secara cemerlang semakin luas.
Quick Math
Penulis: Hj. Sriyanto
Ukuran: 15 x 23 cm
Tebal: x + 311 hlm
ISBN: 979-775-040-X
Harga: Rp 30.000,-
Buku ini sangat membantu siswa dalam belajar matematika terutama untuk persiapan menghadapi UN dan SPMB. dalam ujian, mengerjakan soal dengan cepat menjadi tuntutan yang tak terhindarkan. Setiap peserta harus memperhitungkan waktu yang tersedia dan jumlah soal ujian yang harus dikerjakan.
Buku ini menyajikan ringkasan materi singkat dan kumpulan rumus-rumus cepat matematika SMA. Setiap materi selalu dimulai dengan konsep dasar, dilanjutkan dengan rumus-rumus pokok, contoh soal, pembahasan, dan jika memungkinkan ditutup dengan trik penyelesaian cepatnya. Materi yang disajikan merupakan ringkasan dari pelajaran matematika SMA. Alur yang digunakan juga cukup sederhana sehingga mudah dipahami. Hal ini akan sangat membantu siswa mempelajari matematika secara cepat tetapi tetap komprehensif.
Ukuran: 15 x 23 cm
Tebal: x + 311 hlm
ISBN: 979-775-040-X
Harga: Rp 30.000,-
Buku ini sangat membantu siswa dalam belajar matematika terutama untuk persiapan menghadapi UN dan SPMB. dalam ujian, mengerjakan soal dengan cepat menjadi tuntutan yang tak terhindarkan. Setiap peserta harus memperhitungkan waktu yang tersedia dan jumlah soal ujian yang harus dikerjakan.
Buku ini menyajikan ringkasan materi singkat dan kumpulan rumus-rumus cepat matematika SMA. Setiap materi selalu dimulai dengan konsep dasar, dilanjutkan dengan rumus-rumus pokok, contoh soal, pembahasan, dan jika memungkinkan ditutup dengan trik penyelesaian cepatnya. Materi yang disajikan merupakan ringkasan dari pelajaran matematika SMA. Alur yang digunakan juga cukup sederhana sehingga mudah dipahami. Hal ini akan sangat membantu siswa mempelajari matematika secara cepat tetapi tetap komprehensif.
Strategi Sukses Menguasai Matematika
Strategi Sukses Menguasai Matematika
[243-07-22123]
Oleh: HJ Sriyanto
Rp.25.000
ISBN : 9789792399707
Rilis : 2007
Halaman : 120
Penerbit : Galang Press
Bahasa : Indonesia
Bagi sebagian besar siswa, matematika adalah momok yang menakutkan. Seperti kiamat saja matematika di mata mereka. Keringat dingin mengucur deras ketika aneka rumus hitung-hitungan membuncah di meja ujian.
Ubah cara pandang! Matematika itu tidak sulit. Matematika itu gampang.
Ada caranya menjadikan matematika semenyenangkan menyanyi. Caranya? Simak baik-baik panduan sukses dalam buku ini. Ada strategi mengatur metode belajar, mengenali berbagai tipe soal, hingga kiat memberesi soal-soal tes.
Buku ini tepat dijadikan panduan berlatih membuat rumus, menggarap soal-soal, hingga menyelesaikan aneka tes matematika. Siapapun Anda pantas merujuk buku ini.
Happy With Math
Happy With Math
[243-07-22122]
Oleh: HJ Sriyanto
Rp.22.500
ISBN : 9789792399806
Rilis : 2007
Halaman : 99p
Penerbit : Galang Press
Bahasa : Indonesia
Matematika yang kita kenal adalah ilmu yang penuh rumus, teoritis, dan njelimet. Padahal sebenarnya banyak sisi lain yang menarik untuk kita ketahui. Sisi lain itu bisa membuat kita berdecak kagum dan mengubah cara pandang kita terhadap matematika yang selama ini dianggap menakutkan.
Hanya sayang, selama ini kita belum mengenalnya karena tidak dihadirkan saat kita belajar matematika di sekolah.
Buku ini dengan jelas mengungkapkan sisi menarik tersebut. Ada bilangan ajaib yang kadang terasa tidak masuk akal tetapi memudahkan kita. Ada juga cerita-cerita konyol yang mengantar para ilmuwan matematika pada penemuan konsep matematika yang baru. Serta pengalaman unik para peserta olimpiade dalam menyenangi matematika..
Kesemua ini akan membantu kita mengubah cara pandang dari matematika yang menjengkelkan menjadi sesuatu yang patut disenangi. Selamat membuktikan!
Sabtu, 02 Agustus 2008
Enhance Arithmetic Skills
In mathematics, improving arithmetic skills an essential step right from the beginning. I found , Reken test , a freeware , easily downloadable ,an arithmetic testing and practicing tool. This one is so cool, that students under age group 8-12 would surely love to practice and play using it. You may download it from here.
Try it!
Langganan:
Postingan (Atom)