纯技术改造，技术如何驱动需求，我有话说

工作中，难免会遇到服务迁移，服务升级等工作，但是这类需求通常都是技术升级改造，并非产品推进业务需求，关于技术如何正确地驱动需求并执行，我有些经验想和大家探讨下。

相信大家和我们一样，通常我们项目流程是：产品出原型图，找 UXD 出 UI/UE，需求评审，技术排期，技术开发，技术联调，提测修复 bug，产品 &UXD 验收，灰度上线，全量上线。当然有些小公司可能流程没这么苛刻，但是大体相同的。这个流程中，主要由产品来主导，大点公司还会有专业的 PMO 人员帮忙，所以大家觉得一切顺理成章，理所当然。然而，当没有了产品介入时候，项目团队难免会陷入等待别的资源，进而出现一盘散沙的情况。

想想看，如下这些场景是不是在日常工作中经常遇到：

1. 这块产品需求文档没写清楚，需要找产品确认，甚至牵扯到调整 UI，一来二去延期 3 天以上。

2. 这个逻辑客户端说放在服务端更好，服务端说应该在客户端做。业务侧说放在服务层做，服务侧认为业务来做。来回扯皮，延期好几天。

3. 开发自测边界覆盖不充分，交到 qa 手里，一堆明显 bug。徒劳增加 qa 的工作量，测试时间不得不延长。

4. 联调，测试环境几近崩溃，总有稀奇古怪的问题，折腾排查半天发现环境所致。(多人协同开发尤为严重)

5. 原定开发临时有事请假，关键节点阻塞，整体进度被迫推迟。

上述情况只是列举一些常见的，实际项目中还有更多各种复杂的局面。下面我以安居客租房 PC 列表页迁移项目举例，为了保证项目的顺利完成，我们确定了 123 战略。

一个目标：Q1 之前，也就是 3 月底，完成整体迁移。

二个原则：原有的页面结构不改动，原有功能完整平移。

三个并行：服务侧对接服务侧，业务层对接业务层，前端对接前端。

不打无准备之仗

为了完成目标，我们在项目排期之前，就剖析完页面，把页面按照模块和功能进行了敏捷拆分和细化，尤其是我们业务层的，细化到具体的功能和验收标准，以及每个模块对应的开发工程师。而对于其他团队的依赖，我们也能细拆的都进行了细拆，标明了对应负责接口人。最终整理的表格示例如下图所示。

然后，我们请求了 PMO 同事帮忙，拉着项目成员进行了进度倒排，梳理出各个节点的依赖。在每 2 天一次的进度会上，进行集中问题沟通，督促大家进度，把控延期风险以及做好延期预案。比如一个功能延期我们可以暂时先去开发别的，完全践行了不空闲，不等待的高效工作。

兵马未动 粮草先行

划分完模块功能后，我们开始沟通输出预定义的接口文档，与前端，客户端按照协议，独立并行进行开发。当然，实际工作中参与接口设计的人未必就一定是负责该模块的工程师，所以我要求我们团队的小伙伴，严格按照规范，把所有对接沟通的文档资料都分门别类的整理好，统一汇集到一页 wiki，形成目录，方便任何人索引查阅。

换句话说，我们能做到，任何一个小伙伴，都可以不需要再次沟通，根据文档资料就可以独立开发，完成某些子功能或组件。比如在列表页项目刚启动，我们就抽象了获取地域 cityLocal 实体由白梦柯负责实现，底部 SEO 模块交给与项目无关的孔明帮忙，筛选项属性获取由鑫伟完成，大家都把每个模块 demo 开发完成后，统一提交到 test 目录下，方便我们后续其他工程师实际开发调用。这样下来节约了大量的跨部门和临时换人的沟通成本，而且也可以给后续测试和优化提供参考。

破釜沉舟，釜底抽薪

为了保证项目按时完成，我们在排期时候就预留了 3-5 天的 buff。为了给其他团队小伙伴压力，我们后端在我没和小伙伴们沟通下，就拍板说 2 月 28 日完成开发，实际上留给我们开发时间不到一周。收益效果还是很明显，拿我们前端团队举例，其他小伙伴们原本按照排期下来都排到 3 月中旬了，我说我们 2 月底就能完成，你们能不能想想办法，再压缩下工期。于是前端又讨论了技术方案，由原来 1 人负责列表，1 人负责详情，到 3 人同时优先保证列表，之后再一起负责详情。这样我们整体进度都在 2 月 28 日完成开发，保证 3 月 1 日提测。结果前端小伙伴们非常给力，在 26 日就率先完成开发。而我们后端由于技术资源紧张，原本一名得力工程师，被另一个优先级更高的跟版需求调走了。再加上迁移过程中还有各种意料不到的逻辑和问题（最大成本还是和安居客团队跨城市异地沟通，有时候还需要拉产品重新梳理等）结果出现了我在 58 工作 3 年来，第一次落后于别的团队进度的尴尬局面。那段时间，我们天天都加班到深夜 11 点以后，同事们都调侃说这段时间再也不用为打不到车而担心了，因为错过了晚上打车高峰。当然，给自己压力还有一方面原因，是 3 月份由于个人原因，不得不去住院做手术，担心走后小伙伴们压力更大，所以能往前赶就赶，能多做就想着多做点。

