【心灵实验室】系统文档需要写道什么地步才能交给程序

soullab

策划甲
问下大家，你们的系统文档需要写到什么地步才能交给程序开发

策划乙
我们忙不过来的时候很多东西口述，也忘记补文档。，。。

策划甲
需要写到每个逻辑判断嘛

策划丙
那样做，会被程序耻笑的

策划甲
我们要求按钮的逻辑都必须写到位

策划丁
有些关键点 我还是写得比较细……主要是怕出问题

策划乙
我们这还好，程序玩游戏的，喜欢口述。。

策划甲
数据库字段也要策划来设计，这不是扯淡嘛

策划戊
口述的问题不在于做，而在于查

策划戊
有些公司的确这么干的。。
还有数据流、。、

策划己
得看什么程序了 ...

策划丁
公司初级阶段都是口述的

策划乙
比如最早做移动文档，本想写好，后来程序直接过来问：和魔兽差别多大，我曰：自动寻路上要考究，程序曰：其它呢，我曰：基

本没差，动作上下半身。然后就直接做了，至今没补文档

策划甲
主要是你写了逻辑，程序又不是按你写的做..

策划庚
口述就怕之后无案可查

策划甲
这是问题，新人接手后没东西看

策划乙
是，但是后来实在忙不过来，一直没来得及补文档

策划庚
写一条一条的重点也行 格式和??碌幕翱梢悦饬

策划丁
恶性循环的说……


策划辛   
虽然说我的回答比较贱。。。但是答案是
写到程序能看的明白，并且能做的出来就OK。。。。
这个标准在每个公司和团队都不一样啦。。

策划庚   
我们做系统设计的流程是
第一步写系统框架文档。内容主要是系统设计目的、规划、玩法重点；
框架文档出来以后讨论一次，确定方向没错。
第二步写系统设计文档。内容主要是系统功能模块划分、规则、具体玩法和数据接口，也会带上具体的界面草图；
设计文档出来以后再讨论一次，确定整个系统功能无缺无错。
再之后就是细化到系统制作文档，也就是给程序看的执行文档，内容就是具体的规则、系统流程说明、流程图、控制表说明。往往

还会附上界面功能文档和数据表。
当然，这个制作文档在给程序之前还会审核一次，不过一般就不是开会讨论形式了。

策划壬   
   引用：策划甲
         数据库字段也要策划来设计，这不是扯淡嘛

这句话本身才扯淡。。。
初期做框架，中期做设计，后期做笔记。。。

策划壬  
补充下
好的设计文档，最后可以当作QA、QE的用例文档。。。
就算各位所在的公司对文档的要求没那么严格
各位策划也应该在设计时考虑到这些 最好自己记录下来：）

策划癸   
文档的详细程度还是要和团队的软件能力成熟度有关。
如果是磨合默契都很好的团队，口述加上补的一点框架图就够了。
如果是还在磨合期的团队，或者程序本身能力有限的，再详细也不为过。

“写到程序能看的明白，并且能做的出来就OK”
“初期做框架，中期做设计，后期做笔记”
同意以上。

我自己写策划案，同一个案子是分成几块写的，要写几次。
第一次写初期的框架，设计的原因，构想，牵涉的东西。
第二次写
1、策划和程序看的部分：具体的概念，数据库的需求，文档的需求。
2、程序看的部分：逻辑部分，各种图，接口需求。
3、美术和做UI的程序看的部分：功能示意图，布局，各个接口调用的东西。
第三次写
修改，讨论的结果，执行的决定。

如果程序和策划之间默契很好，很多东西都可以用简单明了的图就代替了。
统一建模语言是一个好东西，但是在策划内部都没有普及。

在表达上图>表>文字，这点是不会变的。

策划A   
补充一下
1、对内，统一策划部的文档规格。
2、对外，越详细越好，最好还有后续跟进的记录。

策划B   
我们现在是三部分内容合在一个文档里面了：
第一部分是概述，包括设计原因，构想，牵扯内容；
第二部分是设计，属性定义，数据格式需求，逻辑；
第三部分是执行文档，执行步骤，细节逻辑，界面效果；

然后数据用单独表格，界面单独出详细流程图。

放在一起主要是方便自己查阅，同时给程序知道前因后果便于程序提出自己的意见，然后根据最终讨论出来的设计同步更新备查。

缺点是更新量大，执行文档不够详细，后期没法直接给QA做用例。

我觉得文档这东西在完成了准确传达设计的功能以后，最重要的功能就是备查，保证设计者和其他使用者任何时候都能获得一致的

设计。

策划C   
从公司要求角度讲，文档设计只要其他部门看了点头认可即可，比如程序点头认可。至于认可的标准是什么每家公司都不一样，每

个人的要求都不一样。
但是如果从策划本身的责任来讲，文档设计应当有完整严谨的逻辑结构，谨慎的细节处理说明，尽量完善的异常情况处理方法，清

晰且有条理的文档结构。

策划D   
看是什么系统了，一般一个流程图，外加异常判断的提示内容，少许界面和相关的界面规则，然后重点功能在文档上注释后口述，

基本没啥偏差~

策划E   
主要看这个需求案在你们团队中的工件级别了
公司总部的策划需求就会标记出数据字段，甚至是数据流向
详尽的文案肯定是有好处的
不过这也一定层面上增加了执行工作量和执行工作门槛
所以主要还是看团队衡量了

=============================================华丽的分割线===========================================

   简介：心灵实验室是一个关于游戏设计的讨论群，我们通过群论坛作为载体讨论游戏设计。通过一人提问，多人回答的方式，共同探索游戏设计之道。

BLOG地址：http://thesoullab.blog.sohu.com/

spy

授精

与世无争

标记出数据字段、数据流向、算法、无漏洞逻辑关系、UI、操作命令……

貌似只有为什么这样做的原因才会跟程序口述

eff8888

大致流程图（但是和视觉表现无关的功能别写）+简要文档各一份

c274887583

在保证程序、美术能完成设计需求的基础上，尽量完善文档。

jjyy5566

貌似写清功能和流程就差不多了

jimey99

文档，是写给策划自己看，理清思路用的。另外一个作用是做记录，免得以后扯皮，说不清某个功能的细节，查照文档。

一般分四大块：玩法设计/数据组织与存储/UI设计与操作/提示信息。把这些部分写清楚，一般几万字吧。

对程序员而言，还是拿着文档，策划对照着讲解一遍比较合适。不然，几万字的文档，谁有功夫细看。我自己看还觉得长呢。每个程序员对游戏的理解都是不一样的，如果是有经验的，稍微说说就理解了，没有经验的新人，还得你帮忙讲数据结构。不同人，需要不同的情况来出来，才能把问题处理好。

ps，文档的另外一个功能是方便测试部写测试用例。。。。（ps，策划文档一般不写异常流程的，这是测试部门的活儿了。）

eff8888

主要因为太长的文档没人喜欢看，如果有人喜欢看，那他一定是变态会长

OuDaYe

不错，吸收之

I社爱好者

作为程序员，发表一下我自己的观点，
我喜欢的文档是带图的，对于某个具体的功能模块最好第一部分就是一张未来的游戏界面设计图，不一定是最终定稿，因为从图里我可以知道会有多少事件，以及会显示那些数据。
然后就是对功能的详细描述，说明性质的描述有一些，能让人理解就行，剩下的重点是给规则描述，要1、2、3、4这样一点一点的列出来，但不要把这些东西画成流程图，会干扰我的思维的。当然在开发时，如果发现规则上存在漏洞和不足，我还会和策划进一步沟通并补充完整。