S1项目-项目与产品

Saas，做产品还是服务？理想情况是，做标准化产品，通过配置项及少量开发满足个性化需求，以最小边际成本，快速复制、推广。这要求产品足够成熟，一是已涵盖了相应行业的最佳实践，案例足够说服力；二是产品技术成熟，支持客户自己做扩展功能的开发及维护。产品与项目，存在复杂的依赖关系。做项目交付的有个比喻，选产品如同选另一半。产品好坏，很大程度决定项目的难易程度。产品不够成熟、理念存在问题，即使是资深级项目经理，也得摇头叹气，巧妇难为无米之炊。而另一方面，产品迭代，需依靠项目实施过程的反馈，汇总共性常见，纳入产品标准功能开发清单中。好产品是改出来的，根据什么而改？依靠一个个项目实践得来。

Saas套路，往往两种。一是先抢占大客户，缺点是侧重服务，实施周期长，需投入大部分的资源到项目中。但若做成了，再往下则简单许多。有了行业领头企业的项目，会受到其他企业的青睐，看重的不仅是产品，更有其案例，老大是怎么做的？有什么可以让我们这帮小学生效仿的？第二种，则是先在SMB推广，逐级向上。缺点是客单价不高，影响力甚微，但周期短，可快速实施多个项目，更有利于坚守标准功能。产品发育到成熟期，可以大幅精简团队，一半开发，一半产品。本地项目交由合作伙伴实施。团队专注产品，及公有云项目。同时因产品足够成熟，公有云交付团队也可精简，PM+SA两人现场，所有开发远程集中搞掂。

无论哪种方法，项目在前线打战，产品团队在后方支援。可实际情况，听到炮声的人，有时无法呼唤到炮火。项目现场，交付团队需面临自家产品团队，与甲方两方面的挤压。甲方的需求，交付需与产品团队远程沟通评审，产品团队出于标准化原则的把控，不认可该开发项，转为项目二开；或认为值得纳入产品功能，转为产品二开，但要按照统一发版，影响项目进度；甲方也不理解，为何我们已让步，现场决策，牺牲一定质量，提出可行的开发需求，第二天你们反馈做不了？或要延迟实现？造成项目沟通成本极大，交付、产品、客户三方，就项目二开、产品二开反复讨论、反复调整。更严重者，即使是项目二开需求，公有云产品团队也会把控，拒绝通过。宁愿放到上线运维后，客户有需求，随时联系技术后台做更改，而不愿为了满足一个客户需求，多增加个配置页面。

产品团队面临的悖论是，都知道产品的价值是服务客户，为客户创造价值，但谁是客户，或者说哪个是大多数客户的需求？不能为了1%的客户，牺牲99%客户。如何判断一个需求的影响面？在现场，交付面对的一个客户，就是全部。而产品团队，面对的是N个项目，N个客户。交付提出1个紧急需求，向产品施压，必须满足，否则客户业务受到影响。产品团队收到的则是N个等值需求，需判断哪个收益受众面最广。有时甚至宁缺毋滥，否则产品会变得臃肿复杂，失去了标准化的意义。可怜了交付团队，两边受气，硬着头皮磨合客户业务需求与产品的适配性。

Saas产品，甲方的一纠结点，是选择公有云还是私有云部署？这要看产品的技术能力，以及业务变更的频率与幅度。公有云若无法支持甲方开发，任何变更则要联系厂家远程解决，这会与厂家死死绑定，相当于自己养了一两个开发人员，同时受限于产品版本发布时间，无法及时响应业务紧急需求。特别涉及到大的变更，厂家会借机抬价，将项目低价中标亏损的钱，靠运维收费补回；若本地部署，则无法享受公有云迭代的新功能，自己的开发质量无法与厂家相比。因此如何选择，需按具体情况分析。但一般而言，大公司倾向本地化。一是基于业务现状，要做大改，大量定制化开发的收益，大于成本；二是开发资源充足；三是产品的整体框架、功能模块已具备了，厂家的迭代功能不是必需项。

以上结论，项目经理真的很苦逼，不过职业就是这样，专职背锅与填坑。只能努力奔着上游，做销售，或者转到产品经理，坑后续项目经理。

Tips

1. 好产品是改出来的，产品有了七八分，就敢拿出来找项目，靠项目打磨。但风险在于一上线很容易死，体验太差，用不起来。

2. 产品团队成员都必须去项目实施现场体验，每个项目情况都是不同的，参与一段时间，对于权衡产品标准化与个性化服务会更有感觉

3. 产品发版后，除了项目二开测试，交付团队有时还不得不为为产品标准功能做测试

4. 交付团队应总结项目的优势与劣势，再提出产品运作方式的好坏