需求管理:有三类需求不记
没有说清楚原因,不记(你做个XXX出来,别管那么多。)
不说清逻辑的需求,不记(啊,这里我也没有搞懂,你先看看)
不是实际遇到的需求,不记(哎,我觉得可能有人会这么用)
分析需求时,先梳理逻辑再出方案。能画流程图的画流程图,能画逻辑图的画逻辑图,能画脑图的话脑图,穷举整体的逻辑。
讨论方案时,产品经理一起探讨。
做可行性评审时,技术人员多从逻辑角度提问题。
需求文档,建议要把完整的功能描述文档整理好,而不是每次都迭代一份文档,只关注当前修改的内容。
针对跟业务部门的合作,制定的规范如下:
1、所有需求必须通过邮件发出,否则,不予理会。(目的:为了记录内容和明确责任人)
2、业务方的需求提出者是固定接口人,不接受其他人的需求。(目的,避免业务未内部达成一致的情况下提需求)
3、产品这方也设立固定接口人。(目的,防止需求重新设计)
4、需求的状态每周固定时间发布。(目的:让需求来源方放心,了解需求正在推进的状态)
5、有延期的需求,发送邮件给相关需求方,告知原委。(目的:让需求方了解延期的原因)
《纸牌屋》里面有句话,“你得先学会划船,再去学掌舵”。作为船长,可以不去做水手的工作,但不能不理解水手的工作。
//待续
网友评论