业务端技术团队有多痛？

编者按：本文来自微信公众号“InfoQ”（ID：infoqchina），作者沈剑；36氪经授权发布。

本文整理自 58 同城技术委员会主席沈剑在 QCon 2017 北京站上的演讲，原题为：《业务端技术团队真的痛？》本文将为你详细分析业务端技术团队的各种常见痛点。

技术团队的痛处

团队是指一种为了实现某一目标而由相互协作的个体所组成的正式群体。是由员工和管理层组成的一个共同体，它合理利用每一个成员的知识和技能协同工作，解决问题，达到共同的目标。团队建设是企业在管理中有计划、有目的地组织团队，并对其团队成员进行训练、总结、提高的活动。

在本次演讲中，我将讲述的主题是业务端技术团队所存在的痛处，我将介绍其业务团队在带队过程中可能遇到的一系列问题，之后结合自身经验与大家分享。问题如下：1、和 PM 为何不能愉快的玩耍？2、和 QA 为何不能愉快的玩耍？3、压力大、项目做不完、永远加班做业务怎么办？4、Bug 多、质量低、永远加班该 bug 怎么办？5、人员流动率高，真的是因为没有技术含量吗？

1、PM 相处篇

目标一致

与产品经理相处存在的最普遍问题在于目标不一致，最典型的例子是 KPI 的制定、产品团队 KPI 指标的考核。产品团队、运维团队等 PM 的绩效指标在于 PV 的增长量、UV 的增长量。公司业务团队 KPI 如何考核？技术团队的 KPI 一般标准如何确定？技术团队负责质量，产品团队负责业务指标，假设当时产品团队提出一个功能需求，完成此功能可提升其 PV 和订单量，技术团队对其进行评估发现，由于其高复杂性会对已有信息造成大的冲击，并且这一更改会导致系统的不稳定性，或者说需要较长的时间更改它。那么怎么办，为何会出现这种情况？

其主要原因在于目标不一致。如何协调两者之间的关系？举个例子，产品经理和技术经理在讨论问题，产品经理觉得技术经理的团队技术并不支持他们的产品，导致他们不能达到目标；而技术经理却认为，如果他们的技术支持了产品会导致他们自己的目标达不到。为了防止此类现象的经常性发生，他们应该在业务开展开始前便达成一致目标，因为这是一个自上而下的过程。一个团队组织架构是业务团队的闭环，内部有产品技术部、测试部。而有些团队组织架构内部包含的是产品部、技术部、质量部，若其以业务单元为组织架构可能不会存在目标不一致的问题，但若其以职能为组织架构却可能发生该类问题。

但是，即使是这样的组织架构，在目标上仍然需保持一致，在创业阶段更需要保持业务优先原则。因此，一定要确保产品团队与技术团队达成目标一致性。一损俱损，一荣俱荣。对于目标不一致的解决方案，以业务指标为第一目标，然后统一目标，统一 KPI。为达成一致目标需要 PM 负责人以及业务团队达成共同意识，否则各自完成各自目标，结果终究是对立的，他们不仅需要实现业务，还需要对系统的稳定性和质量负责。

初期的快速迭代可能因此不会考虑太多设计层面的问题，或者说初期的架构设计适应了当期数据量、并发量和业务迭代速度。但随着时间的推移，业务发生变化，并发量、数据量持续上涨，系统架构不再能够支撑，而这时便需要技术团队进行技术改进的项目，尽管这可能与业务功能实现无关。

举个例子，APP 重构，58 到家有多家 APP 商家、用户端以及司机端等，一开始为了追求速度，招聘 3-5 人形成一个团队进行开发，后来发现我们可以进行分层抽象和沉淀公共组件，以此提高开发效率。数据层也是同理，后端做服务端，web 端访问数据库，加入缓存，使得架构结构更加合理。我们最初采用 AM 线和 CM 线各自账号体系的登入方式，后来业务方向发生变化，因此开始改做平台方向，但我们存在跨业务线登录的需求，即 SSO 的需求，统一进行技术优化的项目。

然而当我们拿着技术改进项目与产品团队沟通时，沟通结束之后双方都可以达到自己的期望与预期吗？举个例子，技术同学花费两个星期时间进行技术优化，产品同学却说这个月我有非常重要的运营项目，我需要运营 PV 和 UV 来完成自己的业务指标，由此得出，产品同学并不理解技术改进、技术优化。那么如何达成一致性？第一为达成一致目标，为指标负责。作为一名技术人，都想要达到 PV 高、技术好、流量涨的目标。如果产品经理与我的总目标一致，那么当我说服产品同学为我做这些事情时会更简单，因为总目标一样，产品同学理解起来会更加容易。

