04 | 接到需求任务，你要先做哪件事？

郑晔

你好，我是郑晔。
我们书接上文，继续讲程序员小李的故事。这次小李接到一个新的需求，让他开发一个单点登录的服务，经过几天的奋战，他顺利地写完了所有的代码。正好产品经理小王路过他身边，顺便问了他一下。
小王：单点登录做得咋样了？
小李：做完了，我给你演示一下。
小李演示了一遍自己做的功能，小王看上去很满意。
小王：不错。不过，怎么没有支持验证码？
小李：为什么要做这个？
小王：这不就是登录的一部分吗？
小李：哪里规定要做验证码了？
小王：现在做登录哪有不用验证码的？
我想你已经嗅到了双方谈话的火药味，这个时候如果双方都不能很好地控制自己的情绪，那接下来一场体力的较量可能就一触即发了。
为什么双方会有这么大的分歧呢？其中一个重要的原因是，开始实现这个需求之前，任务双方都没有清晰地定义好边界，没能把需求描述清楚。
需求描述的问题在软件开发中，程序员做什么一般都由需求来定义。我们都知道，需求是软件开发的一个重要组成部分，但你可能并没有仔细想过，不同的需求描述方式，可能会影响我们程序员对需求的理解。
因为信息的传递是会衰减的，你不可能把你理解的信息 100% 传递给另外一个人，而这中间，如何传递，也就是如何描述将直接决定衰减的比例。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《10x 程序员工作法》，新⼈⾸单¥68

立即购买

登录后留言

全部留言(75)

最新
精选

liu
程序员的核心职责是如何实现产品功能，怎么实现功能；前提是理解产品功能，需要实现哪些功能。有些项目经理，产品经理与程序员角色混淆。你同他谈功能，他同你谈技术实现，你同他谈技术，他同你谈产品（需要实现哪些功能）
作者回复: 你能分辨出你们讨论的不是一回事，这是很强的能力。其实，与任何角色沟通都一样，能够识别出双方讨论的不是一回事，及时制止，会大幅度提高沟通的效率。
2
62
彩色的沙漠
老师您好一个产品经理没有想清楚需求的前提给我们开产品需求讲解会，每次就会造成开发和测试的轮番轰炸产品细节，产品经理的回答就是我下去再想想，第二次再开产品需求会的时候还会遇到新的产品细节，产品经理还会回答我下去再想想。看来这个产品经理就是没有定义好验收标准，只是想好了市场部提给他的需求。那么问题了 1、“验收标准给出了这个需求最基本的测试用例，它保证了开发人员完成需求最基本的质量” 这个验收标准给的太基本还是会在后期开发中浪费时间，尽量的详尽很考验产品经理的职业素养以及时间成本，如何去衡量这个最基本的验收标准？ 2、团队开发中需求变更在所难免的，产品变更需求如何同步给大家最有效，以及需求更变的痕迹如何可追踪。请问老师在团队开发对于这种问题有什么最佳实践，谢谢！
作者回复: 这种现象可能有两种原因，一是产品经理没想清楚，二是问题复杂到产品经理想不清楚。实际上，这是一个问题，产品经理缺乏好的工作方式，他需要将产品特性做分解，分解一个个的小需求去实现。另外，变更不可怕，大变更才可怕。这其实是任务分解模块要讨论的内容，敬请期待。

29
Xunqf
就像老师文中提到的，产品只考虑正常逻辑，异常是不做考虑的，然后交付设计，设计也不会出异常页面的UI，开发补充的异常提示信息和异常界面又往往不是产品想要的，往往容易在验收的时候反复修改。而且有些细节问题往往是在做的过程中才发现的，这个时候做一点就去和产品确认一下又非常影响开发效率，老师有什么比较高效的方法吗？
作者回复: 开发效率是什么？我反反复复强调地一个观点就是，开发效率不是写代码的效率。细节不确认就动手，后期还会反复，更浪费时间。有些细节确实是只能在开发中发现的，所以，最好的办法是，让产品经理与开发团队坐在一起，随时确认。退而求其次，每天确认一次。
5
23
Geek_fe0336
听老师的案例有种感觉案例中产品经理不具备基本的需求方面的知识和技能。听到第四课，得出初步结论，10倍速程序员，最直接的方式是找一个有合格产品经理的团队，从业这么多年有个感觉就是，软件行业的工程师是最不像工程师的工程师。因为好多人不具备基本的工程知识和工程化的技能。甚至不具备软件工程的通识，门槛太低是个最大问题。一方面程序员们自认为是专业人士，另一方面确连基础知识都不愿去学。很难想象一个不懂乐理，不持续练习的乐手上台演奏，一个没上过医学院，没练过大量实习的医生去开刀，但程序员呢。说到底，老师讲的都该是一个自认为专业人士具备的基础知识，基本工作技能，基本沟通能力。
作者回复: 好的产品经理可遇不可求。所以，我们只能倒逼产品经理交出靠谱的答案。 IT 行业入门门槛还是低，时间还是短，专业的人太少了。
6
18
davidce
请作者如果能顺便介绍一下每节课内容相关的国内当前行业现状，就像回复评论中的那样就好了。
作者回复: 好建议，后面的内容我适当调整一下。

16
Monday
项目都快到截止日期了，心里总是没底。因为开发，项目负责人，产品经理，测试工程师。。。都是自己。看完此篇才知道验收标准如此重要。现在的情况是没有明确的验收标准，，，怎么做才是最好？
作者回复: 先有验收标准，按照自己的理解，怎么有助于提高怎么来。
2
9
大帅哥
产品经理太强势，需求总是列出几个功能点，用户故事和验收标准完全说不清楚，每次需求评审耗费大量时间讨论，结果功能做出来了，又说不是产品经理需要的，由此可见推动制定验收标准是何等重要
作者回复: 每个人都需要考虑一下，令自己信服的到底是态度，还是道理。做出的东西不是需要的，需要怎么让它变成需要的呢？不去面对这个问题，问题永远解决不了。

7
Calios
不禁想到Simon Sinek的ted：How great leaders inspire action. 从why出发，总是从why出发～
作者回复: 想要成为高手，就要知道来龙去脉。

6
索旭东
最好维护的代码，是还未写出的代码
作者回复: 不写代码解决问题是本事。

6
一直都在
说个刚在我身上发生的事儿，我在做一个数据采集页面，产品的设计图上有些选项只有添加没有删除，我当时意识到这个问题，但是没有反馈给产品就直接开始做了。想着需求定义是产品的事儿，我帮他梳理清楚也增加我的工作量，结果是我做完后提交测试的时候告诉我这些功能还要加上，没办法，我需要二次开发，调整我的代码加入新的功能。
作者回复: 论多说一句话的重要性

6

收起评论