James Governor of Redmonk shared a great tweet today (he is @monkchips)
@dhague: 6 degrees of separation between developers and end-users is 3 too many. It’s hard to keep users happy with that disconnect
Now here’s one way to think about the degrees of separation between your users and your developers:
- Users tell an analyst what they want
- The analyst writes a requirement document or a high-level specification
- A technical design gets developed
- Code gets written to implement this design
- Testing finds flaws and issues and these get resolved
- The user gets to try and use the resulting application
Well look at that – 6 degrees of separation 🙂
If instead the users sit down with the analysts to write the rules that are needed and the developers enhance those rules with the technical details or to take account of implementation issues before reviewing those same rules with the users and the analysts. And if the resulting rules, still readable and even editable by the users and the analysts, can be tested and simulated by programmers, anlaysts and users then suddenly the degrees of separation goes WAY down.
Using business rules to manage the logic in critical decisions – the parts of your applications where business know-how and an understanding of company policy and government regulation are most critical and where constant change is the norm – eliminates these degrees of separation. Result, more agile and more accurate business logic where you really need it.
All this talk of twitter reminds me that you can follow me on twitter – jamet123
Comments on this entry are closed.
I agree with James, but I’d to a step further. First of all, I like to put things in the context of a Method. This may seem like fluff, but it really put’s things in perspective. There are lots of ways to structure a Method for implementing a solution of some sort…I use Discovery, Analysis, Design, Build, Test and Transition.
Now I can show the user how and when they can be involved. Clearly, the Discovery and Analysis phase is where stuff is described in business terms. So the test here is to ensure the user still understands what you plan on doing when you complete the Analysis.
Then while you get busy with the Design and test you can ask the user to put a number of Use Cases together which you’d then revise with them as you complete the Design Phase. And again, revise as you complete the Build so you can account for those Use Cases which were not planned for.
Then you can get them busy in the planning for testing, training and transition. How will they transition to production? A small group at a time or everyone at once.
So all in all, there are so many ways to keep the user involved and bought into the solution you’re building. It’s a hell of a lot better than throwing it over the fence and saying, “here you go….good luck”.