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
of
technology) topic area, you begin with easily FAMILIAR subject matter
and
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
not
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
knowledge)
of each “user class”.
That works.
The reason it works is because each role or user class’ needs and
knowledge
is written out and accounted for, they can be tracked. When a tutorial
or
training section is ready. I can actually ask, “Did I get told in
logical
order?” == Logical order, meaning each topic is presented one idea at a
time, and no new topic/idea is presented before the prerequisites are
presented.
While we may not need such detail, after all everyone knows what a
database
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
machine, is
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:
“Marketing
Myopia”, Levitte, 1960, Harvard Business Review).
You will find that different inductions will be needed to begin
introduction
tutorials different user classes.
Give it a thought. I believe a user profile main wiki page where people
can
develop and refind each user class would be a great beginning.
Our general individual “…fault as an engineer …[to] prematurely
jumping
to nuts-and-bolts” becomes the advantage of engineering when we jump on
the
“appropriate” productive “nuts-and-bolts” issues. Here, I’m suggesting
user
profiles for the new users are very useful!
cheers,
Will.
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