作为一名程序员,你真的理解需求吗

一、作为一名程序员,你真的理解需求吗

1、作为一个程序员，最重要的职责就是：按时保质保量地完成需求开发。

2、像开发新业务这样的复杂需求， PM（Product Manager，产品经理）一般会写出详细的 PRD（Product Requirement Document，产品需求文档），甚至可能会制作高保真原型。

3、而像调换两个按钮顺序这样的简单需求，PM有可能只会口头通知一下，最多在JIRA之类的项目管理平台上创建一条只有标题的ISSUE。

4、如果是有和用户交互的需求，负责设计的部门或人员一般会提供设计图。专业一点的话还会帮你把图都裁好，并准备不同屏幕分辨率下使用的多个尺寸版本。

5、当然，如果你在一个刚刚成立的创业公司，很有可能是创始人在白板前（或者是饭桌上）讲了半个小时，然后就问你：“需要多长时间把它做出来？”

6、不管提出需求的是PM还是创始人，他们的脑海中一定为这个需求设想好了一个自洽的逻辑和形态。PRD也好，口头宣讲也罢，都是在描述这个逻辑和形态。他们提出需求，就是希望程序员能够最大程度地还原他们的设想。

7、说起来简单，做起来难。我们可以通过一个小实验来揭示这一点。

8、首先，你需要找一张长方形的纸。如果你在办公室，那就找一张A4纸；如果你在家，那就找一张纸巾。然后按照下面的步骤进行操作：

9、你的作品是什么样子？中间开洞了吗？边上呢？角上呢？如果再做一次，你能完成同样的作品吗？

10、你可以拿着同样的纸去找你的家人、同事或朋友，请他们来完成同样的操作。在你不施加影响的前提下，他们完成的作品极有可能和你截然不同。

11、如果你仔细观察他们操作的过程，就会发现：

12、由于每次对折都会可能产生两种不同结果，在撕第一个角时纸的朝向有四种可能性，旋转180度时有两种可能。所以仅仅两个撕角的位置，就至少有 2 x 2 x 4 x 2= 32种不同的可能性。

13、就这样，我们还没有考虑撕角的大小、角度的区别，还有极少数人是会沿对角线对折的……

14、上面撕纸的需求，其实是我自己拿了张纸随意摆弄，然后记录下来的操作流程。我照着这个流程，可以十分轻松地做出完全相同的作品。但是如果让别人来做，结果就完全不一样。其原因就是，我在完成作品的过程中，不光是按照流程进行操作，还隐含了自己的一些小习惯，却并没有把这些细节记录下来。

15、如果把所有细节都完整地记录下来的话，需求应该是这样的：

16、同样，PM在写PRD时，很有可能会漏掉一些自己认为应该是「常识」，无需再进一步说明的内容。比如「把一张纸对折」，我们很容易想当然地认为，应该是沿着长边对折，但事实上并非所有人都是这么理解「对折」的。

17、由于每个人的成长经历不同，其认知结构之间必然存在差异，因此对同一概念未必持有相同的理解。你所认为的「常识」，我可能并不知道，或者拥有和你截然不同的理解。所以程序员在看PRD时，一定要把自己对需求的理解复述出来，跟PM确定是不是这么回事。否则就容易出现开发中、提测甚至上线后发现逻辑性错误，需要紧急修复甚至返工的情况。

18、此外，很多问题在设想阶段是发现不了的，只有到了具体实施时才会暴露出来。 PRD不可能真正做到完备，也不能保证没有错误和遗漏。比如一个表单需求，很可能在做的过程中发现某个非法数据case是PRD里没考虑到的，这时的用户交互怎么做？文案怎么定？这都要和PM沟通来解决，而不能自己拍脑门决定。

19、 PRD只是需求的一个快照性描述文档，并不是需求本身。程序员应该对需求负责，而不是对文档负责。只有和PM保持沟通，不断地细化需求，才能让需求真正落地。当发现PRD里有不合理或者有疑问的地方时，一定要提出来让PM进行解释。千万别视若无睹，甚至干脆将错就错，等着看PM笑话。

20、如果我们拿到了一份图文并茂、十分详尽的PRD，是不是应该马上照着文档开工呢？那可不一定。

21、一位优秀的程序员，应该在开工之前把下面这些问题想清楚：

22、程序员有责任对需求方案进行review，并协助PM改进设计。要知道，PM一般不会从技术角度对需求进行考虑，所以往往提出的并非最优方案。有时只要做一点点调整，技术实现的难度就会大大降低，却不影响目标的达成效果。

23、比如某个业务需要用到日期选择器组件，PM为此专门设计了一个，而你知道系统中某个功能页面里有现成可用的同类组件。这时就应该和PM沟通是否可以直接复用，或者在原有组件的基础上进行功能扩展。这样既节省了开发资源，又保持了用户体验的一致。

24、程序员要对整个产品的可用性负责，全面评估需求可能导致的不良影响，谨慎对待有破坏性的需求。 PM由于不了解系统的底层实现和实际数据的组织方式，所以很可能无法全面地评估需求的影响面。如果程序员忽视在这方面的思考，只是机械地按部就班地执行方案，就很可能导致严重的线上事故。

25、比如要对某数据进行批量修改，在做的过程中时发现该数据有多个业务正在使用。这时就应该必须停下来和PM沟通，因为PM可能只了解自己负责的那一块业务，不知道修改可能会对其他业务产生影响。此类需求要和相关各方沟通协商，确认修改没有不良影响后才能继续。

