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