技术工作的一二三之快餐

这系列是三年前的沉淀，回首看一直在跟着业务奔跑，静下来长考的时间很少，越来越多焦虑也许来自于此。近期的工作中，不管是对外分享、顾问团队沟通还是价值观的思考，都推着自己在技术工作、组织管理、能力雷达上做出总结。通过思考和讨论，确立技术工作的方法论和价值观，继而逐步沉淀技术工作在团队中的最佳实践。

这篇内容从业务交付说起，是技术工作的基石，重点要讨论的内容是项目管理中的流程。技术工作中的内容，我分为了五个元素，业务、团队、技术、质量效率和流程。



要重点强调的是，需求被划归内部关注点之外，是由于当前大部分发起点是运营产品团队，PRD已是经过充分论证，工程师工作较少，内部需要关注的是如何落地实现，而不是需求建立本身。相反地，技术团队务必关注业务指标和结果，这也是工作价值所在。

这些元素中，前四项是实实在在可以看到的，业务和质量效率是工作的发起和结果，团队和技术是落地的基石。而流程，在我当前的出发点是，用以解决研发过程中的问题，满足业务交付的手段。这其中有两个含义：

         1. 流程能够解决问题，不能解决问题的流程不应该在研发过程中。

         2. 有了问题才需要针对地调整流程，没有出发点的调整没有价值，反而会带来团队的混乱。

基于不同业务形态和团队能力的差异，需要量体裁衣地进行流程的设计。而受到关注点的不同，流程的把握对其他四项的影响是非常大的。通过有针对性的流程调整，团队能够快速收敛到一个持续平稳交付的状态，但我把这种方式称之为“快餐”。原因有二：



一、极大地依赖于团队主管对于问题关键因素的把握

在业务和团队迅速扩张的情况下，问题的影响因子是在变化的，信息传达链也会变长。如果主管无法及时地深入至研发过程中的每个人和每个环节，都会导致业务的交付问题。救火行为则会带来管理精力成本，同时恢复稳定的时间和代价不可控。



二、流程中的每个环节都有资源开销成本

      如果这个环节是为了规避团队能力差异带来的问题，不管是时间成本还是管理精力的成本，这个环节都应该在团队成长到某个节点优化掉，从而带来研发效率的提升。

在我们的研发流程中，近两年有这样一些关键环节的调整。

1. 需求拆分

      这是在需求评审完成后进行的环节，主要目的是规避开发过程中由于沟通能力的差别/历史业务的熟悉等原因，导致对需求细节的理解偏差。需要参与版本的全员聚集在一起对PRD进行讨论。由于沟通的精力开销对于每个参与版本的成员都是必须的，因此在5人左右的版本或功能中，这个环节是充实有效的。但随着动辄50页+的PRD和越来越多的成员（H2已有16人）参与版本，这个环节对整个团队来说效率变得越来越低下。

      这个环节属于快餐的性质，团队需要在更小规模（理想中是每个人）的理解沟通能力都能满足完成交付的要求。当前流程调整为对拆分输出物的确认，团队成员是否能在这个阶段成长为骨干，以领导小团队保质保量交付为考察基线。

2. 开发前输出物交付（数据库和接口设计）

      这是需求拆分后的验证环节，同样是为了规避开发节奏依赖，各端交流不充分等问题。这一环节的落地是必要的，能够最大程度地减少数据设计的技术债和沟通成本。但同样存在接口文档系统不够灵活，耗费精力较大的问题，需要在工具和开发习惯上找到契合点。

