白癜风早期症状 http://m.39.net/pf/a_4721404.html做为一只程序员，什么人会让你很无奈，最终哭笑不得，除了老板和客户外，相信大部分人的答案是产品经理，而由于老板或客户的需求，最终还会让产品团队去实现，所有的问题还是会出现在他们这个团队上。
希望能尊重下程序员
知道不知道，你改一个需求，只需要五分钟，而程序员可能要几天时间来实现，而当给你实现需求时，你又让改回来，说是还是以前的好，你就不能在原型上直接看下效果么？
这是最不尊重程序员的行为之一，盖楼你要重新盖，成本是看得见的，混凝土，一砖一瓦都需要钱，而改需求，成本是程序员为你掏的，加班，重新做架构，重新规划，重写页面，重新测试，这些都是五分钟改需求后，程序员面临的。
所以，如果你真的有能力的话，请改完之后就不要再改回来，请在原型或UI图上直接把效果看好了，定下。
如果有哪天，程序员发火了，请第一时间反思下自己是不是需求改的太频繁了。
改需求就必须延长时间
很多时间，程序员和产品之间的矛盾来自于时间的控制，在已经压缩时间的情况下，还在不断的改需求，是矛盾的最主要原因。
不信，你试试改完需求，延长项目时间，看看还会不会出问题了。
希望能主动担责任，分清谁的锅
按照岗位职责划分，程序员是在规定的时间内把相应的原型具体实现，而产品是把客户想要的，做出一个效果模型来，需求改来改去，项目时间还不延长，这是产品失职啊，请不要把这个锅甩给程序员，他们没有义务来替别人背锅。
希望能适当用程序的思维去思考问题
有些功能，在纸上用几笔就可以改完，换成程序去实现，或许就成为不可能实现的系统，最终重写底层。
还有没有重写底层的，是之前待的公司，另一个团队，本来系统架构，由于赶时间，和业务的不熟悉，架构对未来的业务扩展支持很差，又加了一个非常大的项目，打算两个月内做完。
为了完工，打时间战，就在原来的架构上继续写的功能，结果嘛，9个月还没做完，投资人不干了，坚决不投了，整个项目组解散。
当然这个例子并不是产品的锅，只是用来说明一下前期需求的确定，是多么的重要。
不管是开发还是销售，在需求分析占的比重都是非常大的，记得最早的时候是系统分析员做的工作，十年前考软件设计师的时候，那时候流程还是，程序员到软件设计师，软件设计师再到系统分析员，只有系统分析员可以接触到业务需求，制定需求分析。
也就是说，必须要有程序的底子做基础才可以，不仅仅要会编程，还要会系统架构，不知从什么时候开始，做产品做需求，不再需要这样的背景和技术支持，导致现在的产品和开发团队问题的出现。
下一节中，将讨论，系统分析员和产品经理做产品需求时思考方式的不同，会最终给开发团队带来什么样的结果，从开发角度上看如何才能做好产品，欢迎
