One of the last chapters of The Pragmatic Programmer: From Journeyman to Master book that I finished reading today is titled "Great Expectations".
This chapter talks about communicating expectations to the users and suggests to gently exceed users' expectations in order to keep them happy using your software.
I must say that I agree with this book in many points except "The Extra Mile":
If you work closely with your users, sharing their expectations and communicating what you're doing, then there will be few surprises when the project gets delivered.
This is a BAD THING. Try to surprise your users. Not scare them, mind you, but delight them.
Did I miss something here? I understand that a good surprise may pay off, but who knows? It may not be so good after all. Only customers will tell if the "surprise feature" is good.
Maybe I'm too pragmatic (more pragmatic than the pragmatic programmer), but I would feel better to have a happy customer with less surprises. However, the marketing guys may have a different opinion...
What is your opinion? Do you give your users little surprises to delight them? If so, I'd like to hear from you.
3 comments:
I think the only good surprises you can leave for your customer are back end surprises. You know, the types of features that are helpful when the user calls up and says "I think I just deleted the entire database." In situations like that it's good to pull out the 'surprise' back end maintenance features (logging, backups, etc.) that your customer probably never paid any attention to in the first place if they were part of the original spec. In terms of front end surprises I'd say that was a big faux pas that can easily be interpreted by the client as deviating from the spec. Including extra features that you assumed would be nice might not be interpreted in the same way by the client. Any sort of visible 'feature' that wasn't discussed beforehand isn't going to earn any points. However, if there was a feature that the client said they wanted that you initially nixed that gets included in the final product then that's ok. I'd throw documentation and help features in this category too. No client is ever going to complain if you deliver extra documentation with the project. Under promise and over deliver will always go over well with a client.
A suprise can be a good thing, but you have to know your customer. The more detail oriented a customer the less suprise you want to give them. If they are more generic, your suprise mightly simply be something they expected you to do in the first place.
Going the extra mile isn't about shocking your customer. It's about quality. Customers tend to get what they pay for if they pay very little, most devs will not put in those extra miles, pay more and most will because the better devs simply can stand putting out subpar quality code suprise or not.
You can surprise them by completing a feature that they request, but you weren't sure you'd have enough time to add.
Telling users that you might be able to get that last feature in would raise their expectations and disappoint them if you failed. On the other hand, telling them that you most likely won't have time for these "n" features, and then getting a few of them done anyway. That is the surprise you should make.
Also, depending on your customer base, personalized easter eggs might be a nice touch. I had one user jokingly ask if our tool could give her kittens. I added a little image of a kitten to the tool when she specifically logged in.
Post a Comment