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

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

至于另一种产品经理没思考好，等开发做了一半
，来修改需求的。这种情况
，需要开发和产品都提高理解需求的能力，对

，开发也需要。因为说到底，软件做出来长啥样是程序员决定的（生产者）。只有理解了需求
，才能做好需求。

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

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

。那如何解决这个问题
？

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

2、不要计算工作量完成的百分比，而应该测算剩下多少工作量没完成。如果最初估计完成时间是40小时，而开发了30个小时之后
，你认为还需要另外30个小时才能完成
，那就如实说明情况，并调整计划。通过加班或者加快其他任务来解决。

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

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

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

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

说到测试

，现在的对bug的定义会更严格些。 每一个用户抱怨的点

，都算bug

。包括体验（操作上）

。如果代码问题解决不了，可以考虑通过修改文档或者培训来弥补
。