26、程序员要有魄力去拒绝那些明显不靠谱的需求。有的时候，PM提出需求的动机不是为用户创造更多的价值或提升用户体验，而是为了冲绩效完成自己的KPI。为此拆东墙补西墙，从兄弟业务手里抢流量入口；甚至杀鸡取卵，以严重破坏用户体验的方式拉量。遇到这种事，程序员一定要坚持自己的原则，守住自己的底线。

二、程序员喜欢什么样的需求文档

1、程序员实际上并不需要这个文本的需求供认书，程序员喜欢“图片”，文档的文本应该是产品学生在脑子里思考，而不应该直接把这个想法描述成文字。

2、程序员需要的是一个清晰的交互图,在关键位置的交互图显示,有一些边界条件,交互图不需要使用乱七八糟工具输出,一张纸和铅笔描述清晰,但恢复需求描述的所有元素就可以了,虽然没有UI设计,但程序员可以开始开发演示。

3、一、产品介绍和行业简介。首先，给程序员简单介绍一下产品的价值，比如产品的作用，产品可以提供的服务，以及产品相对于竞争对手的优势。还要介绍产品的目标用户和使用场景。第二点是简要说明行业的现状，未来的趋势是什么，同行业竞争对手的情况如何?

4、二是产品的介绍。第一，实体关系图很重要。当您将产品从0变成1时，为了使数据库开发人员更快地了解您的产品，实体关系图(e-r图)将发挥很大的作用，数据库开发人员可以参考图来做数据表结构设计。

5、第二是用户角色表的访问。当涉及到角色和权限时，需要一个全面的角色权限表单来促进开发人员的参考。第三是业务流程图。通过业务流程流程图，可以从总体方向了解产品的整体逻辑，通过拆卸业务流程流程图得到流程流程图。

6、三是各种细节问题。产品的要求、功能和交互指示。写功能描述，交互说明，不能漏掉一些细节，导致逻辑不严谨。可以从以下几个方面来考虑，它会让你更全面地思考:字段，字段描述，数据源；先决条件，排序机制，刷新机制；状态流(页面可能有多个状态，需要解释)；交互操作(正常操作，异常操作)

三、想做程序员,要些什么条件

1、程序员意味着要编程序。（如果你仅仅想得到一份高薪水的工作，喝喝咖啡就等老板发薪水，我奉劝你还是另找一份更合适的工作，譬如练摊，真的，兄弟，这份工作不适合你）

2、你是学文的还是学理的，编程序也许需要浪漫，但更需要逻辑和严谨。（说坦白点就是，在你没有找到乐趣以前，它很枯燥）

3、你有对新技术追求的热情吗？你有刨根问底的探索精神吗？（热情绝对是最重要的！你仔细思考一下自己的性格适合当程序员吗？）

4、当程序员决不是什么好差事，时刻需要学习，需要思考。（直到你成为那个可以引导别人去学习和思考的人，你才可以偷偷的嘿嘿笑，又一群傻蛋）

5、程序员的未来很迷茫。（但我认为关键看你自己！我希望你是一个有追求的人，不仅仅是混碗饭吃。因为真正的乐趣在于创造；如果你能改变软件业的历史，那才是英雄；不想成为Bill Gates，不想成为Dennis Ritchie和 Bjarne Stroustrup，我会说你没有追求。有个关于程序员未来的笑话，也许你还没听过，你该听一听，摘抄如下：

一个程序员对自己的未来很迷茫，于是去问上帝。

“万能的上帝呀，请你告诉我，我的未来会怎样？”

上帝说“我的孩子，你去问Lippman，他现在领导的程序员的队伍可能是地球上最大的”

Lippman说“程序员的未来就是驾驭程序员”

这个程序员对这个未来不满意，于是他又去问上帝。

“万能的上帝呀，请你告诉我，我的未来会怎样？”

上帝说“我的孩子，你去问Gates，他现在所拥有的财产可能是地球上最多的”

Gates说“程序员的未来就是榨取程序员”

这个程序员对这个未来不满意，于是他又去问上帝。

“万能的上帝呀，请你告诉我，我的未来会怎样？”

上帝说“我的孩子，你去问侯捷，他写的计算机书的读者可能是地球上最多的”

侯捷说“程序员的未来就是诱惑程序员”

这个程序员对这个未来不满意，于是他又去问上帝。

“万能的上帝呀，请你告诉我，我的未来会怎样？”

上帝摇摇头“唉，我的孩子，你还是别当程序员了”）

6、当程序员还是很有乐趣的。（当你学到新知识时，当你有新的思想见解时，当你有新的产品问世时，和知己探讨你的成果时…我问你，觉得这些是乐趣吗？）

7、当程序员不易也不难。（世间事有难易乎？为之…；不为…。你有决心和信心吗？）

8、你真的要当程序员？是你自己的想法？

9、你舍得花钱买书吗？（读好书绝对是学习编程的最佳捷径。你一定会说，现在电脑书籍真他XX的贵，没法子，谁让知识和技术在人家的脑袋，在人家的书里呢；等你写书时可以把价格定低一点，记着还有好多没钱但想买书的兄弟很困难呀。要舍得买书，买好书，不好的的书不如不读，其害大于其益，关于买什么书，你可以问高手或看候捷的书评；准备一个小本子记录你想买的书的名字，逛书店时看看，如果好就买下，记住要读，别光买不看。） 10、我告诉你，程序就是：任何有目的的、预想好的动作序列，它是一种软件。

12、你想好了吗？（如果你想好了还是决定要当程序员，可以继续往下读；否则，你可以继续寻找别的出路了。）