API（默认在隐私协议同意之后生效），并且可以配置调用频率。权限管控：权限管理相对会复杂些，需要增加场景（比方需要在那个页面调用某个权限），且可以配置权限申请间隔时间（如果用户拒绝首次权限申请，默认

流动过程中，大家对能否往下个阶段流转产生歧义（比如：对于「结束开发阶段」这件事，开发同学认为是「编码完成」，而测试同学认为是「冒烟自测通过」），我们在每个节点声明了准入准出的条件（在敏捷中常被称为

隐式转换字段类型：col_a(VARCHAR)col_b(DATETIME)索引：index1(col_a)index2(col_b)SQL：select

阶段。如果读者想知道我们在共建（v2）阶段具体做了哪些改进来提升中台效能的，那就烦请坐等下回分解吧。如读者有中台协同相关的话题，欢迎在底部留言，我们做进一步交流。延伸阅读·

文｜傅宇康有赞数据报表中心为商家提供了丰富的数据指标，包括30+页面，100+数据报表以及400+不同类型的数据指标，它们帮助商家更合理、科学地运营店铺，同时也直接提供分析决策方法供商家使用。并且，每天在跑的底层任务和涉及的数据表已经达到千级别。面对如此庞大的数据体系，作为测试如何制定质量保障策略呢？这篇文章将从：1.有赞数据链路

文｜费解on效能改进一、背景在研发管理领域，业界一直在试图寻找可以衡量研发交付效率的指标。常见的指标有：吞吐率（多）、研发周期（快）、资源利用率（省）。然而，在实践中，我们发现，上述三项无法直接作为指导改进的北极星指标：1）吞吐率，在一段时间内交付项目的个数，是产品需求方关注的指标。若项目未交付，则不落入统计，也就无法发现问题和采取行动。而一旦交付，就错过了采取行动的时机。该指标是个滞后指标，它只关注项目的终点，犹如刻舟求剑，可参考性较差。见图1中，4月份吞吐率为0，但并不意味着生产是停滞的，5月份吞吐率为1，也不意味着持续了5个月的项目D是健康的。图1.

线程池之外，还需要增加对线程池的监控，进一步分离出不适合放在I/O线程池的任务（同样是「慢」和「多」）通过监控每个任务执行的时长，分离出长耗时（即「慢」）的任务，分析出是因为逻辑

点击关注“有赞coder”获取更多技术干货哦～作者：张家瑜部门：业务中台/测试开发前言有赞搜索中台的前身是ES中间件，并没有一个中台的概念，相应的就会有一个问题，业务接入搜索场景的时候还需要为此投入开发资源同步搜索设计，一个需求上线往往耗时很久，重复性工作较多，所以就有了后来的搜索中台的成立，将搜索完整链路的复杂性折叠成一个简单完整的搜索产品，让业务方直击搜索需求，无需费心搜索实现；在此前提下，如何针对搜索中台进行一个从0到1的完整的质量保障也是一个挑战，且中台面临的问题可能跟传统业务面临的不大一样，保障手段也需要更多样化。一、搜索质量面临的问题及痛点目前搜索业务架构如下图所示，笼统的说可以分两层，最上面一层协同网络效应层，也就是服务业务层，包括商品、交易、会员、营销、资产这几个核心业务场景，还有外围的零售、教育、美业、直播业务，第二层折叠效应层，将各种底层能力折叠在一起，包括索引写，索引读，索引管理，集群管理，其中集群管理包括双机房同步、索引重建、重载、监控等，依赖的组件不限于ES，还有Hbase、DTS、Flink、DP等；针对服务应用层、底层能力支撑层都面临着不同的问题，概括的分为三个部分，分别是影响面评估不准、流程规范为零、稳定性较差：痛点1：影响面评估不准服务业务层面临的最大的问题就是业务场景评估，目前有赞搜索业务几乎包含B端C端大部分核心业务，读场景占比量更大，例如B端商品管理页面、订单管理页面、会员业务搜索等，这时候就会遇到一个问题，如果ES进行了升级或者底层做了改造，怎样才能保障上游各个业务场景都没有问题，怎样保障回归用例完全覆盖，避免引发业务线上故障，是搜索中台核心要考虑的问题。痛点2：底层稳定性较差这块问题主要集中在底层集群，ES集群抖动会直接影响上游业务，在搜索前期不仅缺少一系列的监控报警，双机房切换也是纯手工一行一行操作，除此之外搜索涉及到的技术栈不止ES组件，还涉及到Hbase、Flink、DTS、NSQ等等，期间任何一个组件出现问题都会导致搜索读写异常，线上出现任何波动我们除了重启只能坐以待毙，需要整理出一套见招拆招的紧急预案；除了集群自身的问题，业务方的正确使用也是一个关键点，例如大in操作或者数组oversize这些如何避免，慢查query如何及时检测优化等等。痛点3：流程规范为零有赞搜索中台刚开始是以ES中间件为基础一步步搭建起来的，流程规范为零，一条业务线从搭建初始到后面能够正常运转，中间少不了开发跟测试同学之间做好的各种约定，且双方能够很好的执行这些约定才能保障这条业务线的稳定性，搜索中台的业务迭代很复杂，除了一些项目支持、日常支持之外，还会有比较多的压测需求、索引迁移、集群切换等等，针对每个模块都需要制定相应的规范及约定。为了解决上述痛点，搜索中台质量侧从如下几个方面进行落地实践：二、多方位保障手段1