3. 排期确认

       这是团队是否能稳定保质迭代的关键环节，核心的影响因素有两个。

       一是迭代节奏的控制。随着业务线统一为事业部、运营人员大幅加入团队后 ，需求的增长迅速。在排期上遵循四象限原则，将需求归入不同象限后进行安排。常规的版本迭代是重要不紧急的，由于APP不能随时发版，热修复被应用商店禁止，因而交付时间的准确对于运营节奏是非常重要的。团队的开发节奏也需要以常规迭代为核心，在质量优先的前提下保证交付时间的准确。核心业务和问题修复版本是重要而紧急的，需要协调一切资源快速完成。临时活动、数据需求等工作结果影响需求发起人的工作进度，是紧急但重要性略低的，要在保证前两项工作完成的前提下，进行优先级协调后安排。对于未经产品评估的需求，被认为不应该进入研发阶段，需要和产品评估后安排至其他象限或取消。多人配合的工作均列入看板，以同步并减少沟通成本。



            二是交付时间的确认。这一点由于关注点的差异，在早期是较为尖锐的矛盾。需求发起的同学通常关注的是当次交付的时间，因而期望越快越好。但在技术的要求上，关注的是平均交付的时间，要求在长期迭代中都能保持相对高效。由于软件设计的特殊性，如果不关注长期迭代的设计，会造成大量的低劣实现，带来团队成员的补丁式思维惯性。在技术债达到一定程度后，维护成本增加，交付时间离预期渐远，迭代节奏混乱，人员流失。在这一点上，我关注的是实现细节，在清楚全部设计内容后再进行时间点的确认。也要求团队成员尤其是研发骨干摒弃“压排期”的想法，将沟通目标放在细节同步上，将精力专注技术本身，以长期高效作为需求交付的唯一目标。

        4. 产品验收节奏

            在近一年的工作中，由于测试资源的波动，产品同学的验收方式被多次调整。在资源紧张的时候，为了保证需求的实现质量，产品在模块测试时就已经介入了验收工作。这也同样属于快餐环节，在沟通顺畅，保质实现的前提下，不应该在这方面耗费产品同学过多的精力。

        5. mirror环境

            当前的测试有三个步骤，系统（模块）测试、mirror测试和线上验证，在常规版本迭代中需要约一周的时间。mirror环境这个环节是一些客观因素而设立的：开发环境的数据和线上数据有差异、开发机的运行环境和线上的环境有差异、业务耦合度较高缺乏全面的测试覆盖等。同时，这也是工具化发布的必经验证环节。由于这些原因，在线业务经历了多次严重的事故。而不遵循这一环节，偷懒发布也经历了数次血的教训。从技术的角度讲，使用docker统一环境、脱密后同步实际数据、自动化测试覆盖、持续集成落地这些基础工作完成后，可以缩短或取消这一环节的开销。但在当前的状态下，不失为一个性价比较高的最佳实践。

        6. 灰度发布与APM

            在互联网运营中，灰度是项被实践后沉淀的核心环节。从交付的角度讲，通过小规模真实用户的使用结合APM（bugly、听云、日志系统、错误/慢响应监控），可以避免未知的问题影响大规模用户使用，从全体用户或业务层面保证稳定性的波动在可控范围内。在近一年的崩溃率、卡顿率、响应时间等的指标曲线上看，能够持续下降并波动较小，得益于这一实践的落地。但是，由于应用商店的限制，这一环节必须依赖于应用商店，导致研发和运营流程的重叠，给产品和运营同学带来了干扰和质疑。在发布之前就完成灰度的工作，彻底剥离研发和运营环节，是需要进行尝试和优化的方向。

           而APM对于业务问题解决、系统整体的稳定和风险预知上同样得到了最佳实践。日志系统解决了CS交互的问题定位手段缺失，跨过了16年日活增长和业务复杂后频繁暴露的用户侧逻辑问题。各项硬件和应用监控起到了预警和分析的支持，线上问题在业务感知和用户大面积暴露前都已得到控制和解决，平稳地度过17年日活及PV增长。

          因此这一环节不但是研发过程中的必要流程，监控和风险预判也是技术能力雷达中的重要考核要素。

综上，当前在项目管理中的方法论：针对性的流程调整可以快速解决研发过程中的问题，其中的最佳实践应该被严守，快餐手段需要团队成长优化。

下一篇我们讨论技术团队和个人在能力成长的方法论。