需求的冰川

在面对客户、面对用户或是面对五花八门的产品时,我有时会忍不住问自己,到底什么是需求分析?这概念好像哪哪儿都有、无人不知无人不晓,又好像深不见底难以摸个透彻。那我们在谈论需求分析的时候,都在讨论些什么?

要谈论需求分析,先要说说需求本身这个概念。在我们的语境中,需求往往包含了两层意思:

  • 用户需求:从用户自身角度出发产生的“自以为的”需求
  • 产品需求:由综合提炼用户的真实需求而产生的符合组织和产品定位的解决方案

这样一来,重点显而易见:真实需求和解决方案。如何挖掘需求、如何确认需求和解决方案我们已经有了很多成熟的方法论。但真实的需求又是什么?如何知道我们拿到的就是所谓“真实的“需求?要想摆脱需求罗生门,无限接近用户真正的需求,让产品从能用到好用,恐怕第一大忌就是“想当然”。

“想当然”,很大程度上等于我们经常在讲的making assumptions。做合理的assumption并积极地验证假设从来不会造成问题;可怕的是没有意识到assumption的存在还自我感觉良好,这大概就是我们中文里“想当然”所包含的意思了。

拿到我们的项目交付语境中,“想当然”是什么?是懒做甚至不做用户调研关起门来做需求;是自以为了解用户也了解客户没经过验证就敲定了需求;是偏听偏信客户爸爸的话说什么就做什么。

用户研究与验证

了解用户/客户是个庞大的课题,当用户体验被不断强调,可能没有人会跳出来否认用户研究和验证的价值。但反观我们的实践,很多时候业务分析师在需求层面上对用户研究和验证的重视还远远不够。

造成这种缺失的一大原因在于角色的割裂。有人理所当然地认为用户研究与验证是设计师的事,毕竟他们的头衔才是“用户体验设计师”。在产品同质化严重的今天,“体验”二字包含的不单是界面好不好看,操作顺不顺畅,更是背后的业务逻辑和痛点把握。如果强行将需求分析和用户调研分割开来,我们所做的需求分析很可能是浮在真相表面的“假需求”,所谓用户体验更是无从谈起。

业务分析师常常被形容为产品和交付之间的桥梁,产品经理把握产品走向,聚焦产品成长;业务分析师则往返于产品经理和程序员之间,专注如何迅速有效地让产品落地。于是,有人理所当然地把用户研究与验证的锅扣在产品经理头上,认为他们作为产品的最终负责人,应该由他们去做用户反馈的收集,再传递给业务分析师。

首先,我们应该承认产品的需求和运营是无法独立存在的,如果业务分析师和产品经理是纯粹的上传下达关系,分析师既不接触用户也不关注反馈,他甚至连“好”的定义都模棱两可,如何能分析好需求又怎么做好一个产品?其次,虽然产品经理们对自己的行业和领域有很深的了解,但对产品的规划设计和交付却很难面面俱到。他们不是不愿意做好用户研究与验证,而是不一定具备这种能力;即使做好了,也很难知道如何准确地把合适的信息传递给业务分析师和交付团队。

我们不止一次地强调“复合型人才”对产品构建和组织转型的重要性,在需求分析领域,用户研究和验证或许是呈给业务分析师的第一份考卷。

“了解用户”无法一劳永逸

在没有直接接触过用户、也没有参与过产品前期设计活动的时候,我曾经想当然地认为“了解用户”是售前团队、产品探索和规划设计团队的事情;我作为交付阶段的业务分析师,只要跟着项目计划保证交付就好了。后来有机会接触了更多项目更前期的阶段,开始认识到事实也许并非如此,但也并没有付诸实际行动。原因再简单不过:项目交付已经焦头烂额,花“额外的”精力去做用户研究和验证只能带来眼见的工作量负载而非立竿见影的成效,更别说有招致需求膨胀的可能,不如作罢。

在产品探索和规划设计阶段,由于时间紧、任务重,我们的用户研究与验证往往侧重在产品概念层面,确保产品方向性的正确。因此,即使在产品快速启动时产出了完整的需求列表和设计,也不意味着他们统统是ready to go的状态;更不意味着在交付的第二期、第三期,可以照搬当时的产出作为产品目标。“了解用户”无法一劳永逸,反之,它应该是持续的:在产品进入稳定的交付阶段后,业务分析师应该继续积极了解用户,不断验证并挖掘需求;用户和环境都在改变,该重新组织产品规划设计工作坊的时候,不能搪塞了事。

我目前所在的团队正在做一个听起来挺无聊的需求:给产品中的某功能换名字。我们的产品旨在帮助企业员工提高心理健康水平,在必要时进行干涉并提供援助。这个产品已经上线两个月,收到了不错的用户/客户反馈,但是从GA收集到的数据来看,发现我们当初产品设计阶段收到正面反馈的一个功能使用率并不理想。团队经过用户研究发现,从某种程度上看,是这个功能的名字出了问题。因为用户大多常常处在焦虑状态,这个叫“Goal”的小功能让人觉得压力山大,commitment很重以至于overwhelming,结果干脆不用;我们将在下次发布中,把“goal”换成“pathway”,让人觉得这是压力生活下的一条绿幽小径而非任务/目标。

