在京东我们是怎么做版本迭代的

一个项目的完整生命周期包括以下几点，想法提出、竞品分析、调研、产品内部沟通确定、依赖解决、需求预审、技术方案初步确定、需求正式评审、技术方案正式评审、开发实现、代码评审、提给测试人员测试、部署上线、产品走查等。

上述是理想化的流程，实际工作中难免有临时性、突发性问题要解决，但是需求截止时间明摆在那里，测试人员的排期时间调整又是最麻烦的，因为在电商公司中测试人员是最稀缺。矛盾的是，技术人员希望问题解决的时间也应该算一个新需求，进行中的需求应该顺延，不然只能天天加班自我消化，叫苦连天。

或许需求工期评估时间多留点猫腻是一种办法，缺点就是容易造成双方的不信任，得不偿失。那有没有更好的办法呢？换个问法就是如何有条不紊地管理好版本迭代？且听我从"在京东我们是怎么度过一周的"角度说两句。 1、需求预审

有些产品喜欢私下和研发沟通需求，甚至是长时间的，这其实对双方都不利。容易消耗开发时间，而且一个研发对需求的理解多多少少有些片面。所以最好的方式是选择性地私下沟通，然后在需求预审会上再一起沟通。

需求预审聚焦点在于需求的价值分析、可行性分析、风险分析，我们对需求进行初步评估，然后提出存在疑问的地方，会上无法给出定论的，会下再讨论。

当然一个需求能进预审会是有前提条件的，以下情况的需求都不能进入预审范围。比如没有经过产品内部部门讨论的需求、一句话PRD需求、重复建设的需求、个性化和定制化的需求、相关依赖没有解决的需求。

时间安排：第一周的周四下午

2、技术方案初步确定

这个阶段对需求预审中双方没有达成一致意见的点进行更加深入的探讨，方便产品补充完善需求文档。另外我们此时会验证相关依赖的可用性、正确性，在大脑中构思方案。

时间安排：第一周的周五

3、需求正式评审

需求预审后和技术方案初步确定阶段的沟通交流结果，都有可能对需求产生巨大变化，所以需要对变更过的需求进行评估，确定需求的最终形态，避免开发阶段需求突然变更，让我们措手不及。

时间安排：第二周的周一下午

3、技术方案设计和评审

当然，并不是要求每一个需求都要进行技术评审的。当涉及到钱或者逻辑较为复杂时就必须进行了。技术方案编写好后组织同事和测试人员、领导一起评审。会后再输出工期。

我们技术人员编写技术方案时，容易一下子就陷入到技术细节中，关注某个功能如何实现。实际上我们应该多考虑整个交互流程，多想想不同操作场景，多想想有没有可替代的或者成本更小的方案，甚至可以反思这个需求的必要性真的存在嘛？！

时间安排：第二周的第二天

3、实现功能

所有需求的实现时间尽量不超过一个版本迭代周期。

4、代码评审

提测前必须进行内部评审，避免返工。另外需要邀请模块关系最强的同事，还有测试人员参加。因为他们不知道你到底修改了什么，影响了什么，是否存在牵连影响。此时我们选择开诚布公，他们会帮助我们提高代码质量，帮助我们判断代码在哪些场景下会腰折。

我们一般以以线下开会投屏或者共享屏幕的形式进行。这种形式或许不是最好的，但绝不是保守主义体现。因为上线变更引起事故造成的成本浪费远比一下午的代码评审成本要高，包括隐性成本。

时间安排：第三周的第二天

6、日常和测试期间缺陷管理

不管是日常问题反馈还是测试期间的缺陷反馈，当天必须解决或者有条件挂起。如果花费的时间超过半天，那就得当成需求卡片来处理了。

5、部署上线

部署必须灰度分批进行，必须周知干系人。另外，小需求必须合并上线，一周不能上线多次，不然就会浪费很多时间在部署上线和部署验证阶段。

时间安排：原则上，上线时间为测试通过报告的第二天，如遇到节假日、周末、营销活动日，顺延到下周一。

总结

可以看到，如果我们能够按照这种双周发版模式进行小步快跑的话，需求可以快速上线，研发也不至于压力过大。这一切的前提条件是需求拆分合理、产品要接受非需求时间也有可能算为需求卡片(比如大需求上线)、研发质量有保障。