"Customer need this". "Customer don't like this". "I can't explain this to Customer". "Customer is always right". "Customer f..d me whole day because you guys have no QA!!!". "Customer will send a killer to us". "Customer will hunt for our asses"... Familiar expressions, isn't it?
This post will try to explain magic around life-time conflict between Development Team and Customer. And also I'll try to find some silver bullets, as usual...
Conflict
Generic Vector of interests of Customer and vector of interests of Development Team are different.
Customer wants to have EVERYTHING by $0 cost. This quite generic and logical position. This is just direction of his vector of interests.
Development Team wants to do NOTHING for stable salary. Again this is just generic direction of vector of interests.
Common Interests
There is some good news. In real world those vectors are not quite orthogonal. Customer know that for $0 cost he can't expect some meaning results. And also Team knows that if they will have no projects they will have no salary. So our parties are close to create some symbiotic system.
Vectors of interests even can be the same. For example when developers launched some self-driven project. This is main moving force of Open Source projects. So when Team becomes Customer we have dramatic jump in project's effectiveness.
Building of symbiotic system - I. Information Channel
So.. Looks like both Customer and Team are in Strategic Agreement now. And Common Happiness is here. But.. We have a tactical problem. How we can transform Vision of the project form Customer's head to Developer's heads?
This is question of Information Channel.
There are 3 modes for this channel organisation.
Mode 1. Child and Clown.
In this mode Customer knowingly delegate responsibility on making decisions to Team. Actually no Information Channel created in this approach.
Customer says that he don't want to be involved in day-to-day process of development. He just share some basic desires at start of the project and
waiting for integrated solution from Development Team.
There is one danger. Often at the end of the project Customer says: "This is not result I was waiting for". This is forbidden trick from his side inside this mode. Unfortunately often top management of the development company tries to "resolve" this request under slogan "Customer is already right". This is bad approach which leads to life-time no-ending state of the project.
There is only one solution for both Customer and Team on my point of view in this mode: Customer has to subscribe some contract on this topic at the beginning of the project. And all solutions made by Team becomes legitimate.
In conclusion, Child and Clown mode is rather invalid state then robust approach and many projects failed with help of it.
Mode 2. Delegation.
In this mode Customer delegates responsibility on making decisions to third party. Third party is Company or Person who will substitute Customer in talks with development Team.
This mode is very close to "Full Contact" mode which we'll discuss now.
Mode 3. Deep inside.
So. This is most effective mode for general project success.
At early start, Customer gets serious obligations on himself. Now he acts as member of Development Team. He even can have some assigned tickets in Development Issue Tracker.
Main his responsibility is quick answering all questions received from Team. This can be functionality questions, like how many administrators will be involved in BackOffice actions? Or.. Please draw mockup of Order Page. And Customer has to do it! Using LovelyCharts.com, MS Paint or just pen and scanner.
Very important that for common success of project Customer has to be dominant source of information and decisions. Developers don't have to
guess what Customer need. They don't need to send many mockups as proposal for Customer and wait for short answers "yes" or "no". Customer has to be very resourcing. He has to draw what he wants. He has to be main contributor in project's logic and UI.
Sometimes it's convenient to allocate some person with perfect communication skills inside Development Team who will act as main Medium between Customer and Team. I prefer to call this person Product Owner. This term is actively used in Scrum.
It's very useful to have weekly meeting via Skype calls or chats between Product Owner and Customer. This will allow transfer not only direct answers but also some background around them.
In some cases Product Owner has to get part of Vision and decision making on himself if Customer can't figure final solution.
Product owner is 3rd force in development process. While other 2 forces - developers and QA engineers fight for code writing and search of problems in the code, Product Owner is voice of the Customer in this process.
In many cases even the fact of talking with Customer about some existing technical problem can change position of Customer concerning this point.
Any way it's much better then just say "it was impossible to do" during acceptance of Production system.
Building of symbiotic system - II. Bug or Feature
Often due difference in their generic vectors of interests Customer and Development Team started long discussion on standard theme: "bug or feature".
Reason why this is so conflict theme is clear: if this is bug then Team has to fix it by $0 cost. If this is out-of-scope feature then Customer has to pay for its implementation.
I can propose two simple approaches how to resolve this Holy War.
a. Compare this issue with existing Test Cases. Test Cases should be in-sync with Informational Channel between Customer and Team. So Test Cases is good common point.
b. Use approach: bug is not working functionality; feature is better functionality. So if existing functionality works fine than request to enhance this functionality is Feature.
Popular myths - I: Agile process will resolve all problems
It was real story. Our top manager during meeting with prospective customer said: we'll do this project using Agile process. So, you don't need to worry about spending significant time on descriptions. Customer signed contract and started wait for Miracle.
Miracle was not happen.
Agile process can't substitute Information Channel between Customer and Team. This process was designed for another purpose: transition of Vision and decision distributed over process life time. Often you can hear that Agile can support changing business requirements. It's the same. Agile is more smart in comparison with Waterfall in organisation of Information Channel. But Agile process is not a substitution of Information Channel at all.
Popular myths - II: Waterfall will save our asses
Another real story. After "problem with Agile process" our old friend, top manager on meeting with another prospective client said that Agile process is very problematic. "We'll back to well working Waterfall" - he said. "Oh, it's cool" - Customer said and signed the contract.
Then our friend called developers and said "Listen guys, I don't want to hear nothing about Agile process. We have new prominent project which we'll be conduct with Waterfall. So, sit and write 40 pages specification to the project. Now".
Please pay attention that no Information Channel was created. Again, developers pushed their Vision and their decisions into the project.
Can you guess what reaction Customer had on presentation of this Great WaterFall Project? Just try to guess.. Right! "This is not I was waiting for"!
Popular myths - III: QA is responsible for all problems
Another case. Again without Informational Channel between Customer and Team. Project was not accepted by Customer.
As result Top Management of our company started Great Patriotic War "Against whose f..d lazy QA who passed so many bugs that Customer was shocked".
In this case we have another substitution of reality by myth: after looking on Production system Customer started generation of dozens of requests to fit his estimations.
So in this case Customer created Informational channel by his initiative but just after development of the project was finished.
Top management recognized this stream of information as cloud of bugs passed by QA engineers.
The war was loosed.
Conclusion
I just want to write some compressed recommendations.
1. Always create Informational Channel between Customer (or his delegate) and Team acting during whole project life cycle. Otherwise ask Customer to sign some papers about delegation of decision rights to Development Team without further pretensions from his side.
2. Allocate Product Owner and set-up regular weekly calls or chats.
3. Support actuality of Test Cases as common point for any discussions with Customer.