实时数仓ETL处理过程所涉及的组件比较多，接下来盘点构建实时数仓所需要的组件以及每个组件的应用场景。如下图所示：具体实时ETL处理流程如下图所示：3.2.1

的实现方式是，应用启动时，获取设备唯一标识，上传一次基础信息。业务日志上报时，只需上传设备唯一标识。后端服务收到消息时，通过唯一标识获取基础信息，组合成完整的日志。2、按级别策略上报移动天网平台支持

点击关注“有赞coder”获取更多技术干货哦～作者：飘石部门：技术中台/中间件概述本文是根据有赞中间件团队多年的TCP网络编程实践经验总结而来，目的是为了避免应用因各种网络异常而出现各种非预期行为，从而造成非预期的影响，影响系统稳定性与可靠性。本文不会涉及TCP的各个基础知识点，主要是总结一些TCP网络编程实践中可能碰到的一些问题，以及相应的经过实践验证的解决方案等。虽然本文档很多细节主要是针对于Linux系统，不过，大部分建议适合于所有系统。本文共总结了16项建议，下面逐一进行介绍。1.

对于压测方案，我们主要是希望，在进行bos化改造之后，系统的性能不要下降，所以我们这边的压测策略选择了单机压测，相同的qps，观察分别走新老链路的性能指标。五、业务代码接入低代码平台的兜底方案介绍

Server，然后进行方法映射数据的处理。（2）性能数据同步。卡顿发生时，会上报相关数据。数据会通过DP(数据平台)进行清洗、计算和统计(比如前一天性能报告统计)，然后通过Hive

点击关注“有赞coder”获取更多技术干货哦～作者：欧阳霞部门：测试团队在最近的面试中，越来越多的候选人问到：“现有有赞测试团队是什么样子？”

执行等待机制上图这个界面，该商品的价格依赖于后端返回的数据，但因为此处价格的计算时间不稳定，大部分情况都是很快可以展示，但也存在不可预期的出现时间，刚开始脚本里的实现是页面等待

List）：基于用户级别的权限控制。将系统的各种权限直接授予具体的用户。抽象来说，为每个用户维护了单独的权限列表，当需要分配权限、收回权限时，需要修改对应用户的权限信息。RBAC（Role

点击关注“有赞coder”获取更多技术干货哦～作者：胡加华&冯明潇部门：数据中台一、前言随着近几年业务快速发展与迭代，大数据的成本也水涨船高，如何优化成本，建设低成本高效率的底层服务成为了有赞数据基础平台2020年的主旋律。本文主要介绍了随着云原生时代的到来，经历7年发展的有赞离线计算平台如何拥抱云原生，通过容器化改造、弹性伸缩、大数据组件的错峰混部，做到业务成倍增长的情况下成本负增长。首先介绍一下目前有赞离线计算的一些现状。万兆网卡的新集群，机器带宽不再是瓶颈。之前我们完成了一次跨云运营商（UCloud

