第三章 转折16 拆解复杂

我们的需求和研发管理使用了自研的一套系统，简称IDO。IDO是非常不错的一套系统，简化了很多需求管理的问题，我们对它的依赖度很高，PM也会自己在上面给自己提需求。

需求都需要我来评审，也不只是我，还有各个模块的业务负责领导。把事情写清楚，会降低相关人的理解成本、提高审批的效率，所以我会在第一个环节仔细评审大家写的内容。

我发现，很少有人能把一件事情写得很清楚。把一件复杂的事情说清楚、简明易懂，确实是很有难度的，一般来讲除了文字描写、还要辅以举例、截图、流程图等方式，这里重点说说文字描写部分。

首先，还是要明确读者是谁，换位思考，对于不了解背景的读者，要思考如何能够帮助其直截了当了解事情的前因后果。

其次，就是拆解。

在阅读大家方案时，发现一个很常见的问题，作者把背景、冲突、问题、方案揉到一起了，没有说清楚背景就直接说要做的事情很是司空见惯。

鉴于此，周会上我给大家分享了SCQA的模型，帮助大家提升写作能力。

SCQA并不复杂，就是背景、冲突、问题、答案的缩写，写一件事情，如果按照这几个维度和顺序，逐点交代，就会显得简明清晰。比如：

背景（S）：大家会提报IDO、写需求和产品方案，客户会审批

冲突（C）：IDO中的需求/方案不够清晰，很多信息混淆在一起了，审批人难以快速做出判断

问题（Q）：如何能把需求写好？

答案（A）：客户视角，不是我想怎么说，而是客户怎么看；写作拆解，我是在说问题、还是在说方案？

其实拆解的思路也不只是在写文档，产品设计中也很常见。

今天和小萍讨论了一个产品方案，发票管理中，小萍额外加了5、6个字段来支撑用户对于特定期间发票变更额度的统计需求。我反馈了设计上过于复杂了，发票管理应该是以发票实体为中心，支撑各类发票的上传、状态更新等；而发票额度的期间统计，明显是统计报表类的需求，是动态数据的展示，应该提供新的报表能力来满足这类需求，这样使得每个模块负责独立的场景，从业务理解到研发实现都比较清晰，虽然看起来多了一个模块，但反而降低了难度，保持了产品的简洁。

能看出来，小萍对于我的反馈不是很理解，毕竟类似的事情做了不少。对我自己，一方面还要持续学习，加强理论修养并提升说服能力，另一方面，还是要保持耐心，认识到习惯的阻力是非常强大的。