https://mp.weixin.qq.com/s/Ru2b0LXrLlpOqWBaH1rZgg
之前认识一个老板，曾经雄心勃勃地宣布：咱们把手里给甲方的几个项目做好，从中提炼出标准化产品，以后就能一鱼多吃，躺着赚钱了！折腾了很多人很多时间，也浪费了很多钱，最后都是一地鸡毛：项目团队天天被甲方折磨：客户临时改需求、领导偏爱“面子工程”、预算越砍越狠；产品团队被要求“边接项目边打磨产品”，结果代码像“四不像”——既要满足甲方奇葩需求，又要留接口给未来用户，最后项目交付一塌糊涂，产品更没影了。今天微信上聊了会儿天，他对这个事儿感慨了下，有点反思，但不多，更多的还是不甘心，觉得是当时干活的人不行。这两事儿我都干过，聊几句，凑一篇……我接触过的很多“用项目养产品”更像是让猫和狗杂交。项目和产品，对于很多公司来说其实是两码事儿～虽然想法上是好的，但执行的时候就不是那么一回事了。甲方的特色需求、领导偏好、临时变更，预算，自己公司领导的决策水平，时间，成本，考核标准等元素掺合在一起之后产生的各种冲突大概率就决定了想在项目里孵化产品这事儿，有点异想天开。当然，往往这个时候，总会有人说那 xx 公司的 xxx 就是通过服务某个客户过程中逐步迭代出来的。项目：以满足特定客户验收为目标，同时想办法从客户那里多增加功能需求（有没有用不重要）好多收钱，同时自己实施的时候尽可能的少成本。实现一个利益最大化。所以甚至可以出现，项目做的很烂没关系，但是搞定这个客户负责人，能帮忙给我们验收是最重要的。你想象一下，你的BD和项目经理给客户做验收报告，然后这个客户不满意，觉得你们没有达标，不签字，尾款堪忧，BD和项目经理回去跟你汇报，你把他们几个骂了一顿，然后关上办公室的门，打了一个电话：”哥，你下面那个谁谁谁不签字……“，第二天，客户给你们项目经理打电话：”把材料重新补一下，今天再来一趟“。产品的逻辑其实又不一样了，不是某个特定客户，而是某一类，需要普适，反而要考虑冗余的问题，又要在一些明明可以写死交差的地方变得具备灵活性。确实就会出现，交付这个项目一行代码就搞定 ，搞成产品就要写十行代码。产品的“用户”是真正在用的普通人（或企业员工），他们只认好用不好用，难用，是真会骂你、差评，不付钱了。你搞项目的只用想办法搞定关键用户就好了。有的人会搞各种项目，不会去操心搞产品的问题，本质上因为他很早就明白这生意的本质是“人情游戏”，不是“产品比赛”。同样的，项目负责人和产品负责人，考核指标都不一样，还想在项目中搞产品，都要建立在不影响对方 KPI 都前提下，这就行不通。公司考核项目经理的指标都是“签单金额”“回款速度”，“项目质量”那都是后话。所谓「能拿钱回来就是英雄」。更别说那些“吃回扣”的项目了，它更不可能有孵化产品的空间了。别问“能不能两头占便宜”——从来没有“既要又要还要”的童话。当然也不是没有例外，但不多，道理听上去也挺简单的，主要是做不到啊：产品经理必须能顶住甲方压力，说“这个需求不符合大众用户需求，不能加！”；项目经理必须学会拒绝客户：“超出合同范围的改动，得加钱——而且可能影响产品稳定性。”能不能接受这个成本：成功的产品研发成本至少是单个项目的2倍以上。如果发现客户的需求根本无法复用，哪怕亏了钱也要及时止损，不要通用产品改成“定制化怪物”。如果觉得有用，转发给身边还在“项目+产品”泥潭里挣扎的朋友，救人一命胜造七级浮屠！
https://mp.weixin.qq.com/s/Ru2b0LXrLlpOqWBaH1rZgg
