作者 / 李宽wideplum · 排版 / 不萌
对于这些盲点我们能做些什么呢?意识到它们的存在是一个开始。接下来是识别他们。这需要对客户的业务环境有更广泛的认识,对 B2B 产品有全面的理解,并更好地把握 B2B 用户的需求。
这些目标大致可以分为两类:
1. 减少与客户的距离
2. 缩短内部职能之间的距离
随着企业规模的增长,保持效率所需的劳动分工导致了客户和开发团队之间的多层次结构。在大型企业中,遇到从未与客户或终端用户交谈过的开发人员并不罕见。
有几种方法可以减少这个距离。
企业的分工也造成了“竖井”。虽然小型(孤立的)团队在他们的本地环境中高效运作,但是他们在大型产品环境中的输出可能会在意想不到的地方显示出裂缝。竖井还会增加专业化,特定职能领域的专家通常不具备检测跨职能流程中的问题的能力。
要找出这样的盲点,你需要多面手: 那些在不同职能上花了不少时间的人,他们可以有更广阔的视野。David Epstein的著作《Range: Why Generalists Triumph in a Specialised World 》说明了为什么在知识经济时代,解决复杂问题需要人们看到不同领域之间的联系。由于视野狭窄,专家们无法识别和突破这些盲点。
对消费者来说,没有什么地方比产品的用户体验更能体现竖井的影响了。
培养多面手和处理“竖井”效应可以通过把不同职能的人聚集在一起来实现。DevOps 方法——它使开发和运营人员彼此更加亲近——是跨功能实践的一个很好的例子,现在已经编纂成为一个软件工程原则。为了识别从竖井中出现的盲点,我们需要更多这样的跨职能联盟: 跨工程和客户支持,跨工程和用户体验,等等。
用户体验(user-experience,UX)角度值得更多的关注,因为没有什么地方比产品的用户体验更能体现竖井的影响。用户体验是产品行为表现出来的地方。
但问题不仅仅在于用户体验功能。与用户体验相关的盲点也可能起源于与用户界面无关的决策。例如,团队对技术堆栈的选择可能导致与其他应用程序或产品的集成不良——这在生命周期的早期是看不到的。为了解决这个问题,用户体验必须与所有生命周期阶段涉及的不同功能紧密合作。正如有人所说,设计太重要了,不能留给设计师去做。
盲点也出现在我们对用户体验的理解的边缘。当重点放在确定应用程序核心的用户体验问题时,可能会忽略边缘上的有问题的方面,比如找到访问应用程序的位置、如何配置应用程序、获得正确的用户权限等等。用户体验需要解决整个产品生命周期,而不仅仅是应用程序的运行时间。这也需要跨职能的方法。
找出盲点本身就是朝着解决这些问题迈出的一大步。在这个阶段发现的见解可以引出解决方案的想法,而用于确定盲点的方法通常会提供如何解决这些问题的方法。例如,跨职能团队是修复这些职能之间边界上出现的盲点的理想构造。客户协同创新项目不仅帮助 B2B 软件供应商了解客户的环境和需求,而且也是满足这些需求的地方。
其中一些方法在小规模的团队中很容易实施。缩短与客户的距离是每个团队都可以做的事情。其他方法需要利益相关者网络之间的协作努力。
这种跨职能的协作更多的是例外而不是常态。组织结构通常是围绕单个功能设计的,很难绕过这样的结构。这就解释了为什么许多盲点仍然存在,即使它们的存在是已知的。有时需要一个战略性的、自上而下的命令来解决这个问题。回想一下前面提到的停机时间窗口示例: 这样的问题只能通过公司范围内的活动来解决,以对齐这些停机时间窗口。
到目前为止,我们所看到的 B2B 供应商中的盲点并非一次性问题——它们源于 B2B 软件领域存在的系统性问题,而且与 B2B 软件业务本身的性质密切相关。
采取一次性的战略举措来解决具体问题充其量只是一个临时的解决方案。只有文化的转变才能产生持久的变化,并导致能够在出现盲点时识别和处理盲点的行为。我们需要的是一种在整个公司都重视的文化,一种有意识的、持续的关注与客户和他们的用户保持亲密关系的文化; 一种培养多面手的文化,他们能够发现专家们遗漏的东西; 一种优先考虑定期的跨职能协作的文化。
换句话说: 为了确定和解决 B2B 软件行业普遍存在的盲点,需要采取持续的长期办法。
---------
长按下图二维码即可进【ToB行业交流群】
推荐阅读
点击图片即可阅读
▼
觉得有价值,点个“在看”,和朋友们一起成长