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

说到底产品需求在前，开发在后

。而需求是动态变化的
，开发却是基于最开始的需求，所以确实会存在做完后
，发现功能没用的情况。这种情况很大一个原因是软件是一个虚的东西
，没做完之前，摸不着看不到的
，所以就不一定是客户和用户需要的

。这种解决方案就是短周期迭代开发，让一部分功能先上线验证。我见过的大部分企业
，迭代周期都在1-2周
。最高不超过4周。

至于另一种产品经理没思考好
，等开发做了一半，来修改需求的

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

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

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

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

3、为每次完成时间与真实的预估时间做一个对比
，如果你评估2天，实际花费6天，那么两者系数为3
，那么下次你评估的时候就乘以3。通过多次调整
，就会趋于正常
。特别是管理者要帮助下属建立正确评估工作的能力
。

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

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

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

，都算bug。包括体验（操作上）
。如果代码问题解决不了
，可以考虑通过修改文档或者培训来弥补。