数据说话、以理服人

目标一致、数据说话、以理服人。该采纳的建议是什么？

第一，我们可以与 PM 同学解释，我们技术改进项目与其总体目标是一致的。而我们需要做一个 APP 的重构或者重组的组件化，需要产品同学降低其安装包大小的百分比，进行完美配合之后，其用户体验性会更好、下载速度更快、使用流量更少，并且可以预期完成项目优化，据经验也可提高 10% 成功率。

第二，缓存优化。关于分层架构，产品同学表示原先下一个单需要 800 毫秒，访问数据库效率缓慢。但是在完成此项目之后不需要访问数据库，下单时间变成 300 毫秒，直接提升用户体验，并且其用户转化率和留存率随着业界体验的提升而提升。关于 passport 重构，技术组与产品组各自完成自己的任务。当技术团队做单步同步时，一旦完成一类项目，需要同时与 passport 项目减少 5 名人员，并且使用产品组所能理解的语言进行沟通，因为大家的目标是一致的，所有人的任务都是为了共同完成 PV、UV、GMV 等目标。我们从实践中得出经验，即使现在下单确实很慢，但在进行优化之后，转化率显著提高。而在进行技术改进的项目时需要使用数据来与产品经理进行沟通表示双方一致的目标。

项目总结、效果说话、增强信任

每个公司都会产生这样的状况，研发资源不够，需求难以满足。据我所知，即使将工作人员的数量翻几倍，该需求仍然不被满足。那么这该怎么办？技术同学每晚加班，项目多，压力又大，人员流动性便大。短期加班冲刺、熬夜上线可以接受，可是长期以往如此，所有人都会拒绝。

用效果说话，增强其信任。如何用效果说话增强信任呢？首先产品同学与研发同学的人数比例需要采用经验得出的数值，比如说我们需要做 B 端后台系统，信息系统 1:15，那么一个产品需求需要 15 个研发，C 端后台系统 1:5，那么一个产品需求对应 5 个研发。三个产品运营 + 运营 VS 一个技术，根据经验数值比例可得人数必定不够，或者说产品需求过多。

为什么需求需要那么多？真的需要完成这么多需求，这么多功能，这么多改版吗？而且每一个运营、改版真的可以达到我们预期吗，或者说你进行任务之前做好预期吗？功能完成对我们的总体目标有帮助吗？会产生多大的帮助呢？如果需求做不完有没有和技术同学说明效果评价、效果预期？

每个项目的预期是不一样的，每个项目对目标达成的比例也是不同的，所需要占用技术同学的比例也不同。每个人都想投入最少，却得到最高的 PV。运营项目也是如此，假设该时期正逢双十一，产品经理应告诉技术人员，采取技能优秀优先原则，需要大量人才来提高其 PV 率。对于技术人员的审核，介于双方需求的一致性，若其提出的需求对达成目标有所帮助可采纳，若不能则拒绝。因此，在我看来，产品同学需要提前做预期，而技术同学需要反向进行预期评估，而不能仅局限于功能实现的资源。

不管产品同学需求多少人，都不能以技术人员人数有限的态度敷衍派人员，因为大家都是朝着目标共同努力。举个例子，当前共有 10 个项目，PM 同学需要对项目进行收益预期，此时正运行 5 个项目，PV 增长 10%；而对每一个项目技术同学也参与投入预期，投入 4 个技术人员，时长为两周，若其运营较为简单，那么投入一个技术人员，时长为三天。经过这样的预期计算，可能选择五个人进行该十个项目，对目标达成的收益最大。

对产品的要求做效果评估，对技术同学反向做效果的询问和明确，然后根据投入产出比衡量优先级。功能项目需要收益总结、提升需求总结、建立信任关系等，即使初期的预期收益不精准，但长期如此，其结果会更加准确。但信任关系却不是，比如某个技术团队 VS 三个产品团队，该团队对接三个产品团队，每个产品团队必定说，与其他相比，我优先级是最高的。在这之前我们需要建立一套机制，用来评估其预期值以及技术投入产出比。

