1.1 OJT
Definition for this purpose:
Make a just-out-of-college or almost-so new employee to work on a problem in an ongoing project and let him come through it.
Action:
The employee should be handed a problem that has enough complexity. The employee has to setup his or her environment based on the choices made for the project. The employee could solve the problem in parallel with the team. This will prevent him from being a bottleneck, but at the same time allows enough room and an actual problem to think.
Additionally he can also be made to troubleshoot some issues. These issues could be current issues or issues that have been solved but have educational value.
The employee can be presented with a list of training courses, which he can attend to accomplish the task and should be encouraged to ask for one if he is stuck.
Result:
Employee learns to solve some of the problems that may crop up, which will help in production projects. The training becomes a pull model rather than a push model. This results in better take away from training. Since the training correlates with the knowledge required to solve the problem at hand, the information gets registered better.
But, it may also turn out that the employees don’t ask for training as most of the problem might have been solved by one-off discussions.
1.2 Traditional Training
The usual training models involve pushing the information to the employee. The information contains mainly of overview of technologies, which could be easily obtained from the Net and information on standards and conventions. Most of these are not registered in the minds of the employees, as they could not match this with a real need.
1.3 Hybrid Model
A better approach will be a hybrid of the above two. Let the employee go through OJT for a month or so until enough curiosity is awakened and then put him through the training. The training should involve general, but critical information on fundamentals (e.g. fundamentals of webapps – Web server, app server, ports, request, response etc. along with show and tell with a request analyzer), specific technologies (with emphasis on practical application), unit testing. Ideally, an employee could be trained in multiple technologies and then he may align into one or many of them.
1.4 Things that have not worked
Some approaches have not worked very well in an OJT:
- Working on an internal project
Typically, this internal project will consist only of trainees/new employees. The whole team has an air that it is an unimportant one. Most of the times the project is not utilized.
- Involving in a live project, but without any real problem to solve i.e. left to handle routine activities
- Giving a problem from a real project but not attaching any importance to the results or worse not expecting any result at all
Better approach will be:
- If it is a critical internal project, create a real team for it with proper team lead and some senior developers. If not, scrap the project. If it is not important enough it is not worth developing.
- Utilizing an employee effectively only when forced does not add any value to the team. Prepare the employee for tomorrow’s requirement. Automate routine activities and share/cycle non-automated ones amongst the team.
- Push for the results. Use parts of the results where it could be. Expect something that could be used. Give the employee a sandbox branch in the source control for the project and let him commit his changes there.
