Hi folk / Robert
On the small point of our general individual, “…fault as an engineer
[to] prematurely jumping to nuts-and-bolts” (when I am wear my s/w
engineer’s hat) – There are some pedagogical processes that can be
developed for these areas (wearing me adult training cap).
In the specific get me started in a new technically biased (as in lots
technology) topic area, you begin with easily FAMILIAR subject matter
analyse what’s called the “training gap”.
Software engineers can see this as a user analysis in preparation for
enumerating use cases.
Take a familar - To The User - Scenario and analyse what that person may
possibly know. Everything, assume nothing.
I believe the most efficient way to accomplish that task is to begin by
developing user profiles of that context and knowledge (assumed
of each “user class”.
The reason it works is because each role or user class’ needs and
is written out and accounted for, they can be tracked. When a tutorial
training section is ready. I can actually ask, “Did I get told in
order?” == Logical order, meaning each topic is presented one idea at a
time, and no new topic/idea is presented before the prerequisites are
While we may not need such detail, after all everyone knows what a
is for don’t they? (Well actually no. They might know what the name
means.) It is like riding a bicycle – Knowing the word and the
then same as riding it and “knowing it”. grin
Profile helps others too – at some point we’ll want some marketing.
Profiles are the start of target market segmentation. It also helps
internals and addon developers understand user requirements and design
paramerters for fixed and on-going change and development (see:
Myopia”, Levitte, 1960, Harvard Business Review).
You will find that different inductions will be needed to begin
tutorials different user classes.
Give it a thought. I believe a user profile main wiki page where people
develop and refind each user class would be a great beginning.
Our general individual “…fault as an engineer …[to] prematurely
to nuts-and-bolts” becomes the advantage of engineering when we jump on
“appropriate” productive “nuts-and-bolts” issues. Here, I’m suggesting
profiles for the new users are very useful!
On 04/11/2007, Robert M. [email protected] wrote:
I would first ask what is it we want to produce. In other words:
- What topics need to be covered
- A list of use cases and the format that serves each
#1 would require input from George and Tom – it would leverage their
time really well. This could start before documentation does.
My fault as an engineer is prematurely jumping to nuts-and-bolts