早晨读了阿朱的书，老系统那篇。联想到在我的实际工作中也存在着一样的问题，虽然我不维护老系统，但在开发过程中一样有应付不完的新需求，客户总是觉得每一点都很好实现，但事实则不然。另外在对系统的修改过程中，也出现过先是让改成某种形式，隔些天又让改回去的情况，没有详细记录也就无法跟客户理论，很不爽。所以一样有必要想一下如何规范话需求、变更和Bug的提交，做好对需求和项目风险的控制。
初步设想是对于新需求，统一都要由业务咨询部来提，并且是按照产品研发部规定出的某种格式通过邮件来提，然后我们来评估是否可作，或实现的工作量。客户不能直接打电话给开发人员，开发人员收到了也要转给业务咨询部；变更也要也如法炮制；Bug的话可以由客户按照我们给定的格式来提，然后我先全看一遍再进行任务分配，改好后要经过部门内的互相测试、测试部门的测试之后请客户进行回归测试。
具体的文档格式春节这几天要想好，放假回来和研发部经理讨论一下细节，然后尽快推行之～～今后日子会好过一点了吧我想～～至少会过得很有条理了～～
初步设想是对于新需求，统一都要由业务咨询部来提，并且是按照产品研发部规定出的某种格式通过邮件来提，然后我们来评估是否可作，或实现的工作量。客户不能直接打电话给开发人员，开发人员收到了也要转给业务咨询部；变更也要也如法炮制；Bug的话可以由客户按照我们给定的格式来提，然后我先全看一遍再进行任务分配，改好后要经过部门内的互相测试、测试部门的测试之后请客户进行回归测试。
具体的文档格式春节这几天要想好，放假回来和研发部经理讨论一下细节，然后尽快推行之～～今后日子会好过一点了吧我想～～至少会过得很有条理了～～
9202
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
