关于产品交付和项目交付
大家好，我是金刚小鹦鹉，盔甲太重，站不起来，容我坐一会。
昨天晚上突然有个朋友问我：“产品交付和项目交付有什么区别？”
真是太巧了，其实最近我也一直被这两个词困扰，只是我的问题比他更多一点，除了不停地比较产品交付和项目交付的区别，我还会想为什么会出现这两种不同的交付方式？到底哪种更好？什么情况下选择哪种更适合？为什么不同的软件公司采用了不同的交付模式？哪种组织形式更适合哪种交付模式？两种交付模式的团队成员和项目经理分别应该具备什么样的素质？如此种种。
因为一直在想，至今也没有什么头绪，但是或许把这些想法梳理出来，写在纸上，告一段落，才能踩在上面走得更远一些吧。
2010年-2015年期间，我好像都没有这个困扰，甚至都没有感觉到我一直是在做产品交付。
2016年，我去了LC。一去就有人说，他们是在做项目，并不是在做产品，当时我完全没有懂这是什么意思，我觉得我之前也是在做项目啊，不然为什么叫项目经理呢？
后来，观察周围的人和项目，总感觉得有些不一样，仔细一比较，发现这里的项目组成员多了一个标配角色：开发经理。当然一旦有了开发经理，又会根据项目的情况多出很多角色，比如产品经理、测试经理、美工等等。
当时以为是因为我那个项目比较特殊，没有标准模块，所以才配置了开发经理，后来一观察，发现并不是这样，这里所有的项目都会配置这样的一个角色，这在以前，我从来都没有遇到过，哪怕是千万级项目，都不太需要这样的一个角色。
后来，当我发现在YY的时候，安装产品也就是点下一步下一步，最多二十分钟就能完成的事情，在这里居然要先打两百个补丁，花费大约一个星期，才能把产品安装上去的时候，我差不多就明白了配置开发经理的原因。
第一、当产品无法“傻瓜式”安装的时候，我们就需要开发经理。
第二、当产品安装都这么复杂，就不要幻想可以“傻瓜式”把客户的需求配置到系统里面去，要满足客户需求几乎只能通过开发来实现，所以，我们必须要有开发经理。
至此，我觉得做产品交付的意思就是说有一套成熟且功能强大的产品配合交付，类似乐高那样模块化且功能颗粒度很小的产品，开发量很小几乎不需要的时候，就叫做产品交付；如果没有成熟的产品，需要大量开发工作配合来实现客户需求的时候，就叫做项目交付。
但是，并不是说项目交付的模式就比产品交付的模式差，下面来看下区别。
第一，成本差异较大。项目交付比产品交付贵很多很多。
产品交付的项目组织一般只需要项目经理和实施顾问。实施顾问又分为中高低级，在调研和方案阶段才需要中高级顾问，在上线阶段就只需要中低级顾问。
项目交付需要的角色类别比较多，比如项目经理、实施顾问、开发经理、产品经理、测试经理、美工以及大量的开发人员。
第二、周期差异较大。项目交付比产品交付周期长。
产品交付一般只需要调研、出方案、系统配置、用户测试即可进入上线阶段。
项目交付调研完以后，顾问先要做业务方案，然后产品经理再根据业务方案做开发设计方案，然后开发经理再组织开发人员进行开发，然后测试人员进行测试，测试达到一定的验收标准之后，才能交付给用户测试，用户测试完毕才能进入上线阶段。
第三、系统稳定性不同。产品交付稳定性会比项目交付好得多。
就好像买车，最好不要买刚出来的新款车是一个道理，经典车型的稳定性会比新车好很多。
第四、客户适用性不同。项目交付的适用性会比产品交付更强。
就好像乐高玩具的颗粒度，如果颗粒度太细，玩起来的复杂度太高，顾问容易出错或者是根本搞不清楚到底要怎么配置；如果是颗粒度太大，看起来又像是打了马赛克的物体，轮廓不流畅，不清晰，所以只能在这两者中间取平衡。当然，颗粒度太细，技术难度也会成倍增加，开发成本会更高。
项目交付就没有这个问题，反正都是二次开发，从界面到功能，都可以根据客户的需求进行开发。但是如果产品经理心里面想着要把产品做成可推广的，那对于这个项目简直就是灾难，他可能会让开发人员痛不欲生，在那么短的时间内把产品开发得尽量灵活，那会耗费更多的时间。
第五、项目难度不同。项目交付模式的难度比产品交付的模式更大。
做产品交付的时候，项目经理很多都是实施顾问兼任，并且除非项目很大，项目经理才有机会独立出来只做项目经理的事情，否则都要兼着做顾问的活。
但是做项目型交付，要管理的项目成员类别太多，人员结构复杂，势必就会造成管理的复杂度成倍增加，对项目管理的水平就提出了更高的挑战。说实话，我的项目管理水平就是在那个时候进步的。当做完项目交付这种复杂项目的项目管理以后，回头再看产品交付的项目管理，觉得产品交付的项目管理实在是太简单。
第六、关于未来。
2016年开始，当然，以下完全是个人感受，没有数据支撑，可能都只是现象而已。
不管是正在往标准产品的路上走的软件公司，还是正准备创新产品的软件公司，不管乙方怎么想，反正甲方已经发生了很大的变化。
想要做标准的产品交付，变得越来越不容易。
一是因为标准产品的价格竞争白热化，低价化，价格太低，没人愿意做，也做不出来价值。
二是因为标准功能已经普及了这么多年，标准功能对于管理提升的价值也遇到了瓶颈，需要通过新的流程和模式进行管理提升和优化。
比如财务共享，就好像是把标准财务功能改头换面，流程再造以后达到管理效率提升、成本节约等目的。对甲方来说，提升了效率，节约了成本，提升了内部服务满意度；对乙方来说，项目利润更大，顾问价值更高，技术壁垒更高，提高了市场竞争力。皆大欢喜。
但是创新，谈何容易。销售如果签了非标准产品的单回来，做惯了标准产品的顾问看不懂，这个单往往就会被定义为烂项目，因为按照以前的模式无法落地。
以前的模式包含公司对顾问的考核模式（比如项目交付周期的考核一般较短）、公司组织架构的模式（比如开发人员人数较少，没有配置开发经理、产品经理、测试经理、美工等岗位）等等。
总之，我们是要继续坚守产品交付模式，还是要向项目交付模式挺近，什么时候该做什么样的选择？有没有机会选？
目前就想到这些。