抖音上有很多程序员和产品经理的段子。说产品经理提的需求有多无理的，那只是段子而已。现在产品经理也是一种竞争很激烈的行业，如果有，那也做不长久
。

说到底产品需求在前
，开发在后
。而需求是动态变化的
，开发却是基于最开始的需求，所以确实会存在做完后，发现功能没用的情况。这种情况很大一个原因是软件是一个虚的东西，没做完之前，摸不着看不到的
，所以就不一定是客户和用户需要的。这种解决方案就是短周期迭代开发，让一部分功能先上线验证
。我见过的大部分企业，迭代周期都在1-2周
。最高不超过4周
。

至于另一种产品经理没思考好，等开发做了一半，来修改需求的
。这种情况，需要开发和产品都提高理解需求的能力，对，开发也需要
。因为说到底，软件做出来长啥样是程序员决定的（生产者）
。只有理解了需求
，才能做好需求。

越是排期长的版本，时间也越不可控

。虽然大家都会做计划，但因为工作量是偏主观的，每个人的准确度并不一样。所以项目的整体工作量经常不准确。那如何解决这个问题
？

1
、每天的工作排期，除了正常的编码时间，还要考虑会议
、电话以及其他相关活动时间。

2、不要计算工作量完成的百分比，而应该测算剩下多少工作量没完成
。如果最初估计完成时间是40小时
，而开发了30个小时之后

，你认为还需要另外30个小时才能完成，那就如实说明情况，并调整计划。通过加班或者加快其他任务来解决
。

3、为每次完成时间与真实的预估时间做一个对比，如果你评估2天，实际花费6天，那么两者系数为3

，那么下次你评估的时候就乘以3。通过多次调整，就会趋于正常。特别是管理者要帮助下属建立正确评估工作的能力。

4
、测试时间，大版本的测试时间会超过预期，主要还是测试出的问题太多。这需要在平常加强自测
，比如使用单元测试之类的工具，辅助开发。另外就是达成共识
，不是所有的测试问题都要修复，给bug分等级，等级低bug是可以放在下一个版本处理的。

5
、最重要一点是，到底是时间不够
，还是时间都被一些娱乐事物给使用了。反思自己的有效工作时间。

说到测试，现在的对bug的定义会更严格些
。 每一个用户抱怨的点，都算bug
。包括体验（操作上）。如果代码问题解决不了
，可以考虑通过修改文档或者培训来弥补
。