宋老师软件质量初级训练营2期满员开营了，群里同学提的问题很多，有些问题可以在群里直接解答，有些有共性的写成推文可以供学员和各位粉丝朋友学习，也欢迎留言补充。
产品需求到底应该写成啥颗粒度？
产品需求文档的核心作用是交流信息，面对面的交流肯定是效果最好的，但人类的记忆会衰减，单位时间内信息处理能力也有限，所以需要文档来记录，并通过结构化、规范化表述来使得信息接收方能顺利的理解并正确开展下一步的工作。
所以，具体要写到什么颗粒度可能不同企业不同团队都有所不同，但我总结有2条基本的原则：
- 需要使用这份文档的相关方，能否通过文档信息正确开展下一步工作；比如，设计人员 用来进行架构设计、测试人员用来设计测试用例，以及未来维护产品的人员快速理解产品的结构。
- 这个产品需求的颗粒度，是否可以被测试验证。原则上所有的需求都需要被验证，而能否被验证，也侧面说明了，需求描述的清晰性、可评估性，就可以透明化、可控。
但是在实际工程实践中，可能不同颗粒度会在一个文档中并存，有些需求会粗颗粒度，有些会细颗粒度。比如，需求中如果是改进型产品，大家比较熟部分，可以粗粒度编写；不熟悉的部分，要细粒度一点。未来变化可能小的，可以细粒度，变化可能大的粗粒度；另外，根据不同执行人员的素质，素质高，可以粗粒度一点，素质不够，需要加强管控的，需要细粒度。
总体来说，
粗颗粒度
优点是，周期短、可维护性强，能快速应对频繁变更的情况，灵活度高；
缺点：后期接手的人员维护使用难。
细颗粒度
优点：易于评估和管控，利于做出准确的计划。
缺点：导致写文档周期长，变更可维护性差。
所以，具体写成啥颗粒度，还需要根据项目的实际情况来合理的确定。
End
