2019-01-02程序员的核心职责是如何实现产品功能，怎么实现功能；前提是理解产品功能，需要实现哪些功能。有些项目经理，产品经理与程序员角色混淆。你同他谈功能，他同你谈技术实现，你同他谈技术，他同你谈产品（需要实现哪些功能）作者回复: 你能分辨出你们讨论的不是一回事，这是很强的能力。其实，与任何角色沟通都一样，能够识别出双方讨论的不是一回事，及时制止，会大幅度提高沟通的效率。
20
2019-01-02我说两点感受
1.有不少开发，纯粹为了完成任务而完成任务，从来不考虑自己开发的功能到时候怎么用，开发完随便点点就提交测试了，我要是测试已经崩溃了😂
2.另外一个，遇到不专业的专职产品经理，给出的全是需求矩阵，两句话描述一个功能，开发的时候思考这些细节真是浪费时间 9
2019-01-03老师您好
一个产品经理没有想清楚需求的前提给我们开产品需求讲解会，每次就会造成开发和测试的轮番轰炸产品细节，产品经理的回答就是我下去再想想，第二次再开产品需求会的时候还会遇到新的产品细节，产品经理还会回答我下去再想想。看来这个产品经理就是没有定义好验收标准，只是想好了市场部提给他的需求。
那么问题了
1、“验收标准给出了这个需求最基本的测试用例，它保证了开发人员完成需求最基本的质量”
这个验收标准给的太基本还是会在后期开发中浪费时间，尽量的详尽很考验产品经理的职业素养以及时间成本，如何去衡量这个最基本的验收标准？
2、团队开发中需求变更在所难免的，产品变更需求如何同步给大家最有效，以及需求更变的痕迹如何可追踪。请问老师在团队开发对于这种问题有什么最佳实践，谢谢！展开作者回复: 这种现象可能有两种原因，一是产品经理没想清楚，二是问题复杂到产品经理想不清楚。实际上，这是一个问题，产品经理缺乏好的工作方式，他需要将产品特性做分解，分解一个个的小需求去实现。另外，变更不可怕，大变更才可怕。这其实是任务分解模块要讨论的内容，敬请期待。
8
2019-01-03请作者如果能顺便介绍一下每节课内容相关的国内当前行业现状，就像回复评论中的那样就好了。作者回复: 好建议，后面的内容我适当调整一下。
6- 2019-03-21听老师的案例有种感觉案例中产品经理不具备基本的需求方面的知识和技能。听到第四课，得出初步结论，10倍速程序员，最直接的方式是找一个有合格产品经理的团队，从业这么多年有个感觉就是，软件行业的工程师是最不像工程师的工程师。因为好多人不具备基本的工程知识和工程化的技能。甚至不具备软件工程的通识，门槛太低是个最大问题。一方面程序员们自认为是专业人士，另一方面确连基础知识都不愿去学。很难想象一个不懂乐理，不持续练习的乐手上台演奏，一个没上过医学院，没练过大量实习的医生去开刀，但程序员呢。说到底，老师讲的都该是一个自认为专业人士具备的基础知识，基本工作技能，基本沟通能力。
作者回复: 好的产品经理可遇不可求。所以，我们只能倒逼产品经理交出靠谱的答案。
IT 行业入门门槛还是低，时间还是短，专业的人太少了。 1 4 
2019-01-07就像老师文中提到的，产品只考虑正常逻辑，异常是不做考虑的，然后交付设计，设计也不会出异常页面的UI，开发补充的异常提示信息和异常界面又往往不是产品想要的，往往容易在验收的时候反复修改。而且有些细节问题往往是在做的过程中才发现的，这个时候做一点就去和产品确认一下又非常影响开发效率，老师有什么比较高效的方法吗？作者回复: 开发效率是什么？我反反复复强调地一个观点就是，开发效率不是写代码的效率。细节不确认就动手，后期还会反复，更浪费时间。
有些细节确实是只能在开发中发现的，所以，最好的办法是，让产品经理与开发团队坐在一起，随时确认。退而求其次，每天确认一次。 1 4
2019-01-04今日概念：
1. 开发功能列表：对开发标准做简易描述的列表，容易丢失信息；
2. 用户故事：用户故事是一种分析需求的方法，能将各个功能串联起来以便做场景化的思考。最重要的是它能确定验收标准，这将作为后续开发的准绳；
3. 验收标准：规定以终为始开发的结果，可以使用 DoD 来制定；
今日总结：
开发中的许多问题都是由于思考不够深入，沟通不够细致造成的，用户故事能将沟通中丢失的关键环节暴露出来，（切换角色至项目经理）走通用户故事之后再制定验收标准，这时我们的开发流程就变得可控了；展开 3
2019-01-03项目都快到截止日期了，心里总是没底。因为开发，项目负责人，产品经理，测试工程师。。。都是自己。看完此篇才知道验收标准如此重要。现在的情况是没有明确的验收标准，，，怎么做才是最好？作者回复: 先有验收标准，按照自己的理解，怎么有助于提高怎么来。
1 3
2019-01-02在华为，我们部门是没有产品岗位的，需求是se传递给开发人员的，se大多也是从开发升级上去的，所以需求看起来还算“顺畅”，拿到需求，就要先看，然后拉上se和测试，让se再给我们介绍一遍，解决开发和测试的疑问，这个环境是公司要求不能少的，所以都搞清楚再开始各自的工作，最后才能无缝连接起来 3- 2019-01-04产品经理太强势，需求总是列出几个功能点，用户故事和验收标准完全说不清楚，每次需求评审耗费大量时间讨论，结果功能做出来了，又说不是产品经理需要的，由此可见推动制定验收标准是何等重要
作者回复: 每个人都需要考虑一下，令自己信服的到底是态度，还是道理。做出的东西不是需要的，需要怎么让它变成需要的呢？不去面对这个问题，问题永远解决不了。
2 
2019-01-02打卡
开始之前就定义好验收标准编辑回复: 打卡的方式挺好的，加油💪
2
2019-01-02突然觉得，这个东西很适合产品看啊。。。作者回复: 欢迎把文章转发给你们的产品同事！
2
2019-04-16产品经理没有完整的产品思路，只有一个大概的功能点，项目经理只谈开发功能的必要性 给不了技术支持，烦躁。。作者回复: 把事情做细，让他们把需求分解好，别替其他人填坑。
1
2019-03-19在做任何任务和需求之前，先定好验收标准
验收标准包括：正常流程、异常流程
在确定验收标准中，最好用“用户故事”来定义，且站在项目模块的角度来看待需求。
这样在分析需求和“用户故事“中，可以更完整地看问题。 1
2019-01-23郑老师有个疑问，我厂没有这种流程，大家都是以交互稿为验收标准，虽然有时候交互会漏一些异常情况，但是这不是这种形式本身的问题，补上就行了。
交互稿还有个好处就是更直观，前后端都可以使用。
最后验收的时候一般不会出现大的偏差，小的偏差通过产品交互视觉运营走查就能解决。
这两种形式有什么优劣吗？还有您的公司前端程序员也是用用户故事来做参考吗？作者回复: 交互稿只是需求交付的一部分，不是全部，中间的的缺失是靠你们团队的通力协作解决的，你们的方法在你们特定的上下文可以起作用，但很难作为通用的实践推广。
用户故事与前端还是后端没有关系，关注的是业务价值。 1
2019-01-03产品经理往往考虑不到很多异常情况，因为很多产品没有技术背景。作为项目经理，后续我应该承担起这部分工作的责任。第一划清需求边界，避免天马行空的讨论。第二着重考虑异常流程。第三定义验收标准，然后转交给测试。 最后真心希望作者能给出国内大公司的一个开发流程和一些工具（比如腾讯的tapd就不错），这样能让很多小公司的人员也能学习大公司的先进管理模式。不胜感激。作者回复: 其实，国内很多公司在软件开发过程上做得并不是特别优秀，甚至有一些添麻烦的做法，而且，往往是在一个特定场景下适用的。倒是一些产品开发的过程，确实有做得不错的。在软件开发这件事上，行业里的最佳实践几乎都是公开信息，学习这些最佳实践比学习所谓大公司的做法要来得容易，因为这些实践是在很多地方验证过的。
1
2019-01-02【需求不清晰】带给我最大的问题就是 经常返工！不光是需求上面，在领导分配的任务（也算是需求吧）上面理解出现偏差，最终做出来的东西不符合领导要求，这和上一篇的 DoD 有共同的地方，什么是完成？什么是验收标准？经历过，踩过坑 才知道【以终为始】的重要性！ 1
2019-01-02请问郑老师，在以往的项目经验中，对测试驱动开发TDD怎么看？从逻辑上，根据已有的DoD或验收list, 是可以先写测试用例的。BDD的定义也可以比较容易的转化为测试用例。这样的流程更贴近于以终为始的概念，只是有些反常规，毕竟程序员的意识里最直接就是写功能。请问在ThoughtWorks 或国内大厂TDD和BDD的使用如何，有没有好的项目实例或一些坑可以避免？作者回复: 后面会专门讲到TDD和BDD。国内的团队大多停留在能写测试就不错了的阶段，好一点的公司，对测试覆盖率有要求。很多人对于测试的理解有误，这是后面会讲到的。
1
2019-12-25说个刚在我身上发生的事儿，我在做一个数据采集页面，产品的设计图上有些选项只有添加没有删除，我当时意识到这个问题，但是没有反馈给产品就直接开始做了。想着需求定义是产品的事儿，我帮他梳理清楚也增加我的工作量，结果是我做完后提交测试的时候告诉我这些功能还要加上，没办法，我需要二次开发，调整我的代码加入新的功能。
2019-10-30笔记
1 故事描述。快速以窥全貌，理解用户关键需求。
2 检查清单，非常的重要。
小公司场景下，程序员自己写检查清单。
有趣的话，没有代码的代码最好维护。
一些想法
还是那句话，事物有两面，容易变成相互推诿，所以找对合作伙伴很重要。展开