2B创业说 | 需求是商业的核心驱动力,而非其它

从创业以来，一直在思考驱动一个2B公司走向成功的核心要素是什么？不同的阶段、不同的人都有不同答案，有内在因素（人、管理、文化），也有外在因素（客户、技术、产品）等等。这些点思考下去，没法形成共性的解释，不同商业模式的公司对这些内外在因素表达和解释都有不同。

前不久也看到一篇文章，认为一个2B企业的驱动过程一般遵循以下规律：技术驱动、产品驱动到销售驱动。看着觉得很有道理，对于一个2B企业来说首先谈的是技术，在第一层构建技术壁垒是最好了；技术打造出一个产品，产品沉淀场景，形成产品壁垒；产品出来后，需要通过销售把它卖到客户那边，从而给客户带来价值。此时我更想增加一个阶段叫需求驱动，需求驱动可以理解成一种高级形式，更应该是一种原点模式，就是那个最初的动力。对于一个创新型企业来说，需求的理解更是成功的关键，而创新的引领点是对客户需求的把握程度。我的思考逻辑非常简单，谁更贴近用户，谁更贴近应用端，谁更了解场景，谁的机会就更大。

贴近用户，是让你知道谁会使用你的产品和服务，给他带去的价值是多少？在IT服务方面，你更需要站在用户的角度去思考他的用户从你的产品和服务中获得了什么，否则IT价值不能体现在业务上。

贴近应用，应用是离用户最近的IT业务系统，应用又分业务流应用和支撑性应用。无法说哪类型应用的价值更大，要看企业交付服务不同而定。谁让应用端能够快速的去支撑用户的需求，谁的市场机会就会更大，这是把IT系统由成本中心变成价值中心的方式。

贴近场景，对于用户角色和应用来说，里面有很多活动进行在其中，我们称之为场景。概括来说就是：who、what、why、when、where、how的描述，场景是有目标的，场景是有对象的，场景是有角色的，场景是有活动的等等。场景里面能够迭代出需求所在。

回到需求的讨论上，从需求的表现类型来说，需求分显性需求和隐性需求，前者是能被客户直接提出，并加以描述的，这类需求有着明显的特征，加以经验判断和纠正则很容易模式化提炼出来，有些是通过问题转换过来的，可以通过调查得出的。我曾经在阿里UC的时候，为了让九游平台提供专业的IT服务给游戏厂家，发起一次调查。现在回想起来，我们错误的预设了服务内容和前提，并以此内容发起问题调查，给到的结果让我很意外——运维自动化不是核心需求而日志分析是核心需求（如下图）。从后续的优维计划的三十家面对面客户访谈得出，客户的真实需求恰恰不是调查的结论。

没有一家公司是通过调查做起来，除了那些做调查的公司。

隐性需求是客户没法直接提出和描述的，类似客户的兴奋需求，无法通过数据统计总结出来的。隐形需求是一种经验的迭代优化，呈现模式于过去有根本性不同，比如说ITIL和DevOps，Docker等等，有对客户已知需求的深刻洞察而迭代新的需求点。

对于一个IT服务行业来说，创业者需要有以下的正确认识：

个体需求和整体需求,拒绝用个体需求代替整体需求，这个在早期很容易陷入的误区。早期很容易被个体需求所迷惑，无论他选择的是与不是，此时有效避免该问题的方式就是多接触客户。同时我们需要笃定的从行业上判断当前的现状和水平是什么样的，坚持通往目标的优化之路是未来的方向。有些客户向你要流程平台，那是不是我要做一个流程平台？当你去做流程平台，你的流程平台和OA、和ITSM流程平台到底有什么不同？有些客户说不要监控平台，那是不是真的不需要监控平台？此时我们需要问自己，这么多年的监控平台真的帮客户有效的帮客户快速发现、定位问题了么？真的提升了业务质量了么？

我在早期接触客户的过程中，就很难识别出用户是不是真实用户？随着客户的接触的不断积累，最后我自己总结了十个维度来评估客户是不是我们的潜在客户/目标客户/付费客户等等，从而可以指导销售可以快速进行决策判断。

当下需求和趋势需求，当下需求是阶段性需求，是满足当下的客户需要，这类需求容易识别和判断，是否该有产品提供还是服务提供等等，容易做匹配。而趋势需求是未来的需求，带着不确定性。这类需求需要丰富的客户服务经验，同时还需要团队不断的站在未来去思考。

