Archive for April 2007
- Log shift activities
- Log in and out times
- Generate XYZ Report
- Export Data to Excel
- View Data in a Range
The above pieces represent the nature of a few types of functionality that are often found on projects. One of the practices I that I follow and recommend to others is of course to determine the business value of each of the features desired. For different businesses the value of each of the above features will be different. The other practice is to seperate the features into engine and bells & whistles after you have determined their business value. So, in the above example Export Data to Excel or View Data in a Range can be a bells & whistles feature if it has very little business value. It is a feature that most likely got added because all the other applications in the industry may have those.
This often gets skipped, but is very helpful for many reasons. Some of them are:
- More experienced people can be handed the responsibility of the engine components.
- Bells & Whistles can always be used as filler features when engine feature(s) planned for an iteration of development are over.
- These are often good pieces that can be used to get new team members upto speed on code. Let's not forget that bells & whistles can be very complicated features to implement sometimes.
There, probably, aren't any rules of thumb by which a feature can be classified as bells & whistle. However, there are certain hints that can be used to figure it out. If the business value is very little compared to some of the other features and/or if the feature being asked for has its inspiration from a lot of commercially available applications, there are high chances that it may qualify as bells & whistles.
- Structured - These are generally yes/no, fill in the blanks and data collection kind of questions. The nature of these questions make the interview process seem like an interrogation rather than a knowledge sharing session. Problem almost never come out using this format.
- SemiStructured - Problem come out, which don't in a structured interviews. It is a very efficient two way communication process.
- Unstructured - Without guideposts the chances of straying are very high. Also, it is very important for the interviewee or the respondent to be able to sense the direction you are going in to frame their answers correctly. Unstructured interviews don't have that benefit.
- Availability of users/interviewees.
- Subject Matter Expertise.
- What do you aim to understand - process or problem
- Incomplete understanding of the process/problem, and/or
- I don't know, or I am not sure.
- I can't make that decision.