效率底下的原因--项目管理者说
一、需求阶段1、产品也不知道自己想要的是什么2、产品即使知道自己想要的是什么，也没法给出具体的业务细节，如用户输入应该限制在多少位，是否进行存在性或唯一性校验等。3、即使产品知道自己想要的，也知道业务细节，但是也没法跟开发人员衔接上，往往都是会有误差。4、即使有幸，产品跟技术衔接上了，也很难在以后能记住这些当时的共识。5、即使为了防止以后的遗忘，增加了文档说明，也难以保证文档能够记录的准确，想起我的第一个Boss说的话：一句中国话，100个人都100个人的理解。?二、开发阶段1、只有Team Leader自己知道产品想要的是什么，手底下的兄弟们并不知道2、即使通过分析需求，讲解需求，让兄弟们了解了需求，每个人也只是最关心自己负责的系统以及周边的模块3、即使让大家知道我们的目标是什么，也难以保证在每天的项目推进中，每个人的开发方向不会跑偏。4、即使是通过站会的形式让大家知道当前的进度并调整方向，也难以保证大家的理解都是一致的。5、即使大家的理解是一致的，并且通过规范模块间的接口，也难以保证每个人的代码不是偶在重复造轮子6、即使是每次使用到的轮子，将杂质尽可能去除了，只剩下一个最小公因子模块，也往往是因为不符合case场景被忽略。?三、集成阶段1、经常经历的事情是第一轮的集成实际上就是各个模块的单元测试。2、即使单元测试通过了，也会因为接口职责的不清晰，导致了功能的缺失。3、即使是经过几轮的集成测试，把职责划清了，理顺了，也会因为部署环境的问题导致时间损耗。?四、发布阶段1、发布当天往往是跟过年一样，有的人激情澎湃，有的人心惊胆战。2、往往会因为生产环境跟测试环境不一致，导致发布失败。3、即使环境一致了，也会因为配置参数不一致导致发布失败。4、即使配置参数一致了，也会因为依赖系统跟测试环境不一致，导致出现一些莫名其妙的Bug5、即使是发布成功了，没有什么异常，也会在运行几天后，出现一些发布当前没有覆盖到的bug，比如说第三方调用失败。?五、迭代过程1、如果是产品第一次发布，那么恭喜你，你很幸运，第一次做想怎么做就怎么做，能实现功能就行。2、即使不是第一次发布，如果从第一次发布到现在这次迭代发布都是你参与过的，那么也恭喜你，你也很幸运。3、如果你是半路杀出来的程咬金，开始接收这次发布，那么我也恭喜你，你中奖了。4、半路接手的系统，甭管交接工作做的怎么到位，都不会细致到每一句代码的处理逻辑，特别是条件表达式判断的逻辑。5、经常是你觉得你按照新的需求修改了代码，进行了版本更新，却不行踩到了另外一个雷。6、如果这个雷是在发布的时候，或者发布之前爆炸，那么你也很幸运，你还有能力捂住这个雷。7、如果你以为你这次版本迭代是成功的，美滋滋的准备等待老板的奖励时，却等来了老板的电话：系统被领导发现Bug了。结果你查了半天，才查到问题原因是你踩了一个雷，那么恭喜你，你躺枪了。
都是实际问题！ 需要从管理和技术两方面共同发力才能解决。
都是实际问题！ 需要从管理和技术两方面共同发力才能解决。
嗯，本来是再想怎么尽可能提高效率的，所以就想先罗列一下拖我们效率后退的原因，越罗列就觉得应该分别从管理和技术两个方面来考虑。下一步再罗列一下我能想到的应对思路，大概的方向还是ci的
这些问题也是困扰我时间比较久的，解决问题比提出问题更难，对于如何解决，我现在也没有一个好的方案，那些学院派的东西，也不想拿来做哗众取宠。还是想来点干货，不要大帽子，就要解决问题的方案，哪怕是野路子都行。欢迎一起讨论
