软件开发平台 DevCloud软件开发平台 DevCloud

计算
弹性云服务器 ECS
裸金属服务器 BMS
云手机 CPH
专属主机 DeH
弹性伸缩 AS
镜像服务 IMS
函数工作流 FunctionGraph
云耀云服务器 HECS
VR云渲游平台 CVR
特惠算力专区
存储
对象存储服务 OBS
云硬盘 EVS
云备份 CBR
弹性文件服务 SFS
存储容灾服务 SDRS
云硬盘备份 VBS
云服务器备份 CSBS
数据快递服务 DES
专属企业存储服务
云存储网关 CSG
专属分布式存储服务 DSS
CDN与智能边缘
内容分发网络 CDN
智能边缘云 IEC
智能边缘小站 IES
智能边缘平台 IEF
人工智能
AI开发平台ModelArts
华为HiLens
图引擎服务 GES
图像识别 Image
文字识别 OCR
自然语言处理 NLP
内容审核 Moderation
图像搜索 ImageSearch
医疗智能体 EIHealth
园区智能体 CampusGo
企业级AI应用开发专业套件 ModelArts Pro
人脸识别服务 FRS
对话机器人服务 CBS
视频分析服务 VAS
语音交互服务 SIS
知识图谱 KG
人证核身服务 IVS
IoT物联网
设备接入 IoTDA
设备管理 IoTDM(联通用户专用)
全球SIM联接 GSL
IoT开发者服务
IoT数据分析
车联网服务 IoV
路网数字化服务 DRIS
IoT边缘 IoTEdge
设备发放 IoTDP
开发与运维
软件开发平台 DevCloud
项目管理 ProjectMan
代码托管 CodeHub
流水线 CloudPipeline
代码检查 CodeCheck
编译构建 CloudBuild
部署 CloudDeploy
云测 CloudTest
发布 CloudRelease
移动应用测试 MobileAPPTest
CloudIDE
Classroom
开源镜像站 Mirrors
应用魔方 AppCube
云性能测试服务 CPTS
应用管理与运维平台 ServiceStage
云应用引擎 CAE
视频
实时音视频 SparkRTC
视频直播 Live
视频点播 VOD
媒体处理 MPC
视频接入服务 VIS
管理与监管
统一身份认证服务 IAM
消息通知服务 SMN
云监控服务 CES
应用运维管理 AOM
应用性能管理 APM
云日志服务 LTS
云审计服务 CTS
标签管理服务 TMS
资源管理服务 RMS
应用身份管理服务 OneAccess
区块链
区块链服务 BCS
可信跨链服务 TCS
智能协作
IdeaHub
开发者工具
SDK开发指南
API签名指南
DevStar
HCloud CLI
Terraform
Ansible
API问题定位指导
云生态
云市场
合作伙伴中心
华为云培训中心
其他
管理控制台
消息中心
产品价格详情
系统权限
我的凭证
客户关联华为云合作伙伴须知
公共问题
宽限期保留期
奖励推广计划
活动
容器
云容器引擎 CCE
云容器实例 CCI
容器镜像服务 SWR
应用编排服务 AOS
多云容器平台 MCP
基因容器 GCS
容器洞察引擎 CIE
云原生服务中心 OSC
容器批量计算 BCE
容器交付流水线 ContainerOps
应用服务网格 ASM
网络
虚拟私有云 VPC
弹性公网IP EIP
弹性负载均衡 ELB
NAT网关 NAT
云专线 DC
虚拟专用网络 VPN
云连接 CC
VPC终端节点 VPCEP
数据库
云数据库 RDS
数据复制服务 DRS
文档数据库服务 DDS
分布式数据库中间件 DDM
云数据库 GaussDB (for openGauss)
云数据库 GaussDB(for MySQL)
云数据库 GaussDB NoSQL
数据管理服务 DAS
数据库和应用迁移 UGO
大数据
MapReduce服务 MRS
数据湖探索 DLI
表格存储服务 CloudTable
可信智能计算服务 TICS
推荐系统 RES
云搜索服务 CSS
数据可视化 DLV
数据湖治理中心 DGC
数据接入服务 DIS
数据仓库服务 GaussDB(DWS)
应用中间件
微服务引擎 CSE
分布式消息服务Kafka版
分布式消息服务RabbitMQ版
API网关 APIG
分布式缓存服务 DCS
分布式消息服务RocketMQ版
企业应用
域名注册服务 Domains
云解析服务 DNS
云速建站 CloudSite
网站备案
华为云WeLink
会议
隐私保护通话 PrivateNumber
语音通话 VoiceCall
消息&短信 MSGSMS
云管理网络
SD-WAN 云服务
边缘数据中心管理 EDCM
云桌面 Workspace
应用与数据集成平台 ROMA Connect
ROMA资产中心 ROMAExchange
API全生命周期管理 ROMA API
安全与合规
安全技术与应用
DDoS防护 ADS
Web应用防火墙 WAF
云防火墙 CFW
应用信任中心 ATC
企业主机安全 HSS
容器安全服务 CGS
云堡垒机 CBH
数据库安全服务 DBSS
数据加密服务 DEW
数据安全中心 DSC
云证书管理服务 CCM
SSL证书管理 SCM
漏洞扫描服务 VSS
态势感知 SA
威胁检测服务 MTD
管理检测与响应 MDR
迁移
主机迁移服务 SMS
对象存储迁移服务 OMS
云数据迁移 CDM
专属云
专属计算集群 DCC
解决方案
高性能计算 HPC
SAP
游戏云
混合云灾备
华为工业云平台 IMC
价格
成本优化最佳实践
专属云商业逻辑
用户服务
帐号中心
费用中心
成本中心
资源中心
企业管理
工单管理
客户运营能力
国际站常见问题
支持计划
专业服务
合作伙伴支持计划
更新时间:2021-03-18 GMT+08:00
分享

