抖音上有很多程序员和产品经理的段子。说产品经理提的需求有多无理的，那只是段子而已。现在产品经理也是一种竞争很激烈的行业，如果有，那也做不长久。
说到底产品需求在前，开发在后。而需求是动态变化的，开发却是基于最开始的需求，所以确实会存在做完后，发现功能没用的情况。这种情况很大一个原因是软件是一个虚的东西，没做完之前，摸不着看不到的，所以就不一定是客户和用户需要的。这种解决方案就是短周期迭代开发，让一部分功能先上线验证。我见过的大部分企业，迭代周期都在1-2周。最高不超过4周。
至于另一种产品经理没思考好，等开发做了一半，来修改需求的。这种情况，需要开发和产品都提高理解需求的能力，对，开发也需要。因为说到底，软件做出来长啥样是程序员决定的（生产者）。只有理解了需求，才能做好需求。
越是排期长的版本，时间也越不可控。虽然大家都会做计划，但因为工作量是偏主观的，每个人的准确度并不一样。所以项目的整体工作量经常不准确。那如何解决这个问题？
1、每天的工作排期，除了正常的编码时间，还要考虑会议、电话以及其他相关活动时间。
2、不要计算工作量完成的百分比，而应该测算剩下多少工作量没完成。如果最初估计完成时间是40小时，而开发了30个小时之后，你认为还需要另外30个小时才能完成，那就如实说明情况，并调整计划。通过加班或者加快其他任务来解决。
3、为每次完成时间与真实的预估时间做一个对比，如果你评估2天，实际花费6天，那么两者系数为3，那么下次你评估的时候就乘以3。通过多次调整，就会趋于正常。特别是管理者要帮助下属建立正确评估工作的能力。
4、测试时间，大版本的测试时间会超过预期，主要还是测试出的问题太多。这需要在平常加强自测，比如使用单元测试之类的工具，辅助开发。另外就是达成共识，不是所有的测试问题都要修复，给bug分等级，等级低bug是可以放在下一个版本处理的。
5、最重要一点是，到底是时间不够，还是时间都被一些娱乐事物给使用了。反思自己的有效工作时间。
说到测试，现在的对bug的定义会更严格些。 每一个用户抱怨的点，都算bug。包括体验（操作上）。如果代码问题解决不了，可以考虑通过修改文档或者培训来弥补。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。