最近在做一个赛季迭代，玩家数据变更的需求。本身的需求很简单，就是检测到玩家进入新赛季以后，根据需求对玩家数据进行适当的清理。窝火的地方就在于，这个需求，策划一直理不清楚。我们的策划曾经在策划案中直接写过这么一句话：除了A活动、B活动、C活动之外的所有活动都需要清理。问题在于，除此之外的所有活动，是什么活动？策划说不知道。没有活动名字，有的时候甚至只有一张截图。由此可见，项目系统案、活动案的缺失程度了。
运营方不停的反馈，我们提供的清理数据和实际清理的数据不一致。一开始决定从头开始理：找了1个前端同事、1个策划同事、2个后台同事， 根据自己的项目做了一次调研（= =！），理出来四五十个系统、三四十个活动，系统的策划案缺失了四分之三，活动的策划案基本全部缺失。这个进展不下去了，只能把理好的东西转给策划，希望他们能补上缺失的文档。现在只能根据运营方的反馈，缺一个补一个。最后让策划根据运营方的反馈整理了一份最终需求，这份需求，是不是最后运营方想要的，其实谁也保证不了，理想的状态是，我们有资料可以和运营方做验证，但是明显我们做不到。所以这个功能从一开始就无法完全做好，一个需求都不清晰的功能怎么可能做得好呢？
回想起自己待过的项目组，基本很少有项目组会整理策划文档、归档策划文档，大多数的做法就是，系统做之前给一个模糊的文档，然后和技术人员讨论，讨论完实现完，就完了。几个月以后，提到这些系统活动，就只能以代码实现为准了。
策划案誊写的标准、归档，项目管理软件的使用。
策划案誊写的标准
1、策划案的誊写，应该逻辑、表现、数值尽量分开，方便程序、美术等技术人员查阅。
2、在功能的实现过程中，会出现各种调整，不管是何种调整，最后都应该补充到策划案中。
3、某个系统、活动的策划案，应该有且只有一份，比如提到某个系统中的小改动有一份策划案，最后都应该归纳到最终的策划案中。
策划案的归档
1、每个系统、活动都应该有一个编码，因为策划阶段和最后投放阶段，有可能会换名字，系统策划初期和后期也有可能会换名字，如果只用名字标记，后续根据需求一换名字，就混乱了。
2、要有一个项目所有系统和活动的总表，上面依次会记录系统（活动）编号、名字、涉及的配表、策划文档路径、美术路径、测试案列路径，甚至可以标上各小组负责人等。最关键的是，这个总表需要维护。
项目管理软件的使用（redmine、mantis 等）
1、系统、活动在项目管理软件上开了任务以后，首先上传策划案，中间讨论的结果最好都能记录在案，方便查询；最好系统完成以后，还能上传一份归档策划案。禁止口头达成一项修改意见或者通过沟通软件达成一项修改意见，最后没有体现在项目管理软件中、也没有归档到策划案中。
2、每一个任务都应该有相应的标签，每个人描述一个问题的用词都有可能不一样，如果没有相同的标签，根本无法查找哪些 bug 已经在管理中了，哪些需要补充进去。
最后：不要把项目寄托在某个人身上，不要什么需求没有文档记录，就说找某个人，他做的，他实现的，要学会使用工具，要用科学的方法做归档，把项目的数据有机的整合起来，方便查询和确认。因为人最后都会死走逃亡伤。
原文地址：https://www.cnblogs.com/ljm0/p/11320226.html