产品经理和开发人员的战争：身份认证，奴隶道德以及敏捷开发何以可能
一 身份认同
上学的时候, 老师上课时, 讲了一个他亲身经历的故事.
大概是他去农村做普法工作的时候. 和村民聊天聊的渴了, 就说: “能给我一杯水 (shui) 喝么?”
村民们先是一愣, 继而哄堂大笑: “喝水 (fei) 就喝水 (fei) 嘛, 还喝水 (shui).”
西北方言中, “水” 字发 “fei” 的音, 老师是知识分子, 自然操一口标准的普通话. 村民们便嘲笑他装腔作势.
老师讲这个故事, 本意是要讲, 法律是一门极务实的学问, 所以在现实中, 一定要不要一天到晚把法律术语挂在嘴上.
而我听到个这故事, 却无端想起阿 Q 来:
加以进了几回城, 阿 Q 自然更自负, 然而他又很鄙薄城里人, 譬如用三尺三寸宽的木板做的凳子, 未庄人叫 “长凳”, 城里人却叫 “条凳”, 他想: 这是错的, 可笑! 油煎大头鱼, 未庄都加上半寸长的葱叶, 城里却都加上切细的葱丝, 他想: 这也是错的, 可笑! 然而未庄人真是不见世面的可笑乡下人呵, 他们没有见过城里的煎鱼!
—— 《阿 Q 正传》
“fei” 不仅仅是一个发音, 而 “长凳” 也不仅仅是一个叫法, 它们背后是一套身份认同机制. 村民和阿 Q 的身份认同建立于其上.
为了保证这种身份的正当性, 水只能念 (fei), 否则便是装腔作势, 而三尺长三寸宽的木板做的凳子, 必须叫 “长凳” 否则便 “是错的, 可笑”.
而阿 Q 还多一种身份认同, 他是 “进过几回城” 的, 因此他不但能嘲笑城里人的 “条凳”, 还能嘲笑不知道 “条凳” 的未庄人.
二 主奴道德说
关于道德, 尼采有一个 “主奴道德” 说.
他认为最基本的道德形态有两种: “主人的道德” 和 “奴隶的道德”.
主人的道德来源于胜利者对于强者的歌颂, 因此, 主人的道德以 自我肯定, 荣誉和主动为特征.
而奴隶的道德则是来源于奴隶们对于主人的反抗, 因此凡是主人认为是好的, 他们便认为是恶, 并从此找出一个对立面来, 称之为善.
所以主人说 自我肯定, 他们便讲 自我否定; 主人讲 荣誉, 他们便讲 谦卑; 主人讲 主动, 他们便讲 被动.
奴隶的道德, 先要有一个身份认同, 与这个身份认同相同的, 就是善的, 对的; 与这个身份认同相异的, 就是恶的, 错的.
与是, 把水念作 “shui” 或 “fei”, 把三尺长三寸宽的木板, 称作 “长凳” 或 “条凳”, 便因为身份认同而有了道德上的价值.
“非我族类, 其心必异”, 说的便是这事.
在这种道德认知中, 只有两套话语: “我是谁” 和 “所以你们都是错的”.
当然, 奴隶的道德不仅存在于遥远的西北农村和过去的未庄阿 Q 身上.
也存在于, 女权主义和直男癌的对立中; 爱狗人士和禁狗人士的对立中; “不孝子女“ 和 “父母皆祸害“ 的对立中.
甚至更广泛的存在于, 甜党与咸党, 猫党与狗党, 粉丝与非粉丝, 不同偶像的粉丝之间.
自然, 在存在于产品经理与程序员的战争中.
三 产品经理和程序员的战争
产品经理和程序员的矛盾似乎由来已久, 但从未象现在这么紧张.
几乎所有与技术有关的媒体多多少少都调侃过产品经理和开发人员的矛盾.
这种调侃是可以快速基于身份认同产生情感共鸣的. 当然, 如果没有这种快速产生情感共鸣的效率, 它可能也不会如此快速传播起来.
而这漫画也颇得阿 Q 真传. 如其 既嘲笑城里人的 “条凳” 又嘲笑未庄人的不知道 “条凳” 一般, 既调侃了产品经理, 也调侃了程序员.
与是乎读者们便在嘻笑中, 对号入坐, 各自加深了身份的认同和对抗的情绪.
这个问题是无解的.
因为互联网媒体为了能够快速形成传播, 一定会试图制造强烈的情感冲突; 而为了制造情感冲突一定会试着塑造身份认同; 而利用奴隶的道德制造对立, 则是快速建立身份认同最有效的手段.
因此, 我们可以想到, 未来一定会有人继续贩卖产品经理和程序员的矛盾, 并且必然的会进一步加深他们之间的对抗.
那么产品经理和程序员只有互相伤害一条路可以走么?
当然不是.
四 瀑布模型
作为经典的软件开发生命周期模型, 瀑布模型当然对于这种基于岗位身份认同的对抗有一个解决方案.
瀑布模型大体如下图所示.
简单说来, 其流程如下:
- 需求分析阶段:
- 需求人员进场, 进行需求分析, 形成文档;
- 所有利益关系人开会, 确认大家不会改了, 然后签字;
- 进入下一阶段;
- 设计阶段
- 设计人员进场, 进行设计, 形成文档;
- 所有利益关系人开会, 确认大家不会改了, 然后签字;
- 进入下一阶段;
- 开发阶段
- 开发人员进场, 进行开发, 形成代码;
- 开发结束, 进入到测试阶段;
- 测试阶段
- 测试人员进场, 进行测试, 开发人员改 BUG, 最终形成测试报告;
- 所有利益关系人开会, 确认开发结果没问题, 然后签字;
- 布署到正式环境, 进入运维阶段.
如果我们把这个流程用时序图来表示:
瀑布模型其实并不是解决了不同岗位之间的矛盾, 而是避开了矛盾: 在这个模型中, 理想状态下, 人与人之间是不用沟通的, 所有人都只和文档系统沟通就行了.
这个解决方案当然是有效的. 甚至, 如果产品经理和程序员的矛盾达到双拒绝沟通的程度, 诉诸文档体系是最后的手段:
程序员说: “你不要给我讲什么需求. 你去写成文档, 发邮件给我, 并且抄送领导. 如果领导同意了, 我就开发.”
产品经理说: “你不要给我讲为什么实现不了. 你把情况写成邮件发我, 并且抄送领导, 如果领导说这事不做了, 我就把需求取掉.”
但是这种解决方案有两个很麻烦的问题:
1 所有人不得越界
瀑布模型的文档系统背后是一整套权责系统. 所有人基于文档进行分工时, 其实也是在划分权责的界限.
所以人必须只对自己的分工具有权责, 而不能有任何越界.
如果有人在某个分工上越界, 这个工作一定出问题. 因为一旦越界, 就立刻会形权责混淆, 最后就形成没有人对此事负责的局面.
比如: 如果产品经理就某个功能提出一个如何实现的技术方案, 这个功能一旦出了问题, 大家就会开始扯这样的皮:
开发: “是产品经理让我这样做的啊.”
产品经理: “你是专业的技术人员, 你应该对此有起码的判断啊.”
无论最后, 板子打到谁的屁股上, 反正事儿是黄了.
所以对于每个人来说, 最负责的行为是, 不对自己分工以外的任何事情提出任何建议.
2 系统性甩锅
系统性甩锅是我杜撰出来的一个词. 它指的是这样一种情况:
当项目进行过程中, 出现一个以前没有预料到的问题时, 只要个这问题还不至于让项目现场完蛋, 对所有人来说, 最理性的选择是装作看不见这个问题.
因为所有人只对自己具体的分工负责, 所以事实上没有人对项目本身负责.
而当这个问题导致项目失败后, 我们追查责任时, 会发现没有人应该为此负责. 锅就这样被系统性的甩出去了.
当然, 这种情况下, 大家发挥暴民政治, 找个替罪羊来扛锅也不是不可能的.
所以在这种系统中, 明哲保身和人际关系是要比技术, 能力重要百倍的事情.
既然瀑布模型带来的分工模式有些负作用, 那我们是不是可以不分工, 让所有人为所有事负责呢?
不行. 因为如果不这样, 团队中不同岗位的人, 会因为身份认同和奴隶道德吵成一锅, 然后迅速分裂.
那么还有别的出路么? 有的.
五 两种语言
说个八卦啊? 为什么啪啪的时候要叫床?
答案是: 叫床其实起的是劳动号子的作用. 因为这个活动, 如果双方的节奏不一致, 轻则效率低下, 重则容易受伤.
所以这是基于分工的协调机制.
好, 问题来了, 为什么啪啪啪之前, 大家不需要就叫床一事写文档, 规定一下这个节奏是什么样的, 然后签字.
因为: 语言的目的是为了达成共识, 而达成共识有两种方式, 一种方式是通过意义来共识, 一种方式是通过情境来共识. 这两种共识对应两种语言, 一种叫意义的语言, 一种叫情境的语言.
文档是一种典型的意义的语言. 通过书面的形式, 把事情说清楚, 道明白, 没有任何歧意, 大家基于此, 形成共识. 而签字, 是对共识的确认.
叫床是一种典型的情境的语言, 在叫床中, 没有任何有意义的词汇. 如果把它从情境中拿出来, 我们完全不法知道它在说什么, 但如果把它们放回到情境中, 我们想都不用想, 就知道是什么意思了.
所以要让产品经理和程序员抛开身份认同和奴隶道德, 除了大家只写文档不要沟通以外还有一种办法, 就是建立一种情境的语言, 让大家在情境中达成共识.
六 敏捷方法为什么有效
敏捷方法提出一套建立在情境的语言之上的开发方法, 其基本价值观是:
个体和互动: 高于流程和工具.
工作的软件: 高于详尽的文档.
客户合作: 高于合同谈判.
响应变化: 高于遵循计划.
敏捷方法主张, 建立关系紧密的小团队, 在一个较短的迭代中, 完成一个相对独立的小功能.
小团队使团队成员形成基于情境的非正式话语体系, 较短的迭代使团队成员对于项目的走向有一种把控感, 完成一个相对独立的小功能可以使团队成员让对项目的所有工作有一个具体, 完整的认知.
这种组织设计, 使每一个团队成员有一种 “这是我的项目“ 的主人公般的控制感.
这种组织设计, 保证了团队在 “做事“ 这个情景中达到了共识. 而在这种情景中, 团队成员基于岗位分工的身份认同和对抗意识就会相对弱化, 取而代之的是互补与协作.
七 人格魅力
敏捷方法是一套非常依赖规模控制的方法. 一旦项目规模膨胀起来, 敏捷方法所依赖的, 所有人为一个可控的目标努力的情景 就会淡化. 团队成员会又会按部就班的回到身份认同中.
难道大项目就只能陷入对抗和团队分裂么? 当然不是, 有很多成功的大项目, 成功的落地而没有陷入 “越界” 和 “系统性甩锅” 的麻烦中.
这些大项目是通过什么形成情景的语言呢?
就我的经验而言, 那些成功的大项目, 背后都有一个非常具有 人格魅力 的项目经理.
除了通过 具体的事 形成情境, 还可以通过 具体的人 形成情境.
所以, 对于项目经理, 最重要的倒不是专业程度和经验, 而是能让人们形成凝聚力的人格魅力.
关于产品经理和程序员的战争, 从身份认同和奴隶道德的角度来讲, 是不会有所缓解了.
而且考虑到互联网媒体看热闹不嫌事大的心态, 这两个岗位的对抗和不理解只会越来越严重.
我们作为当事人和受害者, 能做的也能是在沟通中尽可能建构情境的语言, 让团队在具体的事或具体的人的角度上达成共识.