Improving return on investment during Developer training

Product development is a highly specialized activity, for innovators and managers it becomes a daunting task to maintain the product once it is developed.
Often if not always, a product is developed with extraordinary efforts of an individual or a small team having in depth knowledge of the domain which is difficult to acquire via any training program. Another problem is that while many developers and managers are aware about the benifits of documentation and other tools to be used in product development, they are offen ignored due to extra ordinary time pressures during incubation of a new product. At the time when new product  development starts, it is mostly in develop / test market scenario, and developers are in hurry or in pressures to get the working product out. And since they are quite familiar with the domain and product, all the talk about documentation appears to be an overhead.

Usually during the course of a successful product development, people who had originally worked with the product and who have the in depth knowledge about it, move to other responsibilities due to either promotions or better prospects. Now the responsibility of maintaining the
products falls on those who have never worked in that domain, with that product, or even the tools and languages used to develop the product. This new set of people may have experience in working with other products where they may have not been involved from the beginning, in such cases they may have developed
some strategy to deal with this problem or if they are lucky they get some
documentation to guide them in their efforts. Following is a way to help bring some order in such scenarios.

The starting step should be to introduce the newly hired or appointed developers to the domain systematically. Fortunately this technique is followed by good managers or excellent developers turned managers or at times it happens by chance where the developers happen to
be the users of the same product. But many other times short sighted management who is interested in quick returns of the high salary paid to the developers just jump them to the development tasks immediately which may lead to failures. and most of the
times pressures are put by those managers who do not understand either product development or the domain. but ultimate loss is suffered by the customers,
the company and developers. We need to understand that a business exists to earn handsome returns on it's investments, but a long term view is required to understand that product returns happen over a longer horizon and it requires discipline of mind to resist the tendency to get a quick return. Although fast return is not something wrong, it requires careful analysis of the situation and being aware about the potential pitfalls . A solution which may help reap good returns is to follow a
systematic process of introducing the developers to the increasing complexities of the product as well as the domain while getting some return on the
investment.

Step 1: let the developers do the user level testing as part of introduction
of the product. This may sound strange to many developers, after all they are the
developers who are promised challenging task of development and the organizations
usually pay them more than what they pay to the testers. But in spite of the high salaries, the task of testing is more important than doing the development.

Separation of testing and development is done to elliminate creator's bias, if we can train developers to be self criticle, then we may not need testing as a separate function. Organizations put in place processes to provide information of user experience to the developers, But in spite of processes, there is no substitute for a well informed developer who has instinctive understanding of user experience.

 

The testing should be formal as well as rigorous, i.e. during this time developers should log the test results, be rated as per their work
on testing etc. Duration for the testing work should be what company
perceives as necessary for a normal tester plus couple of weeks.

And since developers are involved in formal testing, they will record the results which should be used for further analysis. this way the
organization will recover some investment while developers are being trained on the product.

 

This has another advantage of filling the psychological gap between the developers and the
testers which will enhance the product quality by increased communication between them.

Step 2: An intermediate step should be to let the developers be involved in
product support! Product support requires people to understand the user
perspective,
leading them to appreciate what users actually need. This appreciation gives
refined level of domain understanding resulting in a better quality product.
since product support requires higher level of product appreciation which
comes from working on the product as a tester and working as a product
support
leads in refined understanding of customer requirement, it can really boost
the product quality.

Step 3: Now the developers are familiar with the domain, including how the
product fits in the domain, Natural transition from testing / product
support
would be to fix the defects which the developers have discovered. however it
is not at all required that they fix only those defects which they have
discovered,
it should be mostly spread over different sub components / modules / section
etc. The idea is to cover broadest span of the product. during bug fixing,
the organization will recover the investment and the developers will be
familiar with the intricacies of the product to an extent. During this faze
management
and senior developers get opportunity to evaluate the capabilities of
developer and the developers can be given future assignments for different
tasks
based on their understanding gained during this time of the product. It is
critical that during this faze the developers get the benefit of interacting
with a senior who can answer their questions. Such a senior should not be a
senior in the sense of tenure or status, should be someone with the
understanding
of the intricacies of the product and the domain. Such a person should also
be psychologically mature, and have lots of patience, as developers may have
infinite questions, and answering such very simple questions becomes
difficult for those who are very comfortable with the product.
Another advantage of defect fixing is that developers also become familiar
with the coding standards and they can familiarize themselves with commonly
available
code within the product which can be reused in their future development
efforts.

Step 4: feature enhancement, Once the developers are familiar with the
intricacies of the product and the domain, they can be involved in feature
addition
and other high level activities. Feature addition or architecture
development of products can not be learned just by text book knowledge, it
is highly
complex which matures only with experience. So such task should only be
given to developers after careful analysis of their skills and proper
introduction
of the product and the domain.

 

Since the developers have been through such a systematic introduction of the
product / domain, they will develop understanding which will be hard to get
otherwise. and during all this process of training the organization gets
return on the investment made on them.