Stay hungry, stay foolish

用户研究和验证的方法千千万,我不在这里一一列举。Stay hungry, stay foolish这句用烂了的话,恐怕是我能找到的最契合“BA怎么做用户研究和验证”的原则。面对客户的需求,多问一个为什么;面对用户的答案,多想一个为什么;能最大程度地避免“想当然”,或许就能最大程度地做好“用户研究和验证”

我们常常形容需求是冰川,露出海面的只是冰川一角。写到这里,我忽然想起去年夏天我在某客户的合作工厂做用户测试,工人们因为厂房过于炎热光着膀子也不带安全帽,我趁他们休息间隙想要和他们聊一聊,我走过去蹲在抽烟的人们旁边想要加入他们,但几乎于此同时,大家都站起来离开了。想要融化冰川,或许不只是挖掘那么简单。


更多精彩洞见,请关注微信公众号:思特沃克

Share

浅谈敏捷离岸团队沟通

很多人说,要让团队敏捷, 先让团队坐在一起。没错,“坐在一起”这区区几个字,可以解决团队从沟通到信任到效率提升的不少问题。作为团队的业务分析师,我们很多时候都扮演着产品端和开发端的黏合剂,最理想的工作环境可能是坐在产品团队和交付团队中间;办公室就是大舞台,随时都能展现自己的十八般武艺,把“坐在一起”的效应发挥到极致。

然而,由于种种原因,我们不免会遇到跨文化、跨时区的离岸团队。当“坐在一起”的舒适圈被打破后,很多问题则接踵而来:“见都没见过的团队成员怎么建立信任?”、“人都找不到怎么高效沟通?”、“时区空间不一致怎么组织工作坊?”经历了一个离岸团队的从无到有,淌过了大大小小的坑,笔者将所见所得整理成本文,希望能对同样纠结于此的同行们有一点点裨益。

按需互访

“见都没见过的团队成员怎么建立信任?” 答案恐怕是“无法建立”。别怪我这回答太消极任性,对于远隔重洋甚至黑夜颠倒的离岸团队而言,留言和视频所带来的困惑和乏力往往多过友好度和安全感。尤其对于那些毫无离岸合作经验的客户来说,面对这份未知和“不可控”往往是自我保护甚至抗拒的。

合作双方的互访则是建立信任的捷径,通过这扇窗户,一方面可以了解双方的企业文化、工作习惯乃至个人的性格特点;另一方面能够利用面对面工作坊高效梳理规划,最大程度保证后续项目推进方向的正确性。在条件允许的情况下,在项目伊始就建立互访机制:

  1. 在项目的重要节点,例如合作初始、项目里程碑、检查点进行在岸交流;
  2. 设立双向固定互访周期,如每三个月/半年。

当有机会去到客户现场,该如何充分利用短短数周或是数日?从个人经验来看,你或许可以:

  1. 做好充分的行前计划:不要把它当成签证材料准备中的“例行公事”。海外出差费时费力,为了确保效果,必须提前沟通准备并了解项目干系人的工作/休假安排,重要会议提前发好会议邀请,最好以邮件形式确认你的计划。相信我,你一定不想像我一样,人都到了客户现场以为一切自有安排,才发现接头人马上要休长假,独留“一脸懵逼”的自己。
  2. 尽量结识多的人:哪怕你自认不是“交际花”,哪怕自己的英语不够好,哪怕ta算不上直接干系人甚至来自不相干的团队/部门;当你们未来有工作上的交集,有一面之缘也大大好过冰冷的邮件。
  3. 定期和离岸团队沟通:即使有完整的记录,出差回来一次性输出的效果恐怕也差强人意。就算再忙再紧张,也要定期与团队交流,沟通自己在客户现场的收获,了解团队的问题和想法,并及时反馈到客户现场的工作计划中。

当客户即将来访,该如何抓住深化合作的机会?

  1. 最重要的依然是计划:提前为客户来访的工作内容做好细致的安排准备,双方设置好来访预期和目标,最大程度利用好团队与客户成员共同工作的时间。
  2. 提升对客户的影响力:帮客户站得更高,看得更广。尽力帮助他们在来访过程中更好地感受我们的工作方式和文化氛围,甚至以我们为窗口,介绍目前国内市场上的先进案例和最佳实践。
  3. 为客户做好行前准备和安排:这包括签证准备、交通酒店及个人饮食过敏源等在内的各类生活细碎。很多客户并没有到访中国的经验,对这个陌生又熟悉的国家甚至存在很多误会和担心。我们可以简单准备一份包含城市介绍、物价水平等信息的行前小材料,让他们不至于在踏上飞机前对即将来访的城市一无所知。

