对于范式化需求文档和流程的几点总结

1.范式化的需求文档

制定一种符合某种范式，格式化特征更加明显的文档规范。

我们在看策划文档的时候，其实往往看的是策划对需求的描述，然后根据策划的描述反推需求本身是怎么样的。也就是说，现在的策划文档对于需求是描述性的。我确信会有一种更加直观，更加接近需求本身该长成什么样的一个文档形式。做的需求越多，这种感觉就越强。

 

2.定义>说明

• 我们很多人在做需求的时候，经常发现做到半途，才发现需求文档里还有些没有定的行为。虽然开发做功能的时候可以预先考虑这些问题，但一个简明清晰的文档规范对解决这个问题有很大的帮助。
• 以后策划在写需求文档的时候，不再是写某个功能的说明文档，而是定义这个功能。写需求文档的过程，甚至会有一点像在填写配置。
• 如果新的文档规范要求策划以类似于伪代码的结构来写文档，可以帮助策划的同事提早发现一些需求里未定义的行为。
• 即使没有达到上一点的效果，这种符合范式的文档，对于开发预先考虑这些问题，依然可以起到很好的帮助作用。
• 新的文档规范必须以开发更容易理解的方式组织。假如每个策划写出的文档的风格都是类似。这样的话，开发对于理解不同需求的文档的时候，需要花费的精力也会更少。
• 同时，统一而简明的特点也有利于同一个功能的多个版本之间的比较和修改。比如需要修改一个功能的某些规则的时候，哪些规则要改，哪些规则要保留，一目了然。

 

3.规范文档的更新

• 由于文档是多个岗位的同事共同使用的东西，制定这个规范的时候，必须有多个岗位的人共同商议决定。
• 规范好产生规范的规范，千万不能由一个人拍板就决定了某条文档规范的制定或者修改，必须确保每条规范的产生都是经过讨论和推敲的。
• 一条规范的产生貌似可以参考这样的流程：由一个人提出想法，然后大家商议是否采纳，是否需要修正，怎么修正。
• 在执行的时候如果遇到文档不适用用的情况，也要走上面的流程去更新。

 

4.对于所有工作上的流程规范，给出统一的正式文档

• 现在的规范，更像一种潜移默化，大家默认遵守的流程纪律。一些我们习以为常的习惯和工作方法，常常有新同学会表示不知道。而且因为信息不对称，新来的同学甚至不知道有这些规范的存在，我们有时候甚至会假设他们已经知道了这些东西。甚至有些老员工对流程和规范认识也会有盲点。
• 虽然可以用口口相传的方式传播，或者让他们去wiki或者特定的svn目录下找一些文档来学习。但其实我们默认大家需要知道的东西，是多于成文文档的。
• 而且，伴随着我们工作的时候出现的各种问题。这些流程和规范会有很多细化、修改或者补充。而这些东西需要一个统一的地方来记录，以免造成我们的新规范没有同步给大家，造成有些同事的认识仍然停留在老的规范上，或者不知道新补充的规则。
• 既然是规范，就应该是可以快速全面学习。既然要学习，就应该有明确的学习材料。大部分的规范都应该有标准的答案，既然这样，建议出正式文档来规定这些东西。尽可能地用正式文档来规范我们的流程纪律。
• 虽然对于每一个发送到讨论组的规范，项目组的每一个员工都有责任去学习他。然而，这种分散的方式对员工自我管理的要求太高了。如果有集中、完善、持续更新的正式规范文档，那我们就可以随时地学习这些东西。一个好的流程对个人主观能动性的依赖应该是尽量低的。

 

5.细化对策划提需求和修改需求的纪律，量化地评估需求变更的工作量，对需求的变更作必要的解释和沟通。

 

希望我们日后的流程和规范能够持续改善，至少能够可回溯、对个人低依赖、过程有量化、计划的制定，修改和执行遵循必要的、正式的纪律。