于是，该产品团队为争取到资源而不断努力，并提高其预期值来获取优先级，夸下海口说可增长 50% 的 PV，技术同学认为该团队对我们有益，选取。但在项目结束之后，技术团队进行项目总结发现，预期并没有完全达到，只达到 10%，技术同学便不开心，心想该同学提的需求特别不靠谱。而产品团队却认为，我虽然不能提高 50% 的 PV，但我可以提高 15% 的 PV，可项目一总结发现 15% 也没有达到，达到 12%，还相差一点。

因此，产品效果预期评估不准确，在未来的合作中，即使产品团队表示自己团队优先级很高，但介于之前合作其不靠谱的需求预期，其信任关系便难以再次形成。若每次提出需求预测较为准确，且每次达成目标，那么该信任目标也自然而然地被建立了。所谓统一对接人，上游需要技术团队需求预期，业务、产品团队也需要技术团队需求预期，但是技术团队难以评判。需求团队对接产品团队，技术团队对接产品团队，技术改进项目可和运营项目、产品项目共同评估优先级，产品团队需要做效果预期，技术团队需要根据投入产出比评估项目优先级。

2、QA 相处篇

目标一致

研发团队与 QA 团队的关系是一家人还是对立的？我曾在百度工作过，研发团队的绩效目标质量高，千行 BUG 率低于标准值。关于技术团队质量的评定，几个 9，超时即低于标准值。QA 团队绩效目标是将所有有问题的代码测出来，千行 BUG 测出率高于标准值。因此，这两个团队必有其一达不成目标，其结果会产生什么影响？

测试团队为了达成 KPI，需要尽可能多的提出 BUG。若 KPI 产生该结果，那么他们仍有改进的空间。与研发和产品目标不一致的观点不同，以业务团队统一目标与业务目标为标准，即共同达成 PM、RD、QA、FE、UI 的目标，且每个团队仍然有自己的小目标。我们曾收到过一些反馈，包括测试质量低、可测性差、bug 研发搞不定、性能低下。

目标一致、任务分工明确、数字说话

如果测试团队说，技术团队质量低，那么技术团队是不会同意这个说法的，这与技术团队对产品团队说他们需求质量低，但产品团队不接受一个道理，没有证据不能随意说出质量水平低此类评语。

开发现阶段常存在的现象，提测质量低、可测性差、bug 研发不能解决、性能低下。RD 为质量负责，QA 辅助，这样的搭配团队可以达成目标一致吗？所谓模块负责人制，即每个模块或者系统都有第一负责人、第二负责人。然而有些公司可能并不采取模块负责人形式为项目组，直接安排工作人员完成、测试项目，然后继续进行下一个项目，所以导致研发同学对代码的编写毫无责任心，结束项目便是万事大吉，并不理会未来发展问题。模块负责人制，每一个模块都有一个负责人，而且不乐意他人在自己的模块乱指挥。

比如 APP 团队项目按照功能来分块，A 同学做 A 功能、B 同学做 B 功能、C 同学做 C 功能等，每个人有自己的风格与习惯，因此你也会发现 MAV 分成明显，各块代码风格迥异，由于 MAV 由多个同学开发，于是没有人愿意主动为其质量负责，为项目负责，他们仅是完成任务而不再后续进展了。于是逻辑层、数据层质量低下，各类风格的同学在写代码，没有人想将其继续优化做得更好。在有模块负责人的情况下，假设该 APP 团队被分为三组，分别负责展现、逻辑、项目。任何一个层次出现问题，都会有相应的团队找到相关人员，要其做出处理，于是在项目中他们的交流沟通次数增多。

举个例子，某同学进行开发 MAV、DAO 等，他很清楚地了解页面设计、交互以及数据问题，但需要将其模式开发成一个页面，于是三个小组各派成员进行沟通如何提高其质量，缩短时间。以现在的情况来看，越是大团队越是采取的分工模式混乱，以 58 同城为例，一个 APP 团队有 50 至 100 名工作人员，多个业务线，于是大批量人开发同一个 APP，而每个人各做各的事，编写着自己的代码，毫无沟通，导致其开发质量低下。所以必须采用模块负责制，RD 为模块负责，QA 辅助，利用专业方法和专业设计保证其模块质量。

因此也必须明确两点，第一研发是系统质量的第一负责人；第二必须通过准入达成一致，流程上的一致性、提测前的一致性，没有通过准入 QA 不会进行测试。接口测试是近年来提高了效率才产生的，早期时候，测试与研发的比例为 1:3，一名功能测试同学，三名研发同学，以长远的目光来看待这个比例并不是一个完美的选择，因此需要提高其测试效率。那么通过什么方法提高测试效率呢？接口测试、性能测试、自动化测试等方式？

