Full.CX

Full.CX 是什么

这个名字指向客户体验，但它做的事情完全是另一回事：把一个只存在一两句话里的产品想法，变成工程团队可以直接动手写的材料。

它点出的缺口是多数团队都认得的。需求到的时候很模糊，开发者自己把洞补上，分歧要等活干完才暴露。产品经理、创始人，以及小到请不起分析师的敏捷团队，是它预设的读者。

你可以用它做什么

你用日常语言描述想要什么，拿回来的是一整套东西：用户是谁、功能做什么、适用于什么场景、每一项怎么测、数据怎么串起来。这一套通常要吃掉好几天的写作时间。

这里最吃重的是验收标准，因为它是把需求变成可测之物的环节，也正是团队最后才写、写得很差或者干脆不写的东西。所有内容落在一个共享空间里，产品与工程读同一份参考，而不是两份。

适合谁使用

最明显的读者是把写需求当本职的产品经理，以及没有产品职能可以把活交出去、最后只能自己写的创始人。

希望工程照单接受而不是争论的小型敏捷团队适合这里，为客户开发软件的外包机构也可以把同一份产出当交付文档转出去。见过一个 Sprint 最后为「某一句话到底什么意思」吵架的人，都会认得这个处境。

需要留意什么

生成的标准会继承描述里的假设。一段意图文字产出的是覆盖那段文字所考虑到的标准，而没人提过的需求，恰恰就是后来吵起来的那些。

几分钟就交来一整套完整规格，看起来像是做完了。危险之处在于把它当成已经评审过，因为评审才是抓出误解的那一步，而一份这么完整的文档会让跳过它变得很安全。

从功能描述建出来的数据模型是最弱的一环，因为任何模型都必须与系统已经在存的东西一致；一个适合这个功能、却与现有结构冲突的模型，要等实现开始才会被发现。

人物角色描述的是合理的用户，不是真实用户，它适合用来暴露假设，不等于做了调研。厂商自己的文案读起来热情到几乎不谈限制，检查页面时也没有读到价格。