CH1 有价值的产品或解决方案

表面上的交付

按照纯粹定制化软件开发或者外包软件开发的思维，根据甲方的需求，我们交付产品设计文档、产品功能、源代码、测试用户和报告、用户手册和培训文档、数据报表等，以及根据交付物或者人天工作量进行结算。

实际上可能交付负价值的东西

由于软件项目的复杂性，软件供应商可能交付的是毫无价值甚至负价值的东西。
比如下面是我碰到过的一些非常典型的场景：

• 交付的功能不是客户想要的
  • 可能客户以为是这样，但想法变了或者客户这个想法没有价值
  • 也可能是理解错了客户需求
  • 也有可能产品的标准功能就是没有价值的
• 非常低效或者无产出的沟通和交付
  • 由于缺乏主导，或者主导者能力较弱，无法把控整个方向，在实施过程没有清晰的思路，导致整个团队陷入内耗，沟通成本非常高，开各种没用的会议却没有获得清晰的决策。
  • 也可能是整个方案存在缺陷，调研不充分，细节考虑不到位，导致实施、上线、运营过程问题频出，消耗大量资源勉力维持或者修复。
• 由于系统的问题耽误了品牌业务规划
  • 甲方付出很大代价开发中大型项目，通常期望能带来业务上的提升，因此一并会有配套的业务规划和周边配合。由于交付系统的延期或者系统问题，导致迟迟无法达到业务预期，可能导致配套的业务规划和业务活动未达到期望的效果。
• 把客户的数据弄乱了
  • 涉及到企业ERP、订单中台、会员中台、数据中台、商城等类型的项目，通常会涉及到数据迁移或者多来源的数据融合，在数据处理不慎时，可能导致批量导入的数据出现异常，导致客户的数据被污染。而数据通常是客户非常核心的资产，以及很多决策的依据，所以此类问题会给客户带来比较长期的影响。

以上场景可能是多个原因导致的，比如原始需求不清晰、方案存在缺陷、品牌缺乏控制力、供应商能力不足、第三方配合等，无论何种原因，只要客户付费了，且客户觉得没有获得预期的效果，通常都会把“无价值”这个责任归到供应商上。

供应商需要尽全力保障交付的价值

避免一种不好的价值导向

在纯粹人力外包行业、成本相对较透明的行业或者人力附加值相对比较低的行业，通常的结算模型是根据人力投入进行结算：
**价格 = 成本 * 合理的利润率
即：我给你投入了人力或者资源，你就应该按照投入给我结算
这种模式下，会导致供应商失去主动性，不好考虑效率优化，甚至可以通过把成本提高来推高价格，长期下来会降低供应商的价值，甚至被替代。这种情况下，供应商也可能长期在提供低价值的服务下生存，挣辛苦钱。

需要树立价值导向的交付思维

• 产品对客户/用户有价值，客户愿意交易，产品才有有价值
  • 客户愿意付出成本（钱、时间等）的产品或事项的才是有价值的。比如有些客户觉得在沟通协调上花了很多成本，没有实现业务价值，这个时候的出发点可能不是指责客户无法主导高效的沟通，而是站在整体上思考沟通问题的根源，以及如何推送解决这些问题
  • 通过影响某一类人去销售产品，但是产品实际上并不能给客户带来非常大的价值，这门生意也不会长久
  • 产品提供给客户，但是客户在组织和流程上并没有足够的资源去运营这个产品，通常也会带来产品的无效，通常需要在提供给客户产品的时候，同步给出运营建议或者运营实践
• 主动跟客户进行深度沟通沟通，才能真了解客户期望实现的真实业务价值，给出客户他们真正需求的功能和解决方案
  • 响应式的回应客户需求和提解决方案，有时候并不能解决客户的问题，而实际上要分析客户这个需求深层次的业务目的，以及是否还有更好的方式可以满足。比如客户说想做一个微商城，但实际上微商城只是一个手段，目的是更好的积累私域客户以及触达用户
  • 客户有时候只有一个宏观的概念，以及业务上期望，但并不知道具体要做什么，需要去引导细化，变成可以落地的目标。比如某个客户说想做个数据中台，提了一个非常宏观的想法，要我们去报价，那套系统实现下来需要以年度计算的周期，而实际上客户的预算、业务目标都希望能尽快完成部分功能，这个时候就需要帮客户去梳理轻重缓急，进行分歧规划。
  • 帮客户从一个全局角度思考整个解决方案（业务和技术结合，可能还涉及其他供应商），客户最终获益后，也会觉得这个供应商更有价值。这种情况主要是涉及到多方协作，包括品牌内部多方协作，品牌多个供应商的协作等，核心供应商必须从全局视角考虑问题，才能带来项目的成功。
• 不仅仅考虑外部价值，同时也考虑外部实施带来的内部价值，即通过客户的实际使用，验证产品的实际价值，同时产品也可以积累更多标准化业务场景
  • 通常初期规划MVP，满足最核心的业务运营，在客户使用中进行迭代优化，由此尽快对新的业务模式进行验证。
  • 跟进到产品运营环节的使用，跟客户一起完善和打磨产品，对可以标准化的功能报价不用那么“小气”，毕竟客户的经验可以复用到其他品牌。
• 能意识到我们的能力边界：可以做到什么程度，不要崩盘
  • 对商业化软件复杂度抱有敬畏。通常解决内部信息化相关的软件不用考虑太多的并发、运维、安全等因素，甚至体验上也可以不用那么友好，一旦开始商用化后，一个小问题就可能带来较大的外部风险、沟通成本、信任度等。
  • 口碑可能会有双刃剑，某次实施做得好，获得客户的信任，客户可能会给予更大的合作机会。此时去做一些超过当前团队能力边界的事情（包括团队能力无法支撑，或者不符合团队将来发展的项目），可能会带来团队的脱胎换骨，也可能把口碑做差，并可能拖住团队核心人员，丧失进一步拓展的机会。所以为了团队的长期发展，必要时要放弃能力边界外的项目。
• 在技术团队树立商务价值和技术专业同等重要的意识，商务价值变现和技术实现其实是一体的，一个聚焦做的意义（价值在哪），一个聚焦怎么做（实现价值）
  • 在团队内部，也要有价值变现思维，专业的开发、测试工程师也需要关注业务现状，以及长期业务的发展，跟整个团队和业务一起成长，而不要有“技术不对业务负责”的观念。
  • 进行有效的商务沟通和价值判断应该是业务负责人、产品经理、项目经理必须要具备素质。其他产品核心参与人，也非常要必要有一定的的商务素质和业务判断能力。

通过价值导向的思维，我们至少可以确保成为一个负责任、为客户着想、值得客户去进行深度沟通的供应商。

链接：
导言
1. 有价值的产品或解决方案
2. 有价值的沟通
3. 有利可图的销售
4. 价值导向的交付
5. 持续创造价值