影响地图产品开发介绍

    影响地图是一个简单却极高效的协作性的策略规划方法。
影响地图试图通过结构化、可视化、协作化的方式来从源头解决上述问题。
影响地图是一门战略规划技术,通过清晰的沟通假设,帮助团队根据总体业务目标调整其活动,以及做出更好的里程碑决策。影响地图可以帮助组织避免在构建产品和交付项目的过程中迷失方向,确保所有参与交付的人对目标、期望影响和关键假设理解一致。
同时,影响地图可以有效的评估交付,作为质量反馈的标准之一:如果一个需求没有有效的支持期望的行为影响,那么即使在技术上正确,功能交付给用户了,也仍然是失败的。影响地图试图去解决组织面临的范围蔓延、过度工程、缺乏整体视图、开发团队和业务目标不能保持一致等困扰。

image


image


image

image

image

为什么(Why)?
回答:我们为什么做这些?也就是我们要试图达成的目标。
找到正确的问题,要比找到好的回答困难得多。

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

  • Specific 明确
  • Measurable 可度量
  • Action-Oriented 面向行动
  • Realisitc 现实的
  • Timely 有时限的。

image

谁(Who)?

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

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

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

image

怎样(How)?

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

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

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

image

什么(What)?

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

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

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

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

image

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

image

image

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

zh-cn_image_0183620703

image

影响地图可以很好的控制用户故事列表无限蔓延
看似动态调整的用户故事列表,根据精益消除浪费的思想,维护完整的故事列表,事实上也是浪费。

存在的问题有两点:

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

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

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

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


什么时间结束
影响地图会议何时结束
“当关键想法已经出现在地图上。”

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

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

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

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


今天先到这儿,希望对云原生,技术领导力, 企业管理,系统架构设计与评估,团队管理, 项目管理, 产品管理,团队建设 有参考作用 , 您可能感兴趣的文章:
领导人怎样带领好团队
构建创业公司突击小团队
国际化环境下系统架构演化
微服务架构设计
视频直播平台的系统架构演化
微服务与Docker介绍
Docker与CI持续集成/CD
互联网电商购物车架构演变案例
互联网业务场景下消息队列架构
互联网高效研发团队管理演进之一
消息系统架构设计演进
互联网电商搜索架构演化之一
企业信息化与软件工程的迷思
企业项目化管理介绍
软件项目成功之要素
人际沟通风格介绍一
精益IT组织与分享式领导
学习型组织与企业
企业创新文化与等级观念
组织目标与个人目标
初创公司人才招聘与管理
人才公司环境与企业文化
企业文化、团队文化与知识共享
高效能的团队建设
项目管理沟通计划
构建高效的研发与自动化运维
某大型电商云平台实践
互联网数据库架构设计思路
IT基础架构规划方案一(网络系统规划)
餐饮行业解决方案之客户分析流程
餐饮行业解决方案之采购战略制定与实施流程
餐饮行业解决方案之业务设计流程
供应链需求调研CheckList
企业应用之性能实时度量系统演变

如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯,请关注我的微信订阅号:

MegadotnetMicroMsg_thumb1_thumb1_thu[2]

作者:Petter Liu
出处:http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。 该文章也同时发布在我的独立博客中-Petter Liu Blog。

原文地址:https://www.cnblogs.com/wintersun/p/13339322.html