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

23 评论 45485 浏览 164 收藏 5 分钟

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

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

1

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

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

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

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

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

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

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

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

转回到正题,程序员其实不需要任何需求文档,只需要一份清晰的流程图即可。

#专栏作家#

给产品经理讲技术,微信公众号(pm_teacher),人人都是产品经理专栏作家。资深程序猿,专注客户端开发若干年,对前端、后台技术略懂,热衷于对新的科技领域的探索。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 真的是产品经理不写需求文档就等于给自己挖坑

    回复
  2. 原型图和交互说明规则这些,不都是PRD的一个子模块么。。。

    来自北京 回复
  3. 感觉纯属瞎扯,作为一个刚入行不到半年的产品新人,表示第一次给研发澄清需求的时候就没有prd,就是照着原型图和流程图澄清的,然后转测试,测试没有需求文档一脸懵逼的来问我。
    需求文档还是必须的,当然图也是必不可少的

    来自江苏 回复
  4. 毫无营养的文章

    来自天津 回复
  5. 对于我们的产品来说,这张配图的需求文档已经很是高端大气上档次了

    来自北京 回复
  6. 等什么时候程序员写出的程序别漏洞百出再来要求别人吧,拿着公司最高的工资

    来自浙江 回复
    1. 功能做出来有差池,产品和技术都有责任。毕竟双方沟通没有畅通,产品没有跟进好,技术也是没有仔细去想这件事。所以说双方态度端正,对事不对人才能高效的解决问题,且极大的降低BUG出现的可能。

      来自北京 回复
  7. 产品要想清楚产品的框架,需要细化确认的东西要归纳起来,等整理妥当后才好去组织产品、研发、运营一起讨论,这样才能提高开发效率,产品人需要起到跨部门协调的作用

    回复
    1. 是的,同意。

      来自北京 回复
  8. 那个是恶心的,毋容置疑。但是文档还是有必要的啊,团队可不是只有产品和程序猿的。

    来自广东 回复
  9. 说到底,总感觉少点什么!题主,是不是放几个心仪的草图或流程图好一点。😁

    回复
  10. 你说的这种文档,失败之处在于,没有配上原型图,读者看着这些文字描述还要在脑海中YY出大致是什么样子,我想没谁有这个耐心读下去,从到导致这种撕逼;说到底,还是产品文档的问题,文档就是产品,读者就是用户;个人认为最好的产品文档必备:清晰中低保真原型图、精简无漏洞文字说明、必要的流程图;具备这三要素,就没那么多撕逼大战了。。。

    来自广东 回复
  11. 那么清晰的流程图长啥样

    来自四川 回复
  12. 你都说大家喜欢看的是图,为何就晒一个你觉得恶心的,请列举一个你认为最适合给团队之间递交互动的【要还原出需求所描述的所有元素,的一张草纸加铅笔描述清晰的流程图】,给大家伙学习学习。

    来自福建 回复
    1. 你说的太对了,只给反面教材,读者不会有太大收获

      回复
  13. 我只想问:没有这样讲清楚的文档那测试怎么办?运维怎么办?如果开发中产生交互等方面的偏离怎么办?交付时需要返工怎么办?这会产生多少成本?按文章中分享举例,如果不写清楚每个部分的结果是分享成功后没有提示,分享内容的简介可能是程序员生硬的话语,最后根本出不来做这项功能想要实现的目的。很多功能要实现的不仅仅是功能,重要的是这个功能对于整体的运营要实现的东西,分享要实现的是可以让更多的人看到并点击分享的东西,并不是进行有个功能就可以,这些程序员是想不到的。你这文章说的仅仅适用于10人以下的创业小团队而已,并不适合一个成熟的公司一个成熟的产品。没有喷的意思。。就是自己的看法,因为没有你说的这些所谓恶心的文档我已经撕逼多少次了,运营、测试、需求方都不知道会骂我多少次。。你说的改多少次文档,最后文档好了,但是时间很长了这种情况只能说明这个PM水平问题,反正我做的需求文档最多改不了3次,而且第一次的时候基本已经确定下来,基本可以开始出图了。。

    来自河北 回复
  14. 哎呀,这个东西好烦呀不要看了吧,讲清楚不就好了嘛,呵呵

    来自北京 回复
  15. 明显是只从程序员角度看问题,没考虑到其他成员还有资料传承问题

    来自广东 回复
  16. 一本正经的胡说八道

    回复
  17. 都不知道说的是啥,一本正经的胡说八道+

    来自广东 回复
  18. 一个墨刀搞掂

    回复
  19. 一本正经的胡说八道+1,这种文档是要有的,主要是呈现方式,你举得例子全是文字,肯定谁看谁头痛,做成图、文、流程结合

    来自广东 回复
  20. 文档不只是给程序员看的,还要给测试人员,后来的产品维护者看的。没有这些,开发过程的风险很大,维护的成本很高

    回复