In my team we use a wiki to document our processes and we try to match the process overhead to the task that it runs.
For example, some processes are just a list of bullets for a QA engineer to review - perhaps when smoke testing an internal script. Others have to coordinate actions from several parts of the company, with control passing back and forth as different deliverables are generated, reviewed, tested, built for production, tested and deployed.
All the participants in one recent project use Bugzilla for defect tracking so, to avoid reinventing the wheel, we controlled a process using bug tickets. Each stage in the process corresponded to a stage in the life cycle of a ticket and we provided pro-forma comments that just needed editing with the details that changed on that iteration.
Say you'd produced the first-round deliverable, then you'd mark the bug fixed with a comment that told QA where the deliverable was and what the expected performance envelope was this time around.
The process is the road you follow to complete the task. Along the way different people need to start and stop and you want them to drive on the right side so they don't crash into everybody else. Put traffic lights and white lines on the road to guide them. And from time to time the road will need repairs. Fill the pot holes in quickly or people will start to use their own routes.
Comments
Post a Comment