快好知 kuaihz

程序员要的不是需求文档,而是一份清晰的流程图

我所见过的程序员和产品经理之间产生矛盾大多是因为一个叫「需求文档」的家伙。

有一种恶心的需求文档,我曾经见过,甚至再见到会觉得更恶心,请看下图:

这张图应该会交给交互射鸡湿,交互看着这么长的文字,应该是崩溃的,画出交互图。交给程序员的时候,程序员看着这样的需求描述再来生产的时候,就会问若干个「如果」问题,如果×××情况下,该怎么办呢?产品经理再来更新需求文档,又问,又改,再问,再改,大家都疲惫了,需求文档也成熟了,最后谁都看不懂,一份文档束之高阁,没有任何价值。

请产品经理不要再浪费时间生产这样的文档了,程序员其实根本不需要这份文字式的需求告白书,程序员喜欢「看图」,这种文字式的文档应该是产品同学脑中的思路,而不应该直接把思路描述成文字交出来。

程序员需要的是一份清晰的交互图,这份交互图上在关键位置有一些边界条件的说明,这份交互图不一定非要用什么visio或者乱七八糟的工具输出,一张草纸加铅笔描述清晰即可,但是要还原出需求所描述的所有元素,虽然没有UI设计,但是程序员就可以开始开发demo了。

由产品、交互程序员一起讨论出feature的关键路径,并大家一起脑补好每一个流程,然后简单的画出草稿,我认为是效率最高的方式,并且可以减少很多会议,凡是一个人说想好了,发起评审,基本最后都被改的面目全非,还不如初期就大家一起得出结论。

当然程序员是很「贱」的,你没叫他一起参与讨论的时候,他会抱怨说:“TMD,什么都不叫我,乱决策,现在乱的一坨屎,根本跑不通”,你叫他的时候,他又会说:“整天跟产品在一起讨论问题,技术上都没有长进,没有积累,或者又抱怨说,唉,每天白天跟产品讨论,只有晚上加班才能写点代码,累的像条狗,还总被人家说效率不高”。

程序员大多认为自己有些“武功”,跟不同的程序员交流要用不同的办法,例如多请他吃饭或按摩。

所谓能力越大,责任越大,明白的程序员早就想明白了,他每天的工作不是给他的老大干活,也不是给他的老板干活,每天其实都是在给自己干,无论在哪里干,都当是创业。

再说下需求文档中的「优先级」这个选项,也是令程序员很头疼的,优先级分为高、中、低三个选项,大多数产品经理会说,高的必须上线,中低优先级也是需要做的,那还分什么优先级呢?或者说中低选作,这种模棱两可的感觉不如抽象成,做或者不做,当然需要产品经理能力的提升,清晰评估出一个版本能否涵盖这么多的事情。

本站资源来自互联网,仅供学习,如有侵权,请通知删除,敬请谅解!
搜索建议:流程图  流程图词条  程序员  程序员词条  而是  而是词条  清晰  清晰词条  需求  需求词条