创业公司必然经历过这样的阶段，招聘测试开发的同学慢慢学习开始做接口测试。接口测试需要设计，以及 bug 的提及。因此该同学需明确其提出的 bug，等其有复现过程后，与研发同学沟通交流，等待他们的修改和研发。但由测试同学告知研发同学需修改的地方，这是对研发同学的不信任表现。我们需要明确研发同学为性能负责，那么研发同学定然已发现性能瓶颈，并对其进行了优化，提升了性能。做出任何的评价需要用数据，有理有据。

上图为团队数据月报。它详细说明了每个业务部门产品需求、技能改进情况、bug 修复情况、上线需求总数、需求总数、需求完成率、需求超 5 人天需求数。技术团队对产品团队说，你们需求太多；产品团队表示 ，我们需求并不多，只有 5 个需求，你们都没有统计需求，怎么可以说多。技术团队表示不满意，明明系统都有统计数据。于是产品团队技术说，你们需求总是不能达成。技术团队又不乐意了，他们表示他们需求完成率为 100%，全上线了，即使存在没有上线的需求，但完成数仍保持高的状态。而关于 bug 的修复，观察数据就可以发现质量低的团队，数据都是明确的。

找到主要矛盾，针对性的改进

不管是产品提测的问题，或者是研发测的问题，还是整个测试质量的问题，先看数据找到主要矛盾，再进行针对性的改进。我们曾经有过问题测试维度很高的情况，有些部门有三个，有些部门有五个，而一次上线成功的概率低，且上线之后第一时间总是出现问题，还要进行新一轮的修改再上线，于是收集数据、找到主要矛盾、针对改进。

3、加班篇

加入技术设计 + 评审环节

业务研发团队压力大，项目完不成，加班情况严重，就会导致项目延期。2016 年，我刚加入 58 同城，曾观察过项目的执行情况。正如许多创业公司会做的，首先产品团队写出需求，之后进行评审，需求评审结束之后，项目产品负责人会咨询技术负责人，评审已结束，需要多长时间完成项目 。技术负责人回复，需求较多，还不能完全消耗，据经验需要四个星期时间完成项目。产品同学立马呈现出不信任的样子，并且表示这么简单的项目，时长期限只允许两个星期。于是产品同学与技术同学对时长期限进行争论，最后约定三个星期完成。

于是技术同学开始做任务，然后发现技术范围比想的还多得多，以为接口已经存在只需调用就好，最后发现却不是，而当时却没有考虑这个问题，可期限只有三个星期，于是赶快开始实现。其实经验丰富的工程师评估时间是较为准确的，而经验不丰富的新手工程师评估能力还有待提高。他们不能在三个星期的期限内完成任务，怎么办？他们不得不再次找产品同学表示他们确实不能在三个星期内办到，产品同学表示需求时间是技术团队自己决定的，不能按期完成，为何还找我们？技术团队那怎么办？加人？从别的部门协调两个人加入团队。

但参加过项目团队的同学都知道，并不是所有加人的项目都可以缩短工期，但产品团队却觉得人员增加一倍，时间减少一半。这种情况下，既然加人并不是一个完美的选择，那么怎么办？那就只有加班的选择了。周六周日加班到 11 点，还可能因为未按期完成任务受到产品团队的投诉，在经过长期几轮的加班后，离职率便增高。而现阶段的状态也是如此导致其人员流动性高。

控制需求变更

 流程存在的问题

如上图所示，项目流程包括需求到需求评审、开发、联调 + 提测、测试 + 修 bug、上线。然而，比经验排的时间点不准确更可怕的是什么？如下图所示。

上图为实际项目流程，需求到需求评审、开发到需求变更、开发到联调 + 提测到需求变更、开发到联调 + 提测到测试 + 修 bug 再到需求变更、开发到联调到上线。

项目周期定理

变化出现在项目流程的越上游，项目风险越小，项目越可控。需求是项目流程的第一步骤，大多数推翻项目重新开始的阶段便是在项目的早期阶段，或是需求评审时期。在这阶段时期，并没有研发同学参与，全程仅仅是产品团队在解决，那为何会产生如此多的需求变更？因为在很多情况下，产品团队在没有思考清楚时便开始着手准备，在进行一半时却发现有一个更好的想法，只是这个想法在初期没有想到，于是推翻重新开始。如果变化发生在设计阶段或者开发阶段，重来仅仅是重新设计、重新开发；若变化发生在需求阶段时重新需求；若变化发生在上线阶段，重来是整个流程的重新开始。因此变化越上游风险越小。

