You highlight several important issues around documentation and training, and as someone who is responsible for providing information I recognise the problems you describe only too well. People with jobs like mine - often known as technical communicators, or technical writers, or technical authors - would love to provide information that supports user tasks, rather than information that just describes the product, but there are often obstacles that stop that from happening. For example:
1. Some companies see technical communication as a necessary evil, and teams are under-resourced in terms of staff, tools, and access to information
2. Some companies see technical communication as a cost centre, part of product development, and so it's kept separate from Training, which is seen as a revenue source. The result is often that there are two teams trying to provide parrallel information to customers, duplicating efforts and wasting resources.
3. The best sources for understanding user expectations and therefore producing documentation that supports users are from user research. This research is often undertaken and owned by a marketing department that doesn't see the need to share. Data about what features are least well understood - the features that need to be explained more fully in training or documentation - could be gathered by reviewing calls to Customer Service, but once again, it is rare for this information to be shared.
Training and documentation serve different purposes and both are needed, especially for new users or even for experienced users who are being introduced to a methodology or major tool feature that is new to them.
Those multi-day offsite training courses in a room full of workstations are expensive, but can be incredibly valuable. The knowledge & experience gained by using the tool in such a focused environment with an expert instructor cannot always be duplicated by simply reading the documentation and trying things on your own.
I first like to read specifications of every new tool or device I encounter. So this way, I know the most capabilites. Reading documentation is sometime time demanding and not many family member have patience. So manual I read as need basis.
First of all...a very nice article!! I am a user of EDA tools. I have not spent much time in reading the manual, but while reading through this article I realized that I might not be using the tool most efficiently. I think training is absolutely needed to start with. If the user works with an EDA tool frequently, training should be enough to start with. When ever I get stuck, I ask some expert users in my organization. That is quick...but if nobody is around to help, the manuals get handy then...only wish that the manuals are presented in a way which does not bore the user. :-)
A Book For All Reasons Bernard Cole3 comments Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...