当下处在IT模式的升级窗口期，传统的IT模式和互联网化的IT模式DevOps并存，未来相当长的一段时间内，新型IT模式带来的变革力还是非常强的，毕竟传统企业的业务也在转型触网，最终大家都要变迁的新型的IT模式之上，这是未来之势。

对于用户来说，需求是一个提出、引导、满足和创造的过程。

提出需求，客户提出自己的需求，这是当下的实际需要，而往往这些需求是七零八落，全面的。我曾经接触一个客户提出了一个海量的需求框架，通过自动化把过去N年没有实现的想法全部放进去了。从作业自动化到告警处理自动化到容灾切换到数据库管理。对于这种需求，需要有清醒的边界识别能力，拒绝诱惑；然后就是引导需求。

引导需求，提出的需求不一定就是合理的，此时需要对需求进行引导，这个过程是去伪存真和划分边界的过程。核心的准则一定是从组织的核心问题出发，核心问题的解决带来是收益的大幅提升。把需求引导到一个正确的方向和范围之上，才会让项目变得更成功。

满足需求，这是产品和实施服务与客户需求的对接过程，让需求落地。

创造需求，不是所有的需求都是客户提出的，对客户的现状有了前面的对接过程之后，此时就需要有一个未来需求的提炼，从而让未来的需求给客户带来更大的业务价值。

如何才能精准的把握用户真实需求？ 坚持自己的产品和能力边界，或者说叫定位。任何一个IT服务提供方提供的产品能力有两种，一种是单角色多场景；另外一种是单场景多角色的覆盖。

单角色多场景，是满足一类角色的不同场景的需求，比如说测试人员的功能测试、自动化测试、探索性测试、验收测试等等。而单场景多角色，是满足多个角色的相同场景需求，比如说日志分析需求，开发、测试、运维甚至是安全人员都有相应的日志分析需求。这两种策略，我更倾向于前者，一则需求能力很好聚焦，快速迭代优化，避免碎片；其次能力可以很好的形成闭环；第三在商业销售端，可以减少多客户角色带来的沟通成本问题，产品带来的销售碎片。

有意思的是，现在很多创业者打了很多云stack的旗号，从低到上、从前到后完全提供全栈的服务能力（这是一种贪婪策略），想想都知道IT能力的专业化需要很长的时间积累，否则没法去真正引导客户需求。这种策略很容易陷入最后的技术化理解，而无法做到真正的产品驱动。下图是我给的一个标准模型来推导产品的能力如何覆盖。

能力边界是我非常坚持的一点，这个会反向影响你的产品脉络。没有控制好，很容易让你的产品变成项目型产品，缺少行业通用性和适配性。在国内，IT型产品很容易被客户需求牵制住，让产品失去了强势性。

尊重客户的需求和经验反馈，和客户认真的沟通，了解他们的需求背后的动机，不要一味的看着自己的产品能力，让客户来适应。举个例子，我们一直讲运维自动化和传统的ITSM是不是就完全不能兼容呢？我说不一定。在互联网行业来看，越接近应用端，和ITSM的兼容性就越弱，但是到底层就不一定了。其次此时我们不能忽略了传统行业，传统行业还有不同的行业划分，不同的行业对ITSM的要求也不一样。明显银行去掉ITSM那一套变更流程、发布流程根本就不可能。此时要给出融合的方案，在线的自动化方案如何和ITSM做到融为一体，兼顾安全合规和效率的需求，产品上需要做点创新。

这个原则对于产品型公司来说，很难衡量，需要有很强的需求控制力和产品适配能力。

经验是助力也是桎梏，隐性需求的思考是突破桎梏的关键。当下互联网的经验的确体现出优势，但不要让该经验凌驾于客户需求之上，更不能凌驾于产品之上，只因他有好处也有坏处。经验是你领先于行业阶段的时候，此时才是助力，落后于行业阶段的时候，就是桎梏。

需求是企业级IT服务公司的制胜力量，你越了解客户的需求，从项目、产品、销售多个端都能带来成功的收益；你越了解客户的未来需求，你更是拥有了未来持续成功的钥匙。需求的价值最终就是客户的价值！