工欲善其事 必先利其器

去年的一年，我们团队都在围绕提升人效而努力。团队每周轮流对成员进行集体代码 review，不仅规范了代码风格，也给大家普及了高性能编程意识。此外，每周五的技术系列分享，强化了团队的技术能力。平时，也会给大家普及一些提升工作效率的小技巧。比如常见的登录 ssh，我一般开 3 个 tab 窗口，一个专门用来检测日志，一个用来 debug 代码，一个用来重启服务。再比如我们常见的服务重启，相信不少小伙伴们会陷入不停地 pwd 和 cd 中，而我直接把服务重启执行的脚本超级路径提前写好，用的时候随手一个 copy 就瞬间解决。看似这些不起眼的小细节技巧，会让大家事倍功半的。前几天还整理了一个程序员 A 和程序员 B 的故事，贴给大家，对照下，你到底是 A 还是 B 呢？

打破知识的诅咒

关于知识的诅咒，有些人耳熟能详，有些人可能比较陌生，大家可以自行去网上了解下。由于 3 年前我来 58 房产第一个项目就是列表页服务化，所以对于安居客列表页迁移服务觉得是轻车熟路。之前挑战过一天完成一个租房类目服务化，在评估这次工期时候，觉得一周肯定绰绰有余。结果呢，发现 58 的列表页代码在安居客的列表项目中，还有很多需要调整，基本上重写了所有底层通用代码。筛选项 58 是服务层做的，但是安居客的需要我们自己实现解析，url 筛选项属性值替换等。另外，还有很多安居客独有的东西，比如城市域名。拿北京解析来说，58 不存在这个问题，就是 bj.58.com。但是安居客那边支持 beijing.anjuke.com 和 bj.anjuke.com。这就需要一个支持从 beijing 跳转到 bj 的服务模块。此外，还包括大量底层服务重新实现调用，由于交接是上海的安居客同事，我们需要找不同接口人，沟通成本随之上升，调试不同方式调用不同服务等等。也就是说安居客的列表迁移仅仅是参考借鉴了 58 列表服务化的流程，其他基本上就是重写。显然这就是自己给自己埋了巨大的坑，没好好做足调研工作。好在团队小伙伴们都很给力，顶着压力如期完成了任务。

和光同尘，与时舒卷

住院期间，追了电视剧《大江大河》，里面水书记对宋运辉的指点醍醐灌顶，提到的和光同尘思想我自己也感同身受。我把剧本台词单独摘出来，如下：

工作往往就是在妥协和博弈当中完成的。这就是和光同尘的精髓。就像打篮球，一支篮球队有五个人，你跑的又快传球力量有大，谁能接得住你啊？你能力强你可以打前锋，可是总要有人打后卫，有人给你传球吧？”

想想工作其实也一样，对待别的部门，别的同事，不能像要求自己一样那么苛刻。每个人有每个人的工作技巧和沟通方式，要放平心态，耐心挖掘出他们的诉求，认真理解他们的苦衷。别总是抱着一副别人不积极不配合的心态去看待问题。对于别人不好做或者实现成本高的模块，我们是不是可以帮着多做一些？这样就能减轻他们的压力，会让他们更愉悦的支持我们。像 java 服务的同事，之前项目启动都没来得及通知她们，但是真正需要找她们时候，都是很积极提前就完成了需求。再比如我们前端同事，关于页头右上角用户登录模块的交互，安居客线上是模板输出未登录，用 JS 实现用户登录态获取并显示个人中心。他们表达了这类公共组件对他们的困扰，于是沟通后我们就把这块交互放在了 PHP 后端来做。这样既优化了用户体验(已登录用户不会看到未登录界面，然后在局部刷新到登录态界面)，又省了前端同事的繁杂工作，让他们抽出更多时间精力来帮我们做详情页等支持。

最后，我想说认识了张维这样专业的 PMO 同事，对自己在项目管理方面的帮助很大。更感谢各位参与本项目的同事的大力支持和积极配合。也感谢我的领导在我住院期间分担我的大量工作。我想借用游戏里一句配音来感谢大家：不是一个人的王者，而是团队的荣耀！有你们，真好！