互联网公司需求是不会保持一成不变的，反之是一定会变化的，并且有些变化的需求是不可拒绝的，然而这种情况的需求较少，产品较多。很多时候不是不让变化，而是变化需要付出代价。大多数技术团队认为，需求变化是理所当然且正常的行为，不变化才是不合理的状态。但介于大家目标一致，都是为了 PV、UI、PD 等度量，因此正常的变化是被接受的，而频繁的变化会让人无法理解。

在技术同学与产品同学的双方交涉过程中，一次、两次的需求变化还可以接受，但频繁需求变化之后，产品同学表示他的权限不够，如果还需要进行变化需要上报负责人审批，由于过于频繁的变化，一级 Lead 权限也有限，需要更上级的 Lead 同意，总结审批，产品同学便发现自己这么频繁需求的变化可能会导致上级领导误会他是名不靠谱的员工，因此产品同学不得不在需求初期便想得更清楚，避免后期又出现这种状况。

产品同学在调研、绘图、写文章、评审的几个过程之后才完成一份完整的文档；而技术同学也有设计、评审、工作任务分解的过程。每个团队都有自己的工作，不可能产品同学需要技术同学的帮忙，技术同学便可以马上拿出时间来。他们都需要提前安排时间。因此时间第一，控制需求变化频率不变要有代价。除了需要改进需求、需求评审，还有设计和设计评审环节，这样的方案才更靠谱。但尤其注意的是，工作任务分解，其现阶段要求分解到半天级别，这样即使分解出现不准确时间也不会有特别大的差距。

4、质量篇

数据说话、数据收集、bug 收集与分类

线上 bug 多，便投入大量的时间修改 bug。大多数公司表示线上 bug 是最高优先级的，用户反馈需要修改 bug，公司会优先解决，这也是个高优选择。线上出现 bug 需要修复，在很多情况下，该临时状况并未考虑在项目排期过程中，因此经过多次的经验总结，需要保留 10%-15% 的空间安排修改 bug，否则项目上线、bug 修改，两件事的冲突最终结果仍然是加班完成任务。需求原因、项目流程原因、线上质量原因等各种因素都会导致加班结果，因此也需要不断进行技术改进，减少线上 bug 问题，做更靠谱的未来排期。

数据说话解决主要矛盾。项目出现问题需要数据证实，但是项目的初期不存在数据，因此不得不花费一两个月的时间做数据的总结和收集，并得出该期结论。比如，运营产品团队的后台配置失误、优惠券的打折出错等需调整数据的问题也属于 bug；你作为新用户用手机号注册 58 到家，但是过一段时间之后，你换了手机号码，但发现没有这个功能，于是提交订单请求修改数据。

然而并不是所有类型的 bug 都需要第一时间接入进行修复。用户侧影响较大的需要第一时间解决，但后台侧、体验侧、优先级低的问题不需要立马解决，可采取一些措施。首先进行 1 至 2 个月的数据收集，进行问题分类，对每类问题进行针对性地解决。第一类，难以避免的配置错误，被提供的系统运营和产品配置之间存在错误，但是犯错是存在代价的。需求变化是正常的，第一次错误帮忙解决，第二次犯错经理审批。多次的犯错需要从自身找出原因，知识缺乏、技术缺乏、态度不端正等因素，任何的犯错都需要代价。

举个例子，技术同学抱怨自己的工作没有技术含量，因为他日常的事情都在接受修改用户手机号的需求，在数据库中修改数据，并且日复一日地做这乏味的事情。产品反馈功能优先值较低，每个月只有一两次帮忙修改，但是大家都不会设想未来随着人数的增多，流量的增多，业务的发展，此类情况可能会变成高频发事件。对于低频的事件，RD 需要手动修复数据做成功能。Bug 不分优先级，但需要 RD 第一时间介入修复，规范流程。

bug 修复流程

如上图，Bug 修复流程。Bug 解决也是一个流程，研发团队需要和产品、运营团队、PMO 沟通、讨论、确定线上 bug 解决流程。而在 bug 处理流程中，大多数是用户侧提出来的 bug，并且确定其确实为 bug，而不是功能和策略，且该部分的 50% 已被 down。达到研发团队的 bug，评判优先级较低，且需要一个复现的过程，请求 QA 确认过程。优先级是依靠产品的方案进行快速判定，发现不能跟踪的第一时间必定通知了研发团队。然而并不是所有问题都是有技术团队面向客户群体，高优 bug 在当天晚上 24 点下班之前必须解决；次有问题 48 小时必须解决；之后便是两周之内，最后影响不大的未来在考虑。