影响地图

影响地图是一个简单却极高效的协作性的策略规划方法。

有的产品,它还活着,却已经死了;有的产品,还没发布,就已经死了。太多的产品失败的案例,源于方向性错误,基于错误的假设,功能与业务目标/价值之间缺乏必然的关联与一致性,在做的事与期望的目标南辕北辙。

影响地图试图通过结构化、可视化、协作化的方式来从源头解决上述问题。

影响地图是一门战略规划技术,通过清晰的沟通假设,帮助团队根据总体业务目标调整其活动,以及做出更好的里程碑决策。影响地图可以帮助组织避免在构建产品和交付项目的过程中迷失方向,确保所有参与交付的人对目标、期望影响和关键假设理解一致。

同时,影响地图可以有效的评估交付,作为质量反馈的标准之一:如果一个需求没有有效的支持期望的行为影响,那么即使在技术上正确,功能交付给用户了,也仍然是失败的。

影响地图试图去解决组织面临的范围蔓延、过度工程、缺乏整体视图、开发团队和业务目标不能保持一致等困扰。

影响地图的结构

简单的讲,影响地图是这样的一个思维逻辑和组织结构:为什么(Why)>谁(Who)>怎样(How)>什么(What)

也就是:我们的目标是什么(Why),为了达成目标需要哪些人(Who)去怎样(How)影响,为此我们需要做什么(What)。

影响地图通过构建产品和交付项目来产生实质影响,从而达到业务目标。

  • 为什么(Why)?

    “我们为什么做这些?”也就是我们要试图达成的目标。

    找到正确的问题,要比找到好的回答困难得多。把原本描写在文档中,更多的是隐藏在高层利益干系人头脑中的业务目标,定性定量的引导出来。

    目标描述要遵循SMART原则,确保每个人知道做事的目的是什么,帮助团队协作,针对真正/合适的需求设计更好的方案。

    • Specific(明确的)
    • Measurable(可度量的)
    • Action-Oriented(面向行动)
    • Realisitc(现实的)
    • Timely(有时限的)
  • 谁(Who)?

    “谁能产生需要的效果?谁会阻碍它?谁是产品的消费者或用户?谁会被它影响?”也就是那些会影响结果的角色。

    考虑涉及到的这些决策者、用户群和生态系统,注意角色同样有优先级,优先考虑最重要的角色。

    角色定义应该明确、避免泛化,可以参考用户画像Persona的方式进行定义。

  • 怎样(How)?

    “考虑角色行为如何帮助或妨碍我们达成目标?”也就是我们期望见到的影响。

    在这里我们只需列出对接近目标有帮助的影响,而不是试图列出所有角色想达成的事。影响是角色的活动,是业务活动而不是产品功能。理想情况下应展现角色行为的变化,而不仅仅是行为本身。

    不同的角色可能通过不同的方法,帮助或阻碍业务目标的实现,这些影响彼此之间可能是相互参考、相互补充、相互竞争,或者相互冲突的。既要考虑到正面的影响,也要考虑负面或阻碍的影响。

    业务发起方应该针对角色Who以及影响How,而不是交付内容What进行优先级排序

  • 什么(What)?

    “作为组织或交付团队,我们可以做什么来支持影响的实现?”包含:交付内容,软件功能以及组织的活动。

    理论上这里是最不重要的一个层次,我们不应该试图一开始就将它完整列数,而应该在迭代过程中逐步完善。同时注意,不是所有列出来的东西都是需要交付的,它们只是有优先级的交付选择。

    "永远不要试图实现整个地图,而是要在地图上找到到达目标的最短路径。"

    影响地图足够简单、操作性强、又有足够的收益:能够帮助创建更好的计划和里程碑规划,确保交付和业务目标一致,并更好的适应变化。影响地图的首要任务是展示相互的关联,次要任务是帮助发现替代线路。

