前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >资深BA进阶工具包:构建“Big Picture”的四幅图板 | TW洞见

资深BA进阶工具包:构建“Big Picture”的四幅图板 | TW洞见

作者头像
ThoughtWorks
发布2018-04-20 14:25:26
7310
发布2018-04-20 14:25:26
举报
文章被收录于专栏:ThoughtWorksThoughtWorks

今日洞见

文章作者来自ThoughtWorks:亢江妹。

本文所有内容,包括文字、图片和音视频资料,版权均属ThoughtWorks公司所有,任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表。已经本网协议授权的媒体、网站,在使用时必须注明"内容来源:ThoughtWorks洞见",并指定原文链接,违者本网将依法追究责任。

我们常常说“要有Big Picture”,那么究竟什么是“Big Picture”呢?

假设你在项目组X工作了差不多有三个月了。设想有以下几个场景:

场景1:厨房偶遇ThoughtWorks中国区总经理松哥,松哥问:“听说你在X组?这个客户什么情况,咱们现在具体做什么呢?”你如何能在5分钟简明扼要地把这个客户的情况说清楚?

场景2:你受邀参加了一个外部大会,在活动间隙,有一些人听说你在ThoughtWorks做一个XX产品,表示出了兴趣。你如何介绍这个产品,进一步勾起他们的兴趣?

场景3:有一个新成员刚加入项目,需要请你把项目的情况花个15-20分钟给他简要地介绍一下。

场景4:在一个客户会议中,突然客户老板点你的名说,“XX,请问你能简要地给新加入我们业务部门的约翰先生介绍下我们目前产品和当前进度吧?”

这四个场景,分别是从客户、项目、产品、需求全景的角度在发问,刚好形成了“Big Picure”的一个基本框架。作为软件项目组的一员,所谓“Big Picture”就是对客户、产品、项目、需求有一个简洁明了的认识,脑子里对这四块有一个清晰的蓝图。“Big Picture”不是看不见摸不着的,下面就将给大家介绍四幅图板,帮助你让“Big Picture”现形。

1

"Big Picture”之客户—客户图板

场景1看似个很简单的问题,不就是介绍客户吗,但只要经历过的人知道,要三言两语介绍出关键点,是需要功力的。那么多信息,说什么?用什么词说?按什么顺序说?这里给出一个基本招式——“客户图板”:

在这一客户图板中,有6个关键区域,提出了6个关于客户的关键问题:

  • 客户是谁?一句话来介绍客户,通用句式“XX是[概括市场地位的形容词]的[核心业务和服务]公司"。以介绍我们公司为例,比如“ThoughtWorks是一家全球领先的软件开发与咨询服务公司”。
  • 客户的核心产品和服务。客户有哪些核心产品和服务(尤其是市场上有知名度的、有特色、值得一提的)。
  • 客户当前的市场地位如何?用一些让人一听就明白的数据指标,比如介绍顺丰,“顺丰速运目前总市场份额占第二,高端速递排名第一......”;也可以加上主要竞争对手。
  • 客户的愿景、目标?一句话来描述客户在长期的发展愿景。知名企业一般主页、网上新闻一搜都能搜到。
  • 客户当前面临的问题和挑战?现状与愿景之间的差距。
  • 客户的战略和机会?我们(ThoughtWorks)帮客户做什么?客户自己实现愿景的战略思路是什么?落脚到客户对我们的诉求,为什么跟我们合作,想从我们这里得到什么?

把这些问题的答案概括凝练成简洁的关键词、关键点,可视化在一幅图板上,尽可能让所有人(甚至包括客户)时时刻刻都能看到;任何人如果发现上面的信息不准确,就可以触发讨论,因而保证大家看着同一张板子,在同一个Page。

2

"Big Picture”之产品—精益画布

我们目前不管是哪个组,实际上都在某个产品上工作,只不过是2B和2C的差别而已。从产品角度来说,把握Big Picture,第一能概括产品的“魂”的当属精益画布(Lean Canvas)。这已经算是大家非常熟悉的工具,所以废话不多说,直接上示例:

  • 关于使用这一图板,大家可能常有的疑问是说:“这不是在产品创意之初才使用的工具吗?我现在都是在维护产品了,做这个是不是没有用处?”

