在TB产品开发过程中，UC是至关重要的内容。它是将产品设计者拍脑袋想出来的东西，转化成页面可见、流程完整的形式;是开发工程师系统设计和实现方法的依据，是测试工程师测试设计和确定质量可靠的依据。重要的内容，应该由决定性的人物来制定。那UC到底由谁编写能够达到佳的效果?

目前接触了2种UC编写角色：开发和PD。这里定义的PD，包括2种情况：a，需求完全由自己构思，不受第三方限制;b，需求由第三方比如运营提供。定义的开发，是指具体实现功能的角色，包括系分和普通编码者。
设计好的UC，需要的能力概括起来，是：对需求分析理解要到位，对实现需求的分析要到位，系统设计与需求达到完美统一。

本来想要对比分析一下开发和PD在编写UC上的优缺点，打算从几个角度：需求分析能力，系统分析能力等;一比较，发现开发在UC编写上没有什么优势。UC，是需求的细化强化，需求要考虑到的点都要在UC中体现。如果从这个角度想，那UC由PD来写是合适的，因为PD清楚需求要做成什么样子，细节点的考虑要如何等。开发仅从系统角度和实现上对需求进行分析，而需求基本上不会随着设计而发生变化。

由PD编写UC的好处：

1.需求了解，能够将功能点描述清楚;

2.对整个产品有一个整体的认识，在UC中能够考虑到相互功能之间的关系;而开发可能只会关注自己手上的功能而忽略了相互之间的关系，产生需求盲点;

3.减少沟通成本，若由PD编写UC，则需求是完全由PD决定，即使是N个字符，应该要提示什么，在UC中都已经明确;那么开发只需要根据UC来进行相应的代码设计，测试只要根据UC来设计用例;若开发主导UC的编写(前提需求上对N的要求不强)，测试首先需要根据开发的N字符设计，跟PD沟通，PD同意还好;若PD有异议，还需要三方沟通，有意无意的增加了沟通成本。这个比方可能打的不恰当，不过现实工作中会遇到这样或那样因为需求不一致而引起的问题。

而目前TB的UC是由开发完成，有人会抱怨UC质量如何如何差，写的不够细等，其实不能够责怪开发，毕竟开发只是实现方而非设计方。根据一个粗略的 PRD，开发不仅要考虑系统上的实现，还需要考虑粗略需求上的细化，似乎有些强求了。挺难为他们的，考虑的再细也会因PD的一句话而被否认。罪过罪过也。与其这样，为何不将UC编写的职能划分给PD呢?可能有历史原因考虑，那是否今后可以再次考虑换一种方式呢?咯咯，有点强求了….罪过罪过。

总结标题，我认为：UC由一个有经验的PD来编写是恰当的，如果PD曾经拥有过开发经验，那这个PD是完美的UC编写者。有不同意见者，拍砖即可，我的经验有限。