通过以上论述我们可以看出:影响地图符合软件产品管理和发布计划的发展趋势------包括面向目标的需求工程、频繁的迭代交付、敏捷和精益软件方法、精益创业产品开发循环,以及设计思维。如果你认同上述趋势,那么影响地图会是你的菜。

影响地图的特点

  • 结构性:从业务目标到交付的结构化梳理和挖掘的方法,目标--角色--影响--交付物。
  • 整体性:连接目标和具体交付物之间的树状逻辑图谱。
  • 协作性:利益相关人一起沟通讨论协作,把隐藏在个人头脑中的默认的思维逻辑挖掘共享出来。
  • 动态性:动态调整、迭代演进、经验证的学习。
  • 可视化:统一共享的视图,结构清晰易读。

影响地图将各个部门/角色不同的视角、不同的思维逻辑、不同的前提假设,通过可视化和协作的方式进行梳理、澄清和导出。通过连接交付内容、影响和目标,影响地图显示了之所以去做某个功能的因果链,同时也可视化了各利益相关人做出的假设。这些假设包括:业务交付的目标、涉及目标干系人、试图达到的影响。同时,影响地图沟通了两个层面的因果关系假设:

  1. 交付会带来角色行为的变化,产生影响。
  2. 一旦影响达成,相关的角色会对整体目标产生贡献。

影响地图的分层

是否可以将影响地图分层? 答案是可以而且合理的。

建议计划两次会议:第一次定义预期的业务目标和度量,第二次来制作一张地图。第一步是确定使命,而一个战略目标往往太大,无法快速见效,需要拆分成可短期达成的战术目标。根据优先级排序的战术目标,逐次进行影响地图分析,期间动态调整更新,定期决定是否需要继续。

因此可以有两层的影响地图:"一份针对整体产品愿景,一份针对中期交付。"

同时,通过分层,也可以有效的控制参与两个会议的人员组成。高阶的领导者未必需要参加所有的影响地图活动,尤其是战术影响地图会议。

参与人员

决策者,技术人员,业务人员。注意一定要有决策者参与,包括:商业决策、技术决策、营销决策。如果发现一个问题讨论很久没有决定,也许是因为缺乏合适的参与人员,应该找更高阶的人员决策。

参与人数:原书的建议是将第一次会议人数限制在不超过5-6人,确保关键的业务决策者和技术人员参与进来。随后的会议可以适当扩大规模分组讨论,随后汇总,但人数越多,会议的节奏和范围就越需要控制。