记得之前 张玳(扩展阅读:《TW洞见 | 张玳:什么是服务设计》)分享过一个经历,是说咱们到客户现场做启动项目,其中一个环节是进行一个商业模式画布的讨论,客户说“你们觉得这商业模式是在这里讨论出来的吗?...” 使用工具的目的是验证我们的思考,工具本身并不能产生好产品创意。从验证和分析的角度来说,在产品生命周期的任一阶段,都适用。更重要的是,在涉及到客户、用户、客户的不同部门、甚至客户的客户、以及合作伙伴如我们自己这么多人合作的团队里,我们往往以为“我们对产品的方向的理解是完全一致的”,很不幸这是错觉。我们需要一块把各自脑子里的假设可视化出来的图板,迫使大家去思考、去争论,达成真正的一致。况且还有一些组,因为种种原因,在产品构建之初就没有形成这样一幅板子、也没用精益产品这样的方式思考过。在任何时间点,我们都可以用这样的思维来重新审视我们正在做的产品,指导我们的决策。我就曾经利用这个图板来帮助砍需求。我们所做的产品是服务于呼叫中心的CRM产品,因为所有的呼叫中心人员都要访问这个系统,所有曾有客户各个业务部门需要再这个系统上添加保单特殊处理流程。当摆个图板架构明确出这个产品的“界限”在哪里的时候,客户就自觉把那块需求放成低优先级了。

  • 可能还有的人会问:“我们不太方便于让客户参与进来,但光凭我们,想破了脑袋也填不出来这个怎么办?”

这类图板更多是一个分析和思考工具;思考的过程比结果更重要。所以只要团队(哪怕只有我们没有客户)开始在用这种方式思考、在不停讨论,就是在进步。当找不出答案的时候,我们就会去做更多地调查挖掘这产品的来龙去脉;做更多地研究,国内有没有类似的产品,是怎么回事?在这过程中得到的收获会非常大。

退一步,如果实在想不出来,不放大胆推断和假设,然后再在后续工作中验证自己的推荐和假设是否正确;不要怕图板展示出来别人笑话,别人觉得“不对”才会激发讨论,大家从而找到更为“正确、一致”的理解。这才是图板真正的意义所在。

3

"Big Picture”之项目—项目图板

无论是什么样的产品,要真正落地,就必须受到钱、时间、资源的限制,所以还是会以“项目形态”进行管理。那么获得项目全景也成了Big Picture的一个重要部分。回到最开始提到的场景3,如何向先加入的新人,简要地说清楚项目的轮廓呢?

  • 客户为什么要做这个项目?简单列出项目要解决的问题和业务价值。
  • 这个项目的成功标准是什么?列出项目成功的衡量指标。比如预期每月新增客户10%等。
  • 项目的方案是(综合业务和技术)?简要的方案,不需要列任何细节
  • 项目主要需要完成什么/大致范围?非常粗粒度地列出哪些是明确必须做的;哪些是范围之外的;哪些待定的。
  • 项目的决策优先级如何?质量、时间、预算、范围、体验等当这些因素冲突时,舍谁保谁?
  • 客户的负责人是谁?相关的重要干系人?不要让这些关键人物名单只藏在PM的脑子或记事本里,人人都清楚,有这根弦。
  • 项目的里程碑计划如何?注意是里程碑计划,体现关键时间点和目标信息,而不是发布计划(每个迭代做哪些需求)。
  • 主要风险、假设、问题和依赖?

上工具“项目图板”:

同样的,如果不是格外敏感的话,做个物理图板放在工作区,最好人人抬头都能看得见;并及时维护,保持信息的准确性。

4

"Big Picture”之需求—需求全景图板

在构建产品的过程中,所谓目标的完成、价值的实现,最直接可以看到的就是需求全景,以及针对全景的进度。前面精益画布和项目图板都有所涉及,但粒度上还不能达到“一览需求全貌”的效果,所有还需另外的需求全景图板。构建需求全景图板的工具有很多,比如故事墙、比如用例全景图、产品功能图谱,只要能全面、完整地表达出产品需求就可以。

下面直接给两个示例:第一个按故事墙;第二个按功能组织。

除了提供需求全景之外,这个图板还有以下几个好处:

  • 可以在图上标记哪些需求完成,直接提供了一个可视化的“进展”图;
  • 建立了需求之间的有机联系,久而久之,大家闭上眼,不用参考这个,就能勾勒出需求的内容
  • 可以作为自动化验收测试或回归测试的重要参考
  • 当用户想加“不重要”的需求的时候,可以带着客户在这板子上过一遍,让他自己发现新的这个不那么重要、或者换个其他不那么重要的下来。

5

最后

借助客户图板、精益画布、项目图板、需求全景这四个工具,怎么应对最开始的四个场景,相信大家已有答案。

这四幅图板,提供了从客户业务、产品、项目、需求四个角度的全景蓝图,让所有人“On the same Board, on the same page”; 随时有这样的“Big Picture”做背景参考,日常遇到的种种针对于某个细节的难题或纠结,也会迎刃而解或直接消失遁形,“胸中有丘壑,叶纳百万兵”。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2015-10-29,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 思特沃克 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档