本文讨论技术层面的问题，背景、预算等不在讨论范围。
本文讨论的是定制化项目开发实施的售前问题，而不是标准化产品的售前。
本文面向我们的销售和售前团队，有些需要的信息，需要客户配合调研才能完成。

项目真正发起者

了解谁是真正发起者，有助于我们初步判断项目的目的。有可能的情况下，尽可能与项目的直接发起者沟通，了解项目的高层次目的或根本目的。
了解项目的根本目的，有助于我们判断项目难度和成本，而不被表面的工作量所迷惑，做出远超客户预算的报价错失项目。
什么是根本目的，什么又是表面工作量，我以一个用于生产企业的生产管理软件为例，简单粗暴的归纳：

• 表面工作量
  生产工艺、流程的电子化，生产过程管理事无巨细的电子化，车间零零总总的设备对接。力求完美与准确。减轻车间生产者与管理者的工作量。

• 根本目的
  企业一把手希望深化对生产部门的管理。

如果以表面工作量来估价，甚至恨不得马上把最先进的技术与理念销售给客户，成本与价格必然高昂，错失项目，项目的发起者根本没考虑这么多。在这种情况下，你所有的科普都不会有太好的效果，会给客户造成一个“你就是想赚我钱”的认识。销售先进的技术产品需要过程，不可以一蹴而就。

如果我们把所有的工作都只围绕根本目的去做，就会发现，没那么难。那些琐碎的细节都是可以不做的，所谓减轻基层员工的工作量也不重要。我们只要通过技术手段采集好订单信息、产量信息，质量信息，大老板就点头了，才有可能获得信任继续合作。这样我们就可以在初期大幅度降低报价促成项目落地，项目的实施过程也会有的放矢，避免成本超支。

只有知道了项目的真正发起者，根本目的，才能正确的评估与报价。

项目干系人

若要实施项目，可能会涉及哪些部门。在项目管理学科上有一种技术叫做“干系人分析”，我们把项目干系人分为四种类别：

• 权力大、关注度高
  重点管理、争取支持。

• 权力大、关注度低
  令其满意、争取支持。

• 权力小、关注度高
  随时告知、获取支持。

• 权力小、关注度低
  保持关注，防止关注度变化。

常规来讲项目干系人分析在项目启动之后由项目经理负责。但是我认为在售前阶段，就必须开展一定的前期识别工作，这对项目成本的评估和报价有非常重要的影响。权力大关注度高的干系人多，势必造成项目成本攀升甚至飙升。

所以在售前阶段，就要做好初步的干系人分析，整理好干系人清单，一方面与客户不断沟通，完善修正这个清单，另一方面与技术开发实施团队保持沟通，正确传达。在整理干系人清单的时候，要与各个干系人直接沟通，正确的理解他们的期望和关注的原因，关注的点在哪里。特别是要分析好不同干系人的期望之间可能会存在的冲突。在项目开发实施阶段，要解决这些冲突的成本也是高昂的。

管理软件本质上是管理手段的化身，任何企业管理没有矛盾和冲突是不可能的，售前阶段评估的越准确，项目成本预算就越准确，给客户报价时，也能有理有据，取得信任。

项目范围

说白了就是要干的活。理论上来说这是售前阶段必须要明确的，要列为合同附件的。这里最容易产生的问题是项目范围宽泛，抽象，而解释权掌握在甲方手中。虽然任何项目要求售前团队完全明确项目范围，是不可能的，但依然应该尽可能的，尽最大努力的去做好范围识别。

举例来说，客户要求项目能够把现有的管理流程，在系统中实现。那么就要问清楚：

• 有哪些流程？
  不是宽泛的“财务审批”，而是具体的就财务审批来说，又到底有哪些流程。我们未必能在售前阶段彻底搞明白流程的细节，但至少要有一个清单，知道有这么一回事的存在。

• 涉及哪些部门？
  有许多流程是跨部门的，这就容易导致部门之前有一些矛盾冲突存在，也许在长年的工作中，大家达成了某些默契或是潜规则，来处理工作中的一些问题。一旦上了管理系统化，如何调和这些管理流程上矛盾或不合理的地方？这可能需要开发实施团队付出大量的精力和成本。说起来这是甲方自己的问题，需要自己去解决制定好管理流程，但作为乙方我们去陪跑，也是需要付出成本的，这是不可忽略的项目成本。如果搞到最后甲方说无解，那我项目就不验收了？不给钱了？

这样的例子还会有很多，各个模块都会存在这类问题。所以项目的范围说明，不仅仅也不能只是一个“功能清单”，它必须是一个“项目范围说明书”。这项工作不仅仅是对我们自己负责，也是对甲方负责。

拿我们最近做的在线客服系统来说，我们在第一时间，就做好了详细的范围说明书

https://blog.shengxunwei.com/Home/Post/9b667212-565c-43a8-8379-bd0b832a3720

我们销售的到底是什么

这是我们售前团队自己首先要理解的一件事。并要把这个理念，传达给客户，获得客户的认可。

我们销售的不是软件，我们销售的是服务。

我们做的是定制化软件系统开发，不是标准化产品，我们的成本是由这个服务的过程产生的。客户要付的费用，是这个服务过程的费用，而不是交付物的费用。

我们先理解一个概念：什么是产品范围，什么是项目范围。

• 产品范围
  我们的交付物，比如交付 MES 软件、OA 软件。前文讲的“项目范围说明书”，关注的是这一部分的内容。

• 项目范围
  为了完成所要交付的产品，所要做的所有工作，这里我不讨论技术层面的工作，只讨论客户能够理解的项目层面的工作。
  ** 需求调研：与所有相关部门、干系人讨论交流、开会讨论、写文档、画流程图、再循环继续开会讨论、修改文档。
  ** 原型设计：根据需求文档，设计原型界面，与所有相关部门和干系人沟通确认、调整修改、讨论听取意见，循环反复。
  ** 修改反工：客户的想法变了也好，领导的个人喜好也好，需求调研没有做到位也好，干系人理解错误也好，对错不重要，重要的是这也是我们项目工作可以预见的一部分成本。
  ** 部署实施：涉及到人员的差旅、软件的安装调试、试用期间人员的在场支持。
  ** 后续支持：使用期间的技术咨询、技术支持等等。这不等同于运维服务，运维服务可能是有合同有费用的，后续支持则是一个宽泛的概念，电话或是微信上咨询一些使用问题，三不五时来一波，都会消耗我们的人力，遇到项目紧张的时候，就会影响我们下一个项目的工作。

这其中需求调研和原型设计的成本巨大，在复杂项目中，占比超过开发实施都是可能的。有些大型项目会把这部分工作单独做为咨询项目立项，可见其复杂度。

我们做定制化信息化项目开发实施，销售的是这一体化的服务过程，必须使客户理解这个概念，才有可能使客户认可我们的报价，理解我们的报价。