x%），且列出“新增”与“新减”两个数据维度，协助对网络状况进行分析。“重复调用”会统计所有重复调用的接口状况，包括网络重复请求的总数，还会全部列出重复调用链接内容，方便业务方进行排查优化。2.2

时过多的数据，不可避免地只能通过物化到内存中，导致瓶颈产生，无法有效地提高性能。两者在有些场景甚至是可以混合使用的，一些前沿论文中还有使用软件预取的方式去尽可能地优化。主键索引，二级索引:

点击关注“有赞coder”获取更多技术干货哦～作者：更木部门：数据中台一、背景2020H1我们开展数据中台-离线数据成本治理并取得了一定的成效(详情可以参考往期文章：从量化到优化，详解有赞离线降本之路)。文中预告了下半年会拓展成本治理的范围，H2我们便开始思考并投入有赞数据的全局管理。不限于离线数据，实时数据、内部的平台工具均需要做到可管理、可治理。此外，数据成本透明度同样需要提升。目前成本只能覆盖至数据中台内部，和前台业务关联度低的问题需要解决。用户层面，我们也收到了诸多需求，例如需要相对灵活的成本分析功能、可满足多种角色的分析视角等。带着这些问题和用户需求，我们开始构建数据中台的全域成本账单，力求达成如下几个目标：成本多类型支持成本全业务覆盖多分析手段提供运营全渠道开展本文将围绕这四个目标，分享下我们在构建全域账单过程中的所做的工作，克服的困难以及收获的成果。二、

这个时代，大数据技术已经飞入寻常公司里。即便已经非常普及，其技术迭代升级也是飞速的，不断涌现出新的方案和应用场景。有赞8年的电商经验，沉淀了海量的数据。在数据处理过程中，也时刻面临着稳定性、实时性的挑战。作为大数据时代的核心资产，如何控制好成本，让数据驱动增长，也是热门话题。本次大数据技术沙龙，有赞携手网易、滴滴，共聚一堂，交流大数据领域的最新技术实践和想法。希望能相互学习，取长补短，为各自的业务增光添彩。主题介绍1数据成本治理在有赞的实践

groupKey;}自动分配处理人自动分配处理人主要目的是为了让对应业务的人快速处理属于自己业务的Crash。为此做了两种方式的自动分配。配置清单分配

在订单重构的实践中，最初在考虑灰度方案时，仅以比例灰度为目标，所以可以直接通过配置中心的灰度即可。但后期，希望有店铺白名单的支持，那么就不能以动态路由的配置灰度来完成。于是，动态路由也做了一些迭代。

端线上业务的影响。同时，业务方也可以利用配置的下发能力来限定功能的升降级范围，以对业务进行灰度测试。为了补齐原生侧的这部分能力，我们开始了对配置中心的设计。

有赞技术官方公众号，推广有赞技术干货，偶有有赞技术小哥哥小姐姐们的日常

1后端对DSL解析引擎可参考：https://developer.mozilla.org/zh-CN/docs/Mozilla/Projects/Rhino另外特定版本的App

java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)

实践探讨Vol.315最后打个广告～有赞数据中台，长期招聘基础组件、平台研发、数据仓库、数据产品、算法等方面的人才欢迎加入我们，一起enjoy简历投递邮箱jianfeng@youzan.com

点击关注“有赞coder”获取更多技术干货哦～作者：费解部门：效能改进笔者认为，从系统动力学的观点来看，由于受到自身发展的驱动，一个组织必然是在「混乱」与「有序」之间震荡，而且没有任何管理制度能成为银弹，让平衡一直维系下去。于是，我们所要做的，是不断调整管理手段，形成动态平衡，让组织得以进化。而研发管理，正是这样一种能让研发过程变得「乱中有序」的手段，尤其是「项目制」的管理方式，进可攻，退可守，既能阻止组织继续混乱，又能在时机成熟时，让组织的研发过程转危为机，进一步向「敏捷制」继续演进。笔者所在的效能改进团队，在有赞承担组织优化的重任，相当长的一段时期内，在产研侧持续采用「项目制」的方式，缓解症状，化解矛盾，实现组织现状与发展诉求之间的动态平衡。背景彼时，有赞员工

