“Not Documented, not Accomplished!” might be my most used remark in Jira & GitHub as a CTO and engineering chief 🙄
I hate writing it. However on the similar time I am completely satisfied that documenting duties outcomes is amongst probably the most worthwhile documentation you possibly can write.
Not documenting process outcomes can have many unfavorable penalties. With out Documentation, Individuals circuitously concerned with the duty is not going to know
- if the duty acquired completed, aborted, skipped?
- the place to seek out the outcomes of the duties?
- the way it pertains to different duties?
- and so on.
All of which goes to be essential to know because the workforce grows and will probably be collaborating with many individuals on a number of duties on the similar time.
It is also going to be a treasure trove of “undocumented conduct” as Repositories can develop to hundreds of points over time.
Any outdated bug report, can both be a supply of data on what was tried to repair the bug and choices on why a bug was “not mounted”. Or it could actually simply be a “closed” ticket, leaving you puzzled about what occurred and questioning if that is one way or the other associated to your present process.
Subsequently I like to recommend everybody so as to add quick remark masking the next each time they shut an Problem
- What was the end result?
- Are there any hyperlinks to outcomes, paperwork and so on you possibly can add?
- Are there observe up duties or open factors which might be being tracked in separate points?
Largest problem in being “documentation police” is making that workforce members are usually not feeling checked up on, or in any other case offended. I often resolve these tensions in a 1:1, making certain that that is in regards to the documentation and never about reviewing the standard of labor.
