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