First published in the language document @blueju
Status:
The previous documents were all written by each team member as assigned by the original team leader. Although it was mentioned that review was required after writing, it was rarely reviewed in practice. Therefore, the problem mainly lies in two aspects:
- The leader himself is fine.
- Group members do not have the awareness to propose and promote the review (to be honest, ordinary people are really difficult to have)
Plan:
I can’t say I’m right, so I use the word “plan” instead
Personally, as a group leader, I should write the first version of the document myself and hand over the subsequent modifications to my subordinates.
First, as a team leader, you should know the cause and effect of the object described in the document before anyone else. Second, it is not up to subordinates to decide how to write the document; third, subsequent modifications can be handed over to subordinates, but they need to provide them with some information. Fourth, people also grow up slowly. The subsequent revision and modification can let subordinates list the outline to check whether they have achieved the results desired by themselves or more senior leaders.
Something to think about
What I think is worth thinking about: document architecture (technical point)
Like our team, The documents involved include the Base permission Operation guide, sub-application development Guide, Quick Start, sub-application Access Base Guide, front-end OSS upload Guide, NgFE-Request unified request plug-in usage guide, front-end development specification Manual, NgFe-Permission plug-in usage guide, and NGFed Component library documentation, etc.
With so much content above, it can be regarded as a wealth of knowledge for the team if we can sort out the relationship between existing documents and think about the possible new documents in the long term, remove public documents and link them in a way without repeated writing.