Programmer, how to write a good document? _ Research and development management

When you hear about writing a document, the programmer's first reaction is: Why do you write a document? Do not write. Programmers, we are good at coding, good at discussing programs, arguing technology, most of them are not good at communication, especially not good at writing documents. Remember our team have children's shoes in the weekly newspaper on one word: Modify bug:tdxxxx,tdxxx2,tdxxx3 ....
So the question is, does the program want to write the document. Why do you want to write a document? How to write a good document. 1, what is the document.

Communication minutes, minutes of meetings, weekly reports, work summaries, requirements documents, overall design documents, detailed design documents, unit test documents, test case documents, requirements change documents, product manuals, project summary documents, etc.
2. What is the purpose of writing a document?

Have you ever met a morning meeting, weekly meeting when a problem has been discussed clearly. But after a few days or near the end of the week, some of the kids ' shoes in the team say, "I don't know, I didn't say this or this plan," so the BB thing is very troubling.
In order to avoid the problem after the blind BB, special need to form a written record down.
1 good memory is not as bad as writing, we discuss a good plan, sometimes just a flash, as soon as the record will retain inspiration.
2) traced the roots. During the oral meeting, we had a discussion about the plan. However, the actual understanding of each individual has different, after the timely formation of documents and even charts, copy to the participants, to facilitate consensus. Such as: can clearly define the responsibility, detailed division of labor.
3 when the real writing, more convenient to comb the train of thought. such as: The requirements of the document will clearly define each customer demand point and requirements, is the premise of user benefit protection, party A, party B communication and Bridge. Such as: Meeting Minutes is a summary of the results of the meeting, there are problems, responsible people, the cornerstone of a clear solution. Such as: Change the basis of demand, the original requirements how to write, why not meet, the reason is what. How to modify and so on. 3. What are the pain points of the document?

1) think it is not valued. Programmers often feel that it is not necessary to implement the technology is OK, the other is not important.
2) really do not want to write. Will form a vicious circle, not to write this time, next time, next time.
3 feeling not necessary. Feel no need to write, do not know why to write, do not know what to write. 4, the importance of the document 1 research and development based on the implementation of the function

Requirement detail is the basis of development technology, and every point in the requirement matrix must be covered and perfected. 2) is related to the sustainability of the project.

Project management contains document archiving management, planning, requirements, design, and so on throughout the process of the project all documents are to be archived. Good basis for the next release or follow-up project. The first and foremost reference documentation for a new team member. 3) is for the evidence to facilitate the pursuit of responsibility

The project has appeared through the party A, party B's mail as evidence of the case. 3, how to write good documents. 3.1 Sketchy

Make an outline or refer to a company template document before writing it, including which parts, the main points of each part are thought of.
With the outline, then pen to write. 3.2 Logical Clarity

Try not to colloquial, logical clear, primary and secondary trenchant. such as: Weekly Good ways include:
1 work last week: itemized.
2 problems encountered last week: list by article.
(3) Last week's risk point & Pending discussion: a summary list. (discussed after the meeting)
4 Plan this week: list by article. 3.3 Illustrated

Do not omit places that require diagrams and tables. For example, design documents: Frame composition, module diagram, class diagram, activity diagram, flowchart and so on.
For example, in the design document, sample configurations. ini,. xml,. conf to describe the fields and meanings in a screenshot or form.
A picture of Bai, there is a picture of the truth. 3.4 Sync Update

This is very important. If the design is actually implemented, it may not be consistent with the document. The implementation of the change, the document to follow. facilitate their own follow-up to eliminate problems, but also for the future maintenance of the project for the benefit. Otherwise people will look at the confused.
For example: code updated, note to synchronize updates. 3.5 Providing awareness

Team and even the company to form a consistent solution, attaches great importance and permeates. 3.6 Global Co-ordination

We may not be able to adapt to the first programmer, but think of the pros and cons. To adapt gradually. and high-level to overall co-ordination, do the appropriate rewards and punishments measures to enhance the awareness and enthusiasm of everyone. Summary:

The document is not scary, think of our complex architecture head can be straightened out, many logic can be achieved, the document is small case.
However, even so, programmers need to attach great importance to the document.

2016-06-19 Sunday 16:18

Author: Ming Yi World
Reproduced please indicate the source, the original address: http://blog.csdn.net/laoyang360/article/details/51712757
If you feel this article is helpful, please click on ' Top ' support, your support is I insist on writing the biggest motivation, thank you.