影响地图与用户故事的关联

  • 影响地图可以作为用户故事列表的有效输入

    影响地图的输出物,可以作为用户故事的输入,作为Epic、User Story的来源。这些输入已经经过了价值判断、角色挖掘、优先级排序,甚至已经有了一部分的验收标准(是否影响了受众同时为达成目标作出贡献),同时也因为有资深技术人员的参与,初步做过技术可行性判断。因此这些backlog的输入,往往更加靠谱,对交付团队更具价值。

    • 输入形式

      《影响地图》书中有明确的描述,把三段式的用户故事与影响地图几个层级进行mapping:作为一个Who,我希望What,以便于How。

    • 用户故事管理 at DevCloud

      DevCloud中提供对用户故事的分级管理,可在工作 > 需求规划中,将影响地图中根据层级划分好的用户故事输入到DevCloud中,与影响地图的层级进行对应。

      需求规划视图以树形结构列出了需求从“Epic > Feature > Story > Task”的逐级关系。

      同时可以应用DevCloud对需求按照用户故事的通用格式进行编辑。

      更多关于DevCloud敏捷项目管理的操作,参见项目管理帮助文档

  • 影响地图可以很好的控制用户故事列表无限蔓延

    看似动态调整的用户故事列表,根据精益消除浪费的思想,维护完整的故事列表,事实上也是浪费。

    存在的问题有两点:

    第一,看不到用户故事与业务价值直接的联系,往往为了实现功能去做,而不是考虑其背后交付的价值,以及这个价值是否被用户认可。

    第二,故事列表往往是各方头脑风暴的结果,同时还在不断更新,却很少剔除,这个长长的列表不仅需要定期维护,其背景、内容、优先级、价值等都在随着商业环境的变化而不断变化,事实上维护一个三个月或者半年以后才可能实现的需求就是浪费。

    • 目标/里程碑与发布计划

      业务目标可以与迭代的发布计划关联,每次迭代只处理少量的目标。

      《影响地图》建议一次只处理一个目标,目的在于快速反馈和调整。个人认为基于团队规模、迭代步速,一次迭代可以包含几个目标取决于目标的颗粒度以及时间估算,不可一概而论。在具体执行时,这里会是一个争论以及变数较多的点。

如何防止思维蔓延,地图扩张

  • 先发散再收敛

    实战练习中,我们40多人分成6组,分别绘制自己的影响地图;实际场景中,如果每组都基于同一个目标,绘制出来的地图会各具特色而发散,最终需要引导将发散的地图进行收敛,在此过程中,会发现更好的实现方式或是新的假设导出,最终得到成型的影响地图。

    分层和拆分时,掌握80/20原则,不求面面俱到,只需要涉及最关键重要的因素。考虑到大部分团队会使用物理板+即时贴的方式进行影响地图的设计,因此,原本因为物理空间受限以及可读性原因存在的物理白板的弊端,反而可以作为细化程度的一个有效限制原则(正如著名的两个披萨原则):以物理墙/白板为影响地图的最大边界。

    相对于我们通常关心的业务功能/营销活动,即影响地图的第四层What,我们更应该把注意力放在前三层目标、角色和影响上,尤其是角色和影响上,关注点如此,优先级排序也是如此;先不要关注在What即自己要做什么事情上,这往往会让我们陷入执行的细节,埋头做事,而忽略了事情的初衷。

  • 多数的路径最终不会被执行,是否需要保存?

    首先,要避免过早陷入过多的细节,未来一切都是未知的,所有的结论都是基于当前的假设。所以,维护一份完整的地图,试图将所有想法都归纳在地图上,是没必要的。

    其次,要遵循目标导向原则,避免在那些对整体目标没有作用的影响上花费过多的时间。整理出来的路径,当然可以保留下来,作为下一次影响地图的部分输入。

    此外,需要注意的是,What包含交付内容、软件功能和组织的活动,如果交付的所有条目都是技术性,也许要重新审视影响地图,尤其是角色Who与影响How两部分,并非所有的目标都是需要通过产品功能达成,更多情况下,也许一个简单的营销活动就可以快速实现目标。

什么时间结束

  • 影响地图会议何时结束

    “当关键想法已经出现在地图上。”

    当团队已经达成目标,并且确定最快/小路径,暂时也想不出更好的替代方案时,就可以结束。

    建议设定严格的timebox,一旦出现时间点超时,或者是由于团队陷入太过细节的讨论,或是没有找对合适的人,例如缺乏合适的决策者,也许是业务决策者,也许是技术决策者。

  • 影响地图何时失效

    如同计划,在制定出来的那一刻也许影响地图就已经失效,因此需要适时调整(注意是适时,未必是实时)。

    影响地图更像是迭代计划,每个影响达成,进行反馈评估,对影响地图的内容以及优先级进行调整;一旦目标达成,也许这张影响地图就完成了使命。

本文参考资料

  • 《影响地图:让你的软件产生真正的影响力》Gojko Adzic (作者) 何勉 ,李忠利 (译者)

分享:

    相关文档

    相关产品

关闭导读