|
这是项目经验的第二篇推文。 我们接上一篇谈谈去年第二个项目。这是一个购买市面成熟软件产品的项目。 今天我们会从项目选型、实施、可持续性合作，分别谈谈甲方项目人员在这类外购软件产品项目的注意事项。 注：1、下面内容的项目选型、可持续性合作不属于工程学科的内容，偏商业，因此不少内容仅代表个人观点； 2、这里谈的内容有其适用场景：适用于每年有IT预算的甲方（这代表企业有IT投入的共识）； 3、这里谈的主要是方向、原则性的内容，不讲操作细节。 项目选型 企业在经营过程，会有各种各样的信息化需求。作为甲方IT负责人这时的首要任务是判断：这个需求在市面上有没有成熟的产品方案？ 为什么这是最首要的任务？ 不少人有误区：认为企业有自研能力走自主开发或再不济自行设计后找外部开发，这才代表有创新、有知识产权、有故事可讲。 如果大家对大部分企业经营的目标是利用合适的资源创造更大的效益有统一的共识，那么企业在做信息化选型时，应该把投入产出比作为主要衡量标准。 以我曾经在软件企业的经历，一套大型软件产品是软件企业花费数年，投入上百人的劳动成果。 这样一套产品集合了软件企业多年累积下来的客户案例经验，借鉴了其他成熟产品的体系，反复打磨、验证才推出来。 这里再具象化说说一套成熟的产品所涵盖的体系是指什么？ 如果你留心看看软件厂商对一套产品的设计理念介绍（注意：这个往往不是吹嘘，一套成熟的产品必定有其清晰的设计思路），会看到类似如下的内容： 比如， 某OA产品：定位为协同办公，采用轻前台，重后台的设计模式。 那么产品具体如何设计？ 协同办公：之前我们讲过企业存在的意义是在当今的工作中，企业组织一群人能创造出比一个个独立的个体更大的价值。一群人聚集在一起，就需要协同配合，协同办公这个设计理念就源于此。软件厂商根据这个定位就要判断哪些做？哪些不做？ 轻前台、重后台：这句话怎么理解？用户在前台，应该根据用户所需，提供易用、够用的产品。但2B产品要满足不同企业的个性化管理、业务需求。这就要为IT提供庞大的后台来满足前台的需求。这个设计理念将是整个产品的设计基础。 某CRM产品：基于移动互联、社交网络、云计算，采用销售机会漏斗模型… 移动互联：代表产品的用户前台主要通过移动端 社交网络：说明产品考虑社交属性，用户、客户可在产品上进行交流。 云计算：代表这是一款Saas产品 销售机会漏斗模型：这是一个被写进教科书的商业模型。产品基于这个商业模型进行设计，用户在使用这个产品时就会发现模型串起了整个产品的功能设计。如果你的销售管理和产品设计不匹配，跑都跑不下去。 任何一套成熟的产品都有一般用户意识不到的理念、体系、模型、方法论等背后的内涵在产品里面。绝不是一般用户表面上看到的一个个独立的模块、功能、页面拼凑而成。 这样一套产品需要业务专家、产品专家、架构师、程序员多个工种的配合。 一个主营业务不是软件业务的甲方企业，想通过招募几个程序员，简单地开发一套复杂的软件，往往是还没摸清这里的坑有多少，，项目就已经进行不下去。 就算真的实现了，往往也只能满足企业当前需求。一旦业务变化、发展，软件就会陷入天天修改的局面，最终往往发展成越来越改不下去。 这时，甲方企业不得不又重新到市面上选择成熟的软件产品。 那么从投入产出比考虑，怎么样做选型比较合适？ 个人建议： ＊市面上有成熟的产品解决方案的，优先选择 ＊市面上找不到直接匹配的产品解决方案的，选择近似的平台产品 ＊市面上完全找不到相似的产品方案，才组建项目团队自主开发 完全自主开发是最后的备选。企业到了成熟阶段，对信息化需求会呈井喷式，有些个性化需求确实在市面上找不到匹配的产品解决方案，这时组建内部开发团队，可以快速响应业务需求。 这里再提下互联网企业为什么都喜欢自主开发？ 目前大家熟知的互联网企业，大部分是做2C业务。这些企业大部分属于商业模式创新。它们的特点是业务创新，这类业务在市面上找不到匹配的产品解决方案，所以只能通过自主开发。 而开发的产品就是支撑企业业务运作的基础，这往往让大部分人把互联网企业统一看成科技公司。 如果单从淘宝、天猫的电商业务来说，软件并不是这家互联网企业最重要的部分。电商业务的核心是运营策略+资本投入，软件是实现经营战略的落地工具。 互联网企业的内部管理软件比如OA、HR、财务往往也不是自主开发，还是会考虑选购市面上成熟的产品解决方案。 项目实施 外购产品的实施是项目成败的关键。 那么实施过程又有什么注意事项？ 1、尊重产品原本的设计理念 前面我们谈了一套成熟的产品必有背后的设计理念。如果要挑一套产品的缺点，市面上没有一套产品是完美的。 甲方项目人员在项目选型时，要做到明确自己的需求，匹配市面上对应的产品解决方案。 一旦在这个环节确定好了产品，进入实施阶段，就要转变心态：由挑厂商变为与厂商同舟共济，这有点像招人、相亲。 那么甲方在实施阶段如何与乙方更好地沟通呢？ 尊重产品原本的设计理念是个不错的建议。作为甲方项目团队先做到尊重乙方的产品、经验。项目团队在遇到用户提出问题时，就能换位思考，产品是怎么样解决问题？为什么是这样实现？ 但这绝不意味甲方项目团队要包庇乙方产品的缺点，而是要先试着去理解产品为什么是这样，再提出不同的意见。 很多的甲乙方之争，往往不是需求与产品不匹配，而是甲方坚持应该采用自己认为的某个方案，而乙方的产品提供的是另一种方案，或者说能变相解决需求，但只是达不到甲方要求的标准。 关于如何解决需求与产品不匹配，这里提几个解决思路： ＊预算允许或力所能及的范围，优先选择平台型产品（平台型产品乙方实施团队、甲方IT可自主实施的空间大，能更好满足业务需求） ＊甲方项目团队要能描述清楚准确的需求，及建议解决方案，便于乙方实施团队能更好地内部沟通，争取到开发资源 ＊甲方项目经理要能判断需求的优先级，将资源给到高优先级的需求，再考虑优化性需求（根据实际情况而定）、搞定无差异化需求（说服用户） 2、界定清楚甲乙方的实施权责 这里特别想对甲方项目团队说明3点： 2.1、甲方项目团队要负责向乙方提供从需求调研到方案确认的一系列配合工作。乙方刚进入项目，需要甲方项目团队的配合来迅速和业务单位建立起信任、合作。 2.2、甲方IT实施要具备把业务需求转换成实施方案的能力。如果想单纯靠乙方提供出令甲方满意的方案，这只能说：可遇不可求。 甲乙方虽然在项目实施有共同的目标，但我们也要看到甲乙方往往背后还有不同的考核标准（比如乙方公司会对项目团队有人力、成本、时间等约束）。这时甲方的实施团队就要能有理有据地说出为什么我们要求的实施方案是这样，维护甲方公司的利益。 这也是甲方要组建自己实施团队的价值所在。 2.3、对甲方IT实施团队的工作要求是：确认清楚具体实施方案，比乙方更熟悉业务需求。乙方团队熟悉自己公司的产品解决方案，更善于将方案成功落地。这是双方各自的职责。如果双方没有统一的权责划分，实施过程就会不断磕磕碰碰。 可持续性合作 关于甲乙双方在项目验收后的可持续性合作，这是大家比较容易忽略的点，这里特别拿出来讨论。 1、新需求合作 2B项目有个特点：一直都会有新需求。用户总是追求更好的工具来满足自己的惰性，这也是人类进步的源动力。 软件作为一类工具，用户也有同样的需求。 在项目验收时，甲方项目经理就要思考验收后双方的合作模式？哪些需求由内部实施团队完成？哪些需求需要乙方来配合？如何让乙方高效地配合？ 2、甲方的年度IT预算 甲方的年度IT预算是与乙方建立长期合作的桥梁。 2B项目一旦成功上线，甲方IT团队就要考虑未来每年要投入该项目的预算。如果方便的话，最好是可以提前和乙方沟通，让乙方也提前有准备。乙方往往也会将这类型的甲方视为长期合作伙伴，在资源上对甲方有所倾斜。 对于乙方来说，老客户的预算是个相对稳定的收入来源，与其不断挖掘新客户（还不知道成不成），还不如服务好优质的老客户（成本更低，收益可见）。 3、持续合作 我自己见过不少甲方更换软件厂商的案例，为什么甲方会下定决定更换厂商？我们可以用俞军的用户价值公式： 用户价值=（新体验-旧体验）-替换成本 用户能下定决心更换一套使用了数年的软件，一般无外乎现有产品已经跟不上公司业务发展；或者说原厂商的服务差，无法响应甲方的需求。回到头，几乎都是产品不能满足甲方需求。 甲方会痛下决心替换产品，这是考虑重新实施的资金成本，人力、时间、风险等诸多成本。实际上，甲方也希望乙方的产品能不断满足业务需求，不用替换产品。 那么甲方业务在发展，乙方如何不断满足甲方的需求呢？ 一套好的产品的生命周期应该是持续迭代，有时为了解决前期的设计考虑不足，甚至要重构。 这一点只能说我作为一名从业人员的理想：乙方的产品要比甲方的业务发展走在更前面，才能与甲方相伴相随。 小结 今天关于项目经验——外购产品解决方案的3点分享：项目选型、实施、可持续性合作就谈到这。 这篇文章同样很长。感谢你耐心读完。 关于去年2个典型项目的经验分享就到这。希望在你的工作中，对你有启发作用^0^ （完）
|
|
|
