“中庸”的艺术 - 如跟需求方讨价还价
翻到一个神贴 How to make Product give a shit about your architecture proposal ,标题直译就是《如何让沙雕产品经理接受技术改造》
具体故事,原文非常值得一看。搞了这么多研发,产品经理各种水平的都遇到过一堆,最大的烦恼就是“我有个想法”,“今天就要”而全然不顾你当前技术架构的问题。到底是技术优先,还是业务优先?开发人员和销售非常普遍的冲突怎么处理?
产品经理,老板,甲方,销售,实际上是研发的衣食父母。他们所有的诉求:
- 产品不管你的技术问题,他们也不懂。他们只关心 产品 本身
- 产品需要的是一个 结果,而不是一个白板上巨复杂的分布式系统架构图
- 产品是人,产品为人服务。他们也能理解有工程方面的顾虑,这也是他们找开发的原因。他们是来“讨价还价”的!
开发是“乙方”,正如那个文章里的 水管工 故事一样,实际上是 “赢得信任” 的实施方。所以接下来的套路是:
- 你先不要 what about,先别反驳说 but 。先按照理想的条件,全部答应下来,
- 做一个理想化,全套,SSVIP,贵宾级别的报价,所谓 platinum package。内部需求就把人力、服务器、时间、排期等成本按最坏的估计全部算出来。
- 拿这套方案,给到需求方,一定要让他们很诧异的问出:“why” ,怎么这么麻烦啊!?
- 这就是让产品对你的技术问题关心的机会!接下来,开发需要有礼貌,不卑不亢的,有理有据的把你的处境讲出来,要展示你的专业能力和素养。
- 接下来需要让对方陷入自我怀疑,内心:“Do I really need all this? 是不是这要求有点过份!?”
- 最终结论,还是要做,换更经济的方式去做,要么不做。如果这件事是能挣钱的,那么的确投入人力物力时间去征服麻烦啊。
文章也讨论了,话也说回来,一个粗糙的结果,和没有结果,哪个更讨人厌?实际上是粗糙的结果。就好比故事里的水管工,你下水道漏了,又舍不得大修,就缝缝补补。结果过一段时间又漏了。这还不如不修。烦呐!
所以一般的经验是,要么不做,要么就把一个事彻底解决最好。不要交付半吊子工程!
当然,这个时候要思路灵活。水管坏了不一定要在原地修补啊,说不定换一个管线完全绕过以前的大坑呢?
所以就回到了这篇blog的主题:tradeoff
以前我不知道如何准确翻译这个词,一直把叫“妥协”。但是这似乎有点贬义。或许叫 折衷,取舍 更好?。
我觉得装逼的翻译是 —— 中庸。
成年人的世界哪有那么多“既要……又要”,乃至“……还要”。
以前上学的时候,就喜欢“中庸”,60分及格万岁,一个知识点了解个大概就行,平庸,和稀泥,不表态,无原则,优柔寡断。结果贻害无穷。一只吃亏到而立之年,发现中了孔老二的圈套。
对中庸最大的误会是它丫的压根就不应该是一个“方法论”,而是一个“对结果的欣然承认”态度;
作为方法论,我的心得是,才接触一个事,就要走极端。抓东西就从一个“抓手”入手,如果恰好能抓住“主要”矛盾那就最好不过,而且最好只抓一个。抓住,抓稳了之后,再去了解事物的全貌和corner case,这个时候事半功倍势如破竹。
就好比,以前打 CS 1.5,突然转角处出现两个敌人,你慌乱之中,既不向A也不朝B开枪,而是瞄准他俩的中间空隙biu~biu~biu~。然后就躺了。这种遭遇战就应该训练自己的下意思,必须集中火力,断其一指。
做事也一样,认准一个方向,全力推到超出它极限为止;然后再停下来,考虑有没有更好的方案,做到周全;其次考虑对方接受程度,该省省能砍砍;最后一看,嘿,也就一般般。
好吧。其实我也不懂中庸,也不想懂,更不想revision中庸,就是纯粹想附会,如果是个误会也无所谓。就这样吧。
Posted
stdin