TL;DR
- Before making solution define a goal - what are you solving
- Make sure it's your true goal, not something that will help to achieve it
- When you're thinking of solution, regularly stop and remember the goal - are you still focused on the primary problem?
FULL VERSION
More and more I see the application of basics of
KAOS methodology in a professional environment.
What are the common issues I encounter:
- Focus on detail loses touch with the initial problem, a lot of time is spend on side issues.
- Proposed solutions are implemented without verifying them first, resulting in wasted time and energy with no effective result.
- Improper problems are being solved. Good ideas, good solution, but have nothing to do with the problem, that was the cause of it all.
How it should be done? Let's apply the basics of KAOS for this:
- Define the top goal(s) you want to achieve
- Go down and define sub-goals, that are required in order to achieve the higher goals
- Review and refine the goal graph
- Make a solution, that achieves the lowest level goals
OK, lets go deeper into each item and see what it means. Most of what's below is a theoretical stuff, in reality you usually apply a simplified variant of it.
Define the top goal(s) you want to achieve
Although it sound simple and clear, in practice it's often forgotten. Often in meetings people discuss suggestions on how to solve teams/company's problems, but so often these discussions can be brought to a halt with a simple questions like "What we are trying to achieve?" and "Is that really the real problem?". The main point here is to find a clear and simple goal we want to achieve or contribute to. In a later case the bigger issue is to know full background, to see "the big picture". The company's goal usually is profit, a team may want to be valued and recognized. Things like making good product and doing it in time are usually the sub-goals. In case of Free Software project, the goal perhaps is the product. The point is:
top goals should be all that matter, anything else should contribute to them.
Go down and define sub-goals, that are required in order to achieve the higher goals
When you know, what your goals are, you can think on how to achieve them. Typically there are few sub-goals that either should all be achieved (and condition) or any of them is sufficient to achieve main goal (or condition). A problem I often observe is that
focus on detail loses touch with the initial problem. Most discussions happen in this area and it's very easy to shift centre of attention to a side, when no clear top goal is defined. Any sub-goal must directly of indirectly contribute to the at least one top goal. If not and it's clear the sub-goal is valid - you know your top goals are not defined properly. In general during discussions always question everything "will this help us achieve what we want?". This can help you avoid the other frequent mistake -
solving the wrong problem. Sounds silly, but when you lose your main goal on the way, you often waste most of your time on something else later.
Review and refine the goal graph
It's best to graphically draw all the goals, you get what's called a goal graph. Before trying to solve it, review it! Is it correct? As I mentioned, often
proposed solutions are implemented without verifying them first. This review is to make sure that you know and understand what you're trying to solve.
Make a solution, that achieves the lowest level goals
When you have a graph, you can make a solution. The graph gives you the requirements - solve the required leaves and you're supposed to solve your initial problems. If you can't - go back to reviewing and refining graph.
Bottom line
This a very brief intro into KAOS, but since it's not requirement engineering, but more a daily life, that should be enough. If taken more seriously, you'll need deeper knowledge and tools.
Dia has support for KAOS.
