技术工作的一二三之快餐

发布于: 2020 年 05 月 27 日
技术工作的一二三之快餐

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


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

要重点强调的是,需求被划归内部关注点之外,是由于当前大部分发起点是运营产品团队,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增长。

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

    

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

  

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

发布于: 2020 年 05 月 27 日 阅读数: 2
用户头像

拖地先生

关注

探寻本质。 2018.06.21 加入

从事互联网技术管理工作,公众号《拖地先生》每周两篇实践沉淀~

评论

发布
暂无评论
技术工作的一二三之快餐