Customer Happiness
Opened this issue · 9 comments
We were discussing about the manifesto at Vizir, and we noticed that the customer happiness is missing in the happiness manifesto.
For us the developer and the customer happiness are very coupled. As developer we always must to try deliver happiness for our customers/users, because without customers/users we don't have applications to develop.
I know this objective is very difficult, because sometimes the customer happiness and the developer happiness goes in opposite ways. But this is the challenge: improve our relationship with the customer, to the customer understand that we will need more time to delivery a better and more maintainable application, and the team understand that feature discovered one week before the end of the project, is really important, so you must implemented it.
What do you think about it?
I've discussed this a bit with a few people, specifically when it came to end-user satisfaction. This is more geared towards the development community, with applications on individual development teams. I wasn't thinking about in reference to a consulting project or relationships outside of the development community.
Customer + User happiness is obviously important to the success of any project, I'm just not sure it's necessarily applicable here-I'm having trouble framing this as a value of the development community.
"We value delighting those who use the product of our work over ________", I'm not sure what we're choosing over delighting the user... any ideas?
@scottefein My worry is, the customer + user happiness not so obviously for some developers. Because in many projects I saw a warfare between the developers and users/customers.
Some ideas for a complement to the value: "[...] over just follow the plan without a better collaboration with users and customers."
One suggestion": "We value constant collaboration with customers and users over have fear to talk with customers and users." (this is very similar with "Customer collaboration over contract negotiation" from Agile Manifesto - but the idea is be more close to the developer context)
"We value user happiness over developer happiness". I know it sounds too strong, but at the end of the day it should be the mantra for every developers.
Ex:
complicated code to keep compatibility AND user could update to a new version without any problem
-vs.-
refactored and lean code BUT user spent two days changing her code after hours searching for the problem on stackoverflow
simple, straightforward solutions and not so elegant AND user got right time to market
-vs.-
sophisticated solution BUT delivered too late
"That is, while there is value in the items in the bottom, we value the items on the top more."
Without the user being mentioned the happiness manifesto is just a hedonistic list and lose the whole thing about being a programmer.
To be happy is to delivery happiness.
User Happiness > Developer Happiness gets recursive ;)
I think the Agile Manifesto covers the Developer/Customer relationship, and given that we already value Agile-I'm not convinced this has a place here. While I agree that strong customer/user research and interaction is important, this kind of stuff is indigenous to Lean + Agile. I'm concerned about expanding the scope of this, it's a compliment not a replacement to Agile. This is suppose to address development practices and developer community beyond what's already in Agile.
I like the idea of delighting users based on what we as developers produce-which I still think satisfies the developer end of this conversation. Maybe something like this...
"We value delighting those who use the product of our work over building what is easy or comfortable"
"We value delighting those who use the product of our work over building what is easy or comfortable" is a very good start.
Just to put it out there, there are somewhat revolutionary ideas like valuing employees before customers.
Gary Hamel: Reinventing the Technology of Human Accomplishment (video, 16m)
I highly recommend watching that video, but if you don't have time, the gist is:
If you put your employees first (developers in this case) they will do the right thing for your customers.
Say instead, you push your team to deliver a feature by a hard deadline. Your customers are happy, until they find out it's buggy and changes always take forever - the developers say the code is hard to maintain.
Agree or disagree?
@nathany communication is the problem in this hard deadline scenario. The customer should be alerted about the deadline is a hard one, so you open a negotiation to increase the deadline, and if it's not possible you share the future problems that this hard deadline will drive.
Customer Happiness > Developer Happiness or vice-versa is not the main point. The main point for me is the alignment between customers and developers. Both must try to cultivate an open communication during the project, sharing their needs and fears.
In industry I already saw many guys saying: "Ok, my team will delivery this feature! (even if the deadline is impossible to achieve without compromise the product quality and/or the developers weekend). And others saying: "Impossible, we will not delivery this feature!".
Neither position is the right one. Transparency is fundamental for happiness.
P.S.: thanks for sharing this awesome video from Gary Hamel!
I whole heartedly agree. Emphasize transparency and honest communication.
My work is quite different than yours. I work on a SaaS product for small businesses. We tend not to have external deadlines because of this.
But customer communication is still super important. People want to know what we're working on.