搭建沟通框架

对于“坐在一起”的敏捷团队,沟通会在工作和相处中自然而然地发生。而当我们所处的是一个离岸团队,很多沟通问题则会因为物理位置、语言文化障碍、时差而被放大;最危险的可能是,你不知道你不知道;而某些沟通隔阂可能会在某些时刻产生致命的影响。在项目初始就定义好沟通的渠道和方式在这样的环境下显得尤为重要。简单来讲,我们最应该关注的是:谁和谁沟通,通过什么形式沟通,达成怎样的目标,要有怎样的沟通频次。

(在项目初始与客户达成对重要会议的一致理解)

(对团队成员之间的沟通渠道需要统一和确认)

巧用工具

“时区空间不一致怎么组织工作坊?”针对这个问题,恐怕不仅仅是需求分析相关的工作坊,离岸团队的种种限制对我们许多熟悉的组织技巧和习以为常的敏捷实践都提出了挑战。互访是类似昂贵的特效药,而真正要身体好,还离不开悉心的日常调养。合适的工具,则是这里的关键。

1.Always On:如果能有超过四个小时的工作时间重叠,Always on一定要有。实时视频能增加许多亲切感和趣味,拉近团队成员的距离;更能让包括站会、desk check在内的很多敏捷实践变得容易。有了Always On,信息不回抬头喊一喊,开会了朝屏幕招招手,方便直接,也算对得起客户给的“魔镜”名号。

2.远程协作编辑软件:市面上的远程协作软件让人眼花缭乱,在这里分享几个你也许正在寻找的:

  • Keynote-Collaborate Mode: Keynote算得上我们目前使用最为频繁的演示软件,而它的Collaborate Mode这项高能技巧好像并不是那么知名。协同编辑除了能在紧张的项目节奏中提高团队效率,还可以帮助在重要演示环节/工作坊中与客户进行快速确认。举个例子,如果有两人共同参加工作坊,一人作为组织者与客户交流,另一位则可以实时将产出记录到Keynote中,在工作坊结束前第一时间呈现给客户进行确认。

(只需点击标题右下方的Collaborate,输入你要协作编辑对象的iCloud邮箱,即可将当前文件分享给对方进行协同编辑)

  • RealtimeBoard: 如果让我列举“2017年度最好用工具”,RealtimeBoard一定榜上有名:它是我目前能找到的最好的sticker board,是组织远距离工作坊的最佳搭档。除了最常用的反馈会议、头脑风暴外,RealtimeBoard提供了许多针对不同场景的实用模板,例如用户故事地图, 产品演进路线。

(RealtimeBoard: 五花八门的实用模板)

(团队的第一次远程回顾会议)

3.即时通讯工具:每个人每天都要用到,自然必不可少。 在与海外客户的合作中,常见的主要有Skype, Lync(Skype for business), Slack,HipChat, Hangouts等。目前我们项目正在用的是Hipchat,比较突出的亮点是不用翻墙、可以与Jira, Github集成,缺点主要是记录保存时间较短。

4.项目资产管理工具:个人认为,离岸团队要比在岸团队更加注重文档,良好的文档整理能降低沟通成本,也让沟通有迹可循。关于用户故事/电子看板,常见的有Jira, Trello, Pivotal Tracker, Mingle;关于其他项目相关文档管理,一般使用Confluence, Google Drive, DropBox等。

文化互通

文化差异是每个海外合作团队所必须面对的。由于文化背景的不同,团队成员们有不同的语言体系、做事方式,继而对合作产生一些显而易见或者不知不觉的影响。它本身是一个中性词,甚至褒义词:两种截然不同的文化碰撞,让我们能够交到大洋彼岸的朋友,了解彼此的文化,是多么幸运的一件事。而它也有可能成为“问题”:因为缺乏了解,导致双方产生误解甚至不信任,影响健康的合作关系。

承认并沟通合作双方的文化差异永远不会太早,在项目开始前/初期就应该主动地向客户介绍我们的文化:这包括了大文化,即国与国之间的文化差异,例如中国人可能会相对内向,不说话并不代表没有关注讨论;也包括了小文化,即组织和团队的文化差异,例如我们会相对自管理,不存在传统的上下级观念。

我们总是在谈论良好的团队氛围对项目成功的重要性。良好的团队氛围永远不是从单纯的工作沟通中来的,而是必须来自于每一个活生生的人。当团队成员之间建立起个人关系,很多问题都可以迎刃而解。

(当遇到文化碰撞,团队里需要有人挺身而出)

以上寥寥几点来自笔者有限的项目实践,不免有所遗漏或有待商榷。但毫无疑问的是,离岸团队需要更用心和精巧地经营,而成功也往往离不开各个角色的配合与贡献。


更多精彩洞见,请关注微信公众号:思特沃克

Share