点击关注“有赞coder”获取更多技术干货哦～作者：徐钰菡部门：效能改进前言2020年全球最大的黑天鹅事件——“新冠病毒”的爆发，对线下集中办公工模式产生了巨大的挑战。面对「如何通过远程办公进行跨地域协作」这一难题，各大公司使出浑身解数。少数公司甚至会有一些奇葩操作：有的要求研发工作时间全程开启摄像头；有的要求开通远程桌面，实时监控员工的电脑桌面；有的要求早中晚均需进行打卡汇报……各种“骚操作”不断，在网上一度也是被热议的话题。那么有没有什么办法能快速、明确地知晓研发办公的效率呢？怎么做到有效感知“效率”，而不是实时观察“人”呢？现在许多公司项目管理团队逐渐从如何带好项目，渐渐转型为对团队的赋能和效能的提升。那么，如何利用数字化建立相对中立客观的效能度量数据，以便协助团队进行日常管理、帮助团队成长，同时也能在面对黑天鹅这种极端场景，依然可以有效进行协同呢？一、效能数据体系有赞作为一家致力于商家成功的SaaS公司，关注的不仅仅是研发侧的效能数据，更关注整个「商家」视角下的产品技术效能数据。因为对于客户来说，客户不会感知你设计时长、研发时长等各阶段详细时长，他们只感知到从销售、客服对接开始到最终交付的总时长。因此我司统计的效能数据体系，主要四类：研发效能数据、设计&交互效能数据、产品效能数据、其他效能数据。具体可参看下图：研发效能数据：从研发生命周期进行各阶段节点取数。全面统计研发团队、个人，业务线等需求、项目研发周期效能数据。【人力资源透明】：相关的研发同学在系统上进行任务拆解拆分，完成任务工时占理论投入工时占比。产品效能数据：从需求生产周期各阶段的节点进行取数，从而可以间接统计产品同学效能情况。同时引入「产品故障」，提高产品同学从全局观来设计产品需求。设计、交互效能数据：从设计、交互同学接收到设计任务、任务排期、任务交付，整个过程进行了系统的记录。引入「设计故障」，提高设计同学整体从用户角度出发的设计理念。其他效能数据：主要包含了非标准流程中的相关数据，例如客服咨询、相关工单处理，人力资源透明度等。而以上的各个阶段、各个维度的统计，离不开效能数据的基础————需求全生命周期。二、如何进行数据赋能2.1