5、技术含量篇

深刻思考的重要性

业务团队可能存在的问题。当一名技术同学每天重复地执行这数据库的任务，常常做着没有技术含量的事情，于是士气低落，准备离职。可是我们需要开始反省，很多事情是真的没有技术含量，还是说其实是我们想得不够深刻。微信钱包静态落地页的运营需求，完成一页静态页面，看上去似乎也是毫无技术含量。可是真的是这样吗? 我是一名架构师，曾作为该项目的技术评审，所以也不禁提出疑问，作为技术人员，你是否与运维同学了解过微信一秒钟时间内大概覆盖的用户量？30 分钟其覆盖的转化率如何？静态页面的点击率又是多少？

根据运维产品同学的经验表示，其 30 分钟内两千万的覆盖转换率大概为 10%。可仅仅了解这个是不够的，必须进行更深一步的思考，比如每秒静态落地页的吞吐量，若其吞吐量较高，没有深入考虑该问题过就可能导致不能在第一时间解决问题。所谓静态页，即点击之后会根据用户所在的不同城市，展示该城市所开通服务的入口。

比如，北京开通了宝洁月嫂保姆，点击之后便出现宝洁月嫂保姆的下单页面；而上海只开通保姆和月嫂却没有开通宝洁，那么上海用户点击之后会出现保姆月嫂的静态页。那么如何实现不同城市的静态页？APP 端将此城市传送过来，包括其开通的品类，然后将其品类入口重新拼装再返回。然而用户的持续点击率造成了数据的负荷，需要缓存进行优化，可是选择缓存数据还是页面成为了新的问题，即使缓存的过程并不涉及技术含量，但是却需要谨慎思考选择哪一个更加合适。

选择缓存数据，可数据量太庞大，将整个地区的数据进行计算、拼装、返回，会造成用户的浪费；选择页面，可缓存过程时的流量被提高扩大了 100 倍，带宽也增加，会引发一致性问题。因此，在很多情况下，不是事情没有技术含量，而是心态没有端正、考虑不够深刻从而导致我们不能做出有技术含量的事件。

除此之外，很多已发生的状态都不能在被询问时的第一时间回忆起，需要翻看日志才能答复，再者出现的问题永远是用户先知道，投诉客服、客服反馈产品团队、产品团队找技术团队解决问题，所以解决问题的时间周期长、用户影响时间长。而以上这些情况都仅仅是因为技术人员不够深刻思考，不足够了解性能数据。不同同学找 bug 的过程是不一样的，有些同学需要三小时，有些同学却只需要 3 分钟。当一个经常性出现的问题，却仍然使用复杂的过程修改 bug，却不用最基础类似改脚本的方式解决，这不是技术含量的问题而是不会思考的原因。

培养技术氛围

每个同学擅长的技术点是不一样的，有些同学喜欢站在讲台上与大家分享的诉求，而有些同学却喜欢听别人讲解，进行学习吸收知识的诉求。那么何不建立一个可同时满足两类人诉求的平台，白天项目多，业务量大，无心分享，然而在晚上时间加班、分享二选一的选择，绝对 100% 的同学会选择做分享，因此该行为促进了他们白天的工作效率，使得其系统建设更全、质量更高、找 bug 时间也越短。

该种沟通分享方式称之为技术培训夜校，白天完成工作任务，晚上相互分享或者相互学习。在项目流程中加入设计环节与评审环节，对技术氛围的培训有较大的帮助。评审环节是技术方案讨论与学习的好机会，在技术方案讨论的过程中，除了设计者提出的方案，还有众多同学会提出其意见，讨论其缓存优化、一致性、页面缓存等问题，可从中获取经验。

作者介绍

沈剑，前百度高级工程师，58 同城技术委员会主席，58 同城高级架构师，58 同城技术学院优秀讲师，58 到家高级技术总监，58 到家技术委员会主席，“架构师之路”作者；在 58 同城负责过即时通讯业务技术团队（后端），负责过二手、心宠、优品等业务技术团队；在 58 到家负责过测试平台、PMO、DBA、OP、信息系统团队，负责过架构、基础平台、后端平台、中台业务等后端团队；现负责支付平台、营销平台、客户平台、企业平台等业务技术团队。