点击关注“有赞coder”获取更多技术干货哦～作者：弋戈部门：效能改进背景一个城市越繁荣，所容纳的行业就越丰富。一个行业越兴盛，市场规模就越大，分工就越细，各类专业人士就越多元。经济学之父亚当斯密在国富论开篇即提到“分工出现之后，劳动生产力得到了最大的增进，以及运用劳动时的熟练程度、技巧和判断力得以加强”。高度繁荣的互联网行业，分工已经非常细致。一个典型的例证是，我们已无法向我们的父辈很快说清楚我们的工作是干什么的。如下图所示，有赞招聘网站(

没有索引，或者索引不正确这个场景其实比较容易理解。相信每个DBA工作过程中都会或多或少遇到性能案例都和索引设计有关:创建表，没有索引，sql随着数据量增大全表扫描而变慢。这个就不额外举例子了。4.2

内容来源：敏捷+社区线上直播004期，《OKR与敏捷》分享实录关注本公众号回复“有赞”即可获取本次分享的视频回放、下载PPT点击关注“有赞coder”获取更多技术干货哦～OKR是一个很热门的话题，我所在的公司（有赞）很早以前就开始实行OKR了。2014年老板去硅谷进行调研，带回来一种新的管理方式，一直执行到现在。本次分享也是我在OKR实践方面的一些经历和感受。OKR与项目管理、敏捷，都是一种提升公司或组织效能的手段，OKR与敏捷之间也有着千丝万缕的联系，它俩是相通的，都有很多不确定性，不是你做了就一定能成功，还需要达成很多平衡。管理是一门艺术，系统思考和组织设计，是两种底层能力，在敏捷实践过程中一定会涉及到。要组建一个敏捷团队，一定要有具体的角色，我们在组建团队的时候就开始做组织设计，在大规模敏捷框架里，组织设计也是一项非常重要的工作。小调查你在组织中处于什么角色？你在组织中处于什么角色？比如项目经理、敏捷教练、ScrumMaster、技术负责人等。你在做决策时，是否客观？很多时候在小范围内做局部优化工作，没办法做到全局理性，为什么呢？我们发现，无论是什么角色，在做自己工作的过程中，视野会被工作范围所局限。如何突破自身的角色和有限的视野，看到更大的范围和跃迁到更高的维度，就要回到系统思考的话题。系统思考来源于系统动力学，是一门学科。其中有一个属性，系统有一种层层嵌套的现象，所看到的是一层，如果想要看到更大更高的那一层，就要跳出所在的范围，到更高维度的世界去。实践敏捷也是如此，需要系统思考和更高维度的视野。我的敏捷世界观见山就是山

点击关注“有赞coder”获取更多技术干货哦～作者：杨一团队：中间件团队一、前言应用执行SQL请求完成的过程中，数据库连接占很重要一部分。尤其是涉及到流量瞬间暴涨，需要创建大量连接，或者网络异常导致重连时，从业务端来看，sql执行缓慢的问题，此时sql执行并非真的慢。本文是基于我们自己的生产环境的Durid最佳实践，仅供各位参考，当然不同公司的链路/业务压力可能不一样。具体到个别参数需要区别对待。二、具体实践从整体系统的角度，我们要考虑几个点

有赞测试团队近几年在持续交付、质量体系建设以及效率提升方面从0开始做了很多建设，在这个过程中，我们不断梳理、总结，渐渐形成了一本覆盖各个模块的白皮书，现在我们把这些内容对外，也欢迎大家一起交流。

本身的就能保证在多机房的数据一致性及可用性，但在实践中还是会碰到一些问题：若只有两个机房，没法实现机房级别的高可用（极端情况下一个机房完全不可用时需要人工恢复）March

商品作为基础服务，目前支持多个店铺类型，覆盖实物商品、虚拟商品、电子卡券、分销商品、海淘商品、蛋糕烘焙、生鲜果蔬、酒店商品、预售商品、餐饮商品等多种类型，不同店铺类型、不同商品类型有各自不同的配置。

、、点击关注“有赞coder”获取更多技术干货哦～作者：吕归尘团队：电商技术7月份某个平凡的下午，我们突然收到大量的线上告警：应用A的老年代内存使用率大于95%。登陆到监控管理平台可以看到3点半之后该应用的老年代内存使用率一路飙升，直逼100%，接着年轻代也一路上升。图1我们查看了一下进来的请求也很平稳，并没有突然爆发，那这个地方的罪魁祸首会是谁呢？为了方便读者接下来的阅读，在介绍这次故障之前，我们首先介绍一下我司的dubbo服务发现的流程。一、dubbo服务发现流程我们的开发人员在使用远程服务的时候首先需要配置一个dubbo

proxy会将写流量路由到master，读流量按照配置进行路由。在master节点故障的时候，RDS可以自动实现主从切换，并将写流量路由到新的master节点。双机房部署图如下：2.2

是几十倍甚至上千倍，这就是上面提到的权衡问题，相对来说，我们认为抖动的概率是远比宕机的概率大得多，这也是有数据支撑的，所以我们优先会考虑如何尽量覆盖抖动的情况，再在这基础上减少宕机带来的影响。5.2

、、点击关注“有赞coder”获取更多技术干货哦～作者：光富团队：零售技术一、需求背景自有赞零售正式发布以来，已迭代百余个版本，业务的发展免不了带来工程代码的飞速增加，时至今日，有赞零售工程的业务代码数量已达24w行，所使用的的二方/三方

全量和增量加速方案的分享到此就告一段落了，但是我们对于开发效率提升的追求永不停止。再次感谢大家对我们移动技术沙龙支持，我们未来会产出更多关于移动技术方面的分享，希望大家持续关注。扩展阅读浅谈

编译进阶之路——全量编译提效方案有赞零售财务中台架构设计与实践Vol.263有赞零售团队诚招高级工程师/技术专家，欢迎有兴趣的同学发送简历到：tangyi@youzan.com

点击关注“有赞coder”获取更多技术干货哦～作者：周夏赛团队：有赞零售一、背景近几年有赞零售业务快速发展，为了满足日益增多的业务需求，2019年起零售客户端发版改成了每周一次，在质量保障方面，技术团队要面对更大的挑战。故此我们团队做了很多研究，希望通过技术工具来提升移动端测试的质量和效率，这是我们研发移动端精准测试平台的初衷。目前业内移动端的测试手段主要有两种，一种是手工测试，手工测试是移动端目前主流的测试手段，一般流程是先根据业务场景梳理出对应的测试用例，然后将测试用例分配给开发和测试人员，由他们分别执行用例，排查问题；另外一种是单元测试，单元测试是通过工具进行自动化执行，执行完单元测试，除了根据单元测试的结果来判断代码质量，还可以获得对应的代码执行覆盖率的信息，这个是对单元测试结果的量化分析。这两种测试也有各自的不足，手工测试的覆盖范围依赖于相关人员的业务理解，缺少量化的评估，单元测试用例通常需要根据业务需求的迭代而频繁更新，维护成本较高。因此我们想要研发一个工具，可以支持手工测试的代码覆盖率分析，将两种测试手段的优势结合，这个工具就是移动端精准测试平台。本文会从iOS端来介绍精准测试的实现原理和我们的实践经验。二、原理代码覆盖率，顾名思义，就是代码在测试中被执行的比例，测试场景包括

建设的思考和实践需求价值闭环管理机制Vol.262如果读者对效能改进也有兴趣，欢迎加入有赞效能改进团队，请将简历投递至：jianghongbo@youzan.com，我们共同探讨和实践。

点击关注“有赞coder”获取更多技术干货哦～作者：啊福团队：效能改进背景有赞有千人规模的产品技术团队来保证公司业务的落地和正常运转，在投入如此大量人力资源的情况下，如果缺少有效的价值闭环管理机制，会导致业务的预期目标、运营计划、实际结果及后续改进策略等信息出现传递断层，影响到团队各小组之间的沟通协作，造成组织效能的低下。在建立此项机制前，经常在不同场合接收到各种声音反馈，比如：业务负责人：每条业务线或每项业务落地的需求是否达到预期效果？如果业务进展不及预期，是否对资源投放方向进行有效评估？产品经理：我做了第一期功能，商家用的如何？后面我要如何优化？研发人员：我做了许久的项目上线后，效果如何？为此，公司逐步建立了价值闭环管理机制，并以需求为切入点打通上下游，确保有赞人对价值闭环是有感知、有依据、有反馈的。一、挑战为了支撑业务的快速增长，纯粹的通过招聘更多人的方式，并不能真正解决问题，而且会带来更多人资成本和管理上的挑战，前车之鉴历历在目。就好比在项目管理工作中的“布鲁克定律”：当项目进度落后于计划时，增加人手的做法通常是无效的。那么，该如何利用有限的资源，确保能够按照公司的战略方向，推动重点业务和技术规划快速落地呢？从投资回报率（

点击关注“有赞coder”获取更多技术干货哦～作者：费解团队：效能改进背景众所周知，在丰田精益生产中，核心观念包含对人的尊重、消除浪费、持续改善，只有这样，企业才能保持良性运转，竞争力才会提升。而具体的浪费场景，被总结为「制造过剩、等待、搬运、库存、加工、额外动作、次品」七种，后来又增加了「管理」的浪费。笔者所在效能改进团队，一直致力于精益的实践，从降本增效的角度，来提升有赞软件研发的效能，以应对这个充满不确定性时代的变化的冲击。而彼时的软件研发，从过程管理的角度，已将「项目制」普及到团队之中并持续发挥作用，但从工程实践的角度，虽然各部门都有一些基础设施，但仅为本部门服务，整体处于萌芽阶段，需要有一条主线将各独立的孤岛串接起来，发挥协同的价值。一、工程实践的现状1.1

点击关注“有赞coder”获取更多技术干货哦～作者：老雷团队：效能改进导语当一个组织处在几人或是几十人的规模时，会共同维护一份产品待办列表，许多冲突和矛盾都会暴露得快而明显。而当组织扩张到上百人时，就会随着业务单元规模形成N份产品待办列表，我们便会意识到，有些问题因为过于普遍而被忽略，或是由于被更小的组织单元消化，或是在全局视角看起来不具备共性和短期影响力。但我们时常会在这些暂时被隐藏的问题或风险上栽大跟头。本文作者将为你介绍的是，如何形成并统筹管理大规模产品待办列表，从而降低协作沟通成本，提升资源利用率。那个令人头秃的夜到了月底，所有产品技术都在如火如荼地进行着做月度规划，安排下个月计划做什么需求。唯独产品经理小王迟迟动不了手，因为每个业务都有需求依赖他所代表的业务技术的支持，面对所有需求方都说自己的需求紧急重要，他不知如何是好。这样的情况，每个月都会遇到，通常他会去依照他的想法排优先级，排不上的再做一轮又一轮沟通。而这一次，他叫上我（作者）、某产品线TL

点击关注“有赞coder”获取更多技术干货哦～作者：老雷团队：效能改进导读战略，是为实现某种目标（如政治、军事、经济或国家利益方面的目标）而制定的大规模、全方位的长期行动计划。战略的落地常常是经由跨部门、多角色、多模块的复杂协同单元共同完成，基于此特点，战略项目对管理动作的系统性、全局性提出更高要求。我们通过反复的实践发现，Scrum框架中的经验控制理论同样适用于战略项目管理，我们将结合透明、检视、调整这三支柱来介绍我们如何做战略落地。[透明（Transparency）：大处聚焦透明，小处以终为始]战略项目通常不仅仅是面向单一团队的独立、局部的活动，协同组成广泛且复杂，因此容易出现协作单元陷于具体的事务性工作疲于奔命，却不知身在何处甚至迷失了方向的情况。战略项目的项目经理这个时候便需要起到一个“联结”作用，将大方向和小目标充分“联结”，让所有战箭一致射向同一个靶心，不至于因为飘了方向而产生不必要的浪费。具体操作，我们会分为3步：建立关联：我们呈现给项目成员的目标绝非他们自认为的局部目标，而是整个团队的共同目标。经由核心团队明确基本的O（Objectives）和KR

点击关注“有赞coder”获取更多技术干货哦～作者：阿福团队：效能改进背景随着公司团队和业务规模的快速增长，在组织内外部需要传递的信息越来越多，发生的连接关系也越来越复杂，不可避免的会出现一些问题：在宏观层面，会因为遇到“断点”问题的存在，不可避免的造成了信息不对称和理解不一致，导致目标无法及时达成，从而错失展现强大商业能力的机会；在微观层面，由于业务规划阶段花费了较长时间且没有做关键信息同步，在有明确deadline的情况下，研发环节的时间被严重压缩，造成团队内部的信任感降低。所以，我们需要建立一种价值流体系，让所有人都参与其中，为团队共同目标不懈的奋斗，并拿到符合预期、甚至超出预期的结果。本文将重点讲述有赞在需求全生命周期管理方面的实践内容。主要活动有赞效能改进团队在需求管理的不同发展阶段，与相关团队配合、协作，推行了一系列改进动作。从最初在研发侧保障需求有序落地，到推动产研侧需求优先级和排期活动的开展，并逐渐从产研侧往前延伸到业务侧（包括外部商家和所有内部业务方），打通需求相关方在信息传递和沟通协作上的断点；同时，基于不同发展阶段痛点问题，不断优化需求管理策略，沉淀优秀实践结果，形成了具有鲜明有赞特色的、强价值流管理的方法论和实践经验，主要包括围绕着目标对需求进行端到端的管理，从需求分层分级、需求排期、需求价值闭环等管理机制的落地；以及从商家需求、业务需求、产品需求的提报、流转到价值回顾的全流程管理配套工具的支撑等。需求全生命周期，一般包括从业务规划、产品规划、产品设计实现、产品运营到需求价值回顾等多个环节。虽然从表面上看，需求全生命周期显得比较瀑布，但是在实际操作中，各环节都会有迭代增量的操作。同时，为了使需求全生命周期各环节之间的效能持续提升，除了要突破“深井”，建立业务线内和不同业务线之间的紧密联系外，还要在需求全生命周期的管理模式上下一番功夫。一、业务&产品规划从组织层面来看，业务&产品规划活动，更多的是根据公司