搬砖和搬砖机

码农的命就是搬砖。

曾经挺羡慕“软件开发”这行的,软件,听着多牛逼!入行了以后才知道,不过就是码代码。曾经苦心钻研过的高级统计算法,曾经费神思考过的高效率排序,这些在硬件性能越来越牛逼的情况下,显得越来越不那么重要,反而让你的代码这么复杂、难理解,更可怕的是从你的代码就能看出你的年龄!

这几年我看到的代码,几乎全部是以实现功能为最高标准的,而非在实现功能的同时还得有美感。

这当然也不能赖码农,项目时间紧,谁有功夫给你干那些没用的。

这么说,码农就没有机会高大上一把了么?对,没有机会了,除非你不是搬砖,而是给其他搬砖的制造“搬砖机”。

还记得几个月以前我说的哪个政府项目么?那就是造搬砖机。这篇儿就说说搬砖和造搬砖机在项目管理、方法论,技术管理上的区别。

搬砖指开发商业软件,比如满座网,比如企业内部系统,比如抖音APP。

这些项目都:

有个“价值取向”;

所有的开发都围绕着“价值”的

项目组的历次提交物都是实现了这个价值(当然你要是说我们开发的东西没有价值,客户也不关心,是政治项目,大家都是乐呵乐呵完了,我也没辙)

这类项目单纯的像个大一学生,只要跟她聊,有时间陪着她,就算成功了。同样,只要花时间和客户聊价值取向,在客户中、团队中统一这个价值取向,根据这个取向造出Epic Story,然后BA细化,分派给开发和测试,开发完成后,再由BA验证,最后showcase给客户,项目肯定没跑儿。

从技术上说,使用CI,坚持code review,多写点儿test方便重构,基本上都不会出大事;

项目管理上,坚持实施Scurm方法论,揪住BA,时刻确认他的价值观是否和客户一致,基本上不用管开发码什么;

简单么?本来就不复杂。


咱再说工具类,就是搬砖机的开发。为了说着方便,我用三个项目对比着说:

第一个是这个政府项目;第二个拿微软的Word说事;第三个是创造Java开发语言和jvm。

开始

造搬砖机最大的问题是“问题定义不清晰”或者说“战斗面太大”。

第一个项目的目标有三个

“可以提交任何格式的表单到任何结构的数据库中”

“可以显示任何数据源的数据到任何页面中以任何格式显示出来”

“可以将脚本语言(比如Js、Python、Groovy)插入到上述流程中,完成脚本语言中定义的任意功能”

第二个项目的目标就一个

“写文档、排版”

第三个项目目标也不复杂:

“创建一个运行环境和一种语法,凡是符合这种语法的代码,就可以在该运行环境中运行”

有没有发现,这三个项目的需求其实跟没说一样,在看几个“搬砖”项目:

“我需要一个注册用户的统计报表,里面应该包括XXX,XXX,XXX,这样我就能知道用户总量和拉新情况”

“我需要让用户能够按照商品名称和描述查询商品,这样他们就能进入购买流程了”

你感受一下”战斗面“的区别。

其中的Word项目还好,是能够从“写文档、排版”这5个字深化下去,不论几十个Story还是成百上千,花时间就行。而第一个和第三个,想细化都下不去手,简直了。

造搬砖机类的项目还有一个问题:对于任何一个技术层面的修改或者重构都可能祸及整个项目,这就需要更加高深的架构设计和整体规划。

仔细想一下第一个项目和第三个项目,是不是有种感觉:“不到最后一周,全部的努力就是垃圾,什么用都没有,而只有最后一周,一切连起来了,这个庞大的家伙奇迹般的站起来了”

相比较一般的“搬砖”项目都是有累积的,做完了用户模块和订单模块就可以注册、下单,至于统计、广告模块,以后慢慢增加就行。那个Word项目,功能也是可以累加开发的,第一版的Word就没有做表格的功能嘛。

再看这三个例子,其中Word是产品,够复杂吧,但还不是造工具类的。反而这个政府项目和Java虚拟机的开发很神似,是工具类开发。

下面就好好掰扯掰扯怎么管理这类项目。


《星际争霸 I》玩过么?玩过的都暴露年龄了。啥?你没听说过这个游戏,90后吧?那你看到这儿就当个乐呵完了,别往下看了,多花点儿时间搬砖比什么都强。

内个,回正题,回正题,咱说:

虫族:一队小狗推一个地堡;

神族:两个蝴蝶推整个基地;

为什么突然说这个呢?

造搬砖机需要神族;搬砖用虫族最好。混战的时候,往往虫族和神族配和。

从人员配备上来说,造搬砖机项目需要两个团队

神族 – 团队1:纯开发团队,工作经验必须60年以上,最多三个人,最好两个人,不管他们干什么和怎么干,就告诉他们上面说的那个模棱两可的需求就行。要求他们先动手,做出第一个版本;

虫族 – 团队2,BA、QA、Dev、PM都配齐,等团队1有了第一个版本,他们是实施方和反馈方,他们真正和客户接触,解决客户“我就喜欢红色,你换个红色的按钮给我看看”之类的问题;

从钱上说,两个团队基本上3/7开吧,弄好了4/6也行,神族占7,虫族占3。对,你没看错,2个人挣5个人的两倍。这和一个神族蝴蝶和虫族小狗的成本比例基本一致。多说一句,碰到不差钱的,说”这两个团队都要神族“,我要牛逼中的战斗机。那肯定也是一个没玩过星际的,你见过20个神族的叉子推基地的场面么?上去8个就围满了,另外12个围着这8个乱跑;20个小狗推基地啥劲头?没一个闲着的啊,推的比8个叉子还快。这就是啥人干啥事,你非让宇航员给你当司机,不如找个出租车司机安全又踏实。

从项目管理上说,神族团队的客户是是虫族,他们提反馈给神族团队,可不能让神族直接面对最终客户,遇见那种“你换个红色的按钮我看看”,没两天你神族就走光了。

虫族,用Scrum完全够用,妥妥儿的。

神族,用敏捷有点儿勉强,瀑布方式最好,先让他们做Demo,做尝试,定方案。不用定期的showcase,什么时候有想法随时聊。

从项目的进度安排上说,

神族团队先上,什么时候做出第一个版本什么时候虫族再上。至于你的神族是不是能快速做出第一个版本,这就和星际趟地图一样,技巧和策略不能说没有,但是主要靠命。


最后,如果时间能够重来,我会做这么几件事情:

1、在项目初期就提醒客户:我们不需要虫族,拿全部虫族的钱找神族,把11个人的团队缩减为2个人,也不需要我这个TL(自己把自己先开了)。跟客户说明这个道理:即使掏8个人的钱养2个人,那也是少掏了3个人的钱,赚了啊这是。

2、如果客户否定了1,退而求其次,把团队分成两个,虫子里面找有没有猛犸,把猛犸编成一队,全力做出第一个版本。另外一队打酱油(谁让客户愿意当大头呢)。虽然有点儿浪费钱,但是这样安排也比小狗、猛犸混编、分散精力强;

2.5、如果客户仍然喜欢敏捷,想尝试一把,就让“酱油组”陪着玩,把猛犸隔离出来,安心就干v1这一个事;

3、如果猛犸组2个月以后仍然没有动静的话,就得和客户谈了,两种情况:

第一种:“任务对于这个团队太难了,必须有正经的神族参与,找不到的话就解散团队,别浪费钱了,咱都是穷人家的孩子。。。”;

第二种:“任务对于这个团队太难了,咱能换一个简单点儿的方案么?你看有那么多‘任意’俩儿字。。。啥?方案也不能换么?那。。内个,你看,咱都是穷人家的孩子。。。”

空芯人

今天,回家的路上,看见了一件稀罕的东西:
20160624023759_33554
特别的亲切,想起了“豆腐渣工程”,就下车拍照留念。
以前在ThoughtWorks的时候,一天到晚的说“能力建设”,怎样把团队的能力培养搞好。我们曾经给一个人定义了多种能力和胜任力,并且给出了评估方法和培养方法。对于有的人收效很大,但是有的人效果就不那么好。始终想不出有什么好的方法提高这个比例,总觉得自己做的不好,眉毛胡子一把抓,顾此失彼。
这事儿一直在我心里卡着,总觉得马上就悟透了,可想深了以后,就总觉得缺了那么一点点儿。直到今天看到这个亲切的玩意儿,一下就通透了,像PEI透蓝的天。听我道来:
其实每个人都是空芯的,就像这个水泥板,
外层坚固的是固有技能。对于PM来说,就是项目管理能力;对于开发来说,就是编程能力;对于BA来说,就是业务分析能力;
中间的空洞是附加能力。对于PM来说,可能是开发能力、业务分析能力;对于开发来说,可能是敏捷能力、UX能力;
一般的公司会看重“故有技能”,他们只看重“这板子长不长,硬实不硬实”,越长越硬就越好。可往往事与愿违,找到了长的,但是上面放不了多少东西就断了;找个短的,上面又放不下东西;找到合适长短又硬实的,就可劲儿放东西,直到他断掉。
ThoughtWorks在这点上好多了,知道“每个人都是一块有洞板子”的事实,于是就允许他自己填洞,也会帮他填洞。在公司,大家会觉得开发参与业务分析很正常;UX会业务梳理,那太好了!PM不会开发,那还混个啥?所以,ThoughtWorks的能力建设可以分为“加长板儿”和“换芯”两种,针对这两种事儿的不同,用不同的方法培养。希望现在还在忙能力建设的前同事能有点儿启发~
从个体来说,被“逼着”培养总是欠点儿意思,你想一下,如果一个人可以不停的换芯儿,那会怎么样?
比如,一个PM有项目管理技能、和敏捷技能,同时他又有几套芯儿:零售一套、P2P一套、Java一套、AngularJs一套。遇到零售或者P2P项目,就从这两套里面挑一个;遇到Java或者AngularJs,抽出原来的芯儿,换上Java或者AngularJs。
再横向扩展,如果这“空芯人”有两个洞,就可以同时换上零售、Java的芯儿,如果他有三个洞,就可以同时换上零售、Java、AngularJs的芯儿。
终于说到主题:空芯人。
如果一个人可以换芯,那这个人就不会被自己的故有技能困死,“流氓会武术,谁也挡不住。。。”;
如果一个人不停的养“芯儿”,那这个人自然受人欢迎,“本来能靠本事吃饭,可偏偏靠长相。。。”;
如果一个人不停的在自己身上戳洞,那这个人就要简直了,想不飞起来都难,“站在巨人的肩膀上,脚踩弹簧玩撑杆跳,还赶上巨人站在风口边。。。”
坚固的水泥板的用处越来越小,保证又长又硬的同时,还得“养芯儿”和“戳洞”。不过,“芯儿”养多了没洞放,拿不了就只能扔;洞戳多了没有芯儿,整块板儿就会变脆弱。更不用说,在自己身上抽芯儿,戳洞,也不是一般的疼,不容易。
你同意么?

在ThoughtWorks,PM的一周是怎样的(3/3)

第一部分

第二部分

周四

和大家配合的工作有
  1. 站会。昨天又强调规则以后,观察一下今天是不是改善了。如果没有,不是说明大家都傻,而是大家没把你的话当回事。如果真的这样也没事。等跟他们熟了,他们就不好意思把你的话当放屁了,到时候加上点儿“唐僧精神”就会好的。
  2. 记得昨天约过BA、TL讨论迭代计划的事吧?这个会可能1到2小时,PM主持,确切的说,就是说自己的计划,等着拍砖。相信我,如果半小时开完,BA和TL没有任何异议,那表示你完蛋了:他们一定有自己的计划。如果这事真的发生了,我建议你把你的计划打印出来一份,当着他们面扯了,然后承认错误:“大哥大哥,我错了我错了。你说说你的计划。”正常情况下,这个会上BA和TL会提出很多质疑,这儿完不成、那儿时间紧什么的。如果会后你觉得你妥协的都快疯了,说明这个会很成功。
  3. 终于说点儿高兴的了:晚上聚餐。关于TB这事,如果这是一个新组建的团队,一定要吃。如果大家已经合作过了,并且你非要当“公司省钱之星”的话,也可以省。吃的时候最好聊点儿有的没的,有条件的话,做点儿团队游戏。目的就一个,让大家亲近。另外,虽然你要当一个话痨,调动气氛,但是不要让自己成为中心,而是把那小谁和那小谁关联起来,不冷落每个人。怎么做呢?还记得“大姐”、“叔儿”的Twer可能还回忆得起来,我惯用的就是“无差别随意黑”。
自己做的工作有:
  1. 将讨论后的迭代计划制作成Excel,打印、张贴。和BA、TL达成一致以后,一定要趁热乎打印出来,每个迭代一个列表(一张纸),趁水果时间跟大家说一下:这是项目迭代计划,看一下,有问题赶紧找我。

周五

和大家配合的工作有
  1. 站会。仍然是观察,有大问题的话,会后提醒。
  2. 催开发下班就回家。这个阶段,普通的开发人员是不忙乎的(除非她是个毕业生,补技术栈呢),基本上刚刚进入状态,所以你可以卖个好儿,催他们回家(反正跟这儿耗着也没用),毕竟以后他们就没办法按时回家了。。。
  3. 你在I0的时候就应该已经跟客户确认了UAT了吧?一周了,客户那边再慢,也应该有了点儿进展,所以今天你要给他们打个电话确认一下。这个电话的目的只有一个:客户是不是把尽快准备UAT这个事当放屁了?哪怕是客户说“我们已经下单购买服务器了。”也算是一小步,尽管等服务器到货,上架、准备环境,可能是2个月以后的事情,那至少说明客户把“尽早准备UAT”这话听进去了;如果客户说“没呢,不着急”。那就说明你的话又当屁了。那怎么弄呢?该催催,该找销售找销售,该找领导找领导呗
自己做的工作有:
  1. 检查BA的工作,减压加任务。今天是最后一天,中午以前设法在不打扰BA的情况下,弄明白他本周的工作都完成了没?我建议PM自己看,Trello不都有么?千万别把BA叫过来,让人汇报个1小时(第一,你又不是领导;第二,你又没娶人家)。偶,别忘了,如果没完成,中午请BA吃个饭,席间呢,减压加任务呗,呵呵。
  2. 检查TL的工作。和检查BA的工作一样,别打扰TL。一般来说,做技术的都比较小心,TL更是老油条,他答应你的工作本身就不会很多,今天周五了,他事恨不得昨儿个就完了。
  3. 应付其他的非项目事情。除了项目,也会有一些杂事,这点在TW已经算非常好了,很少。但是也得花点儿时间忙乎不是?
一开始写这个的时候根本没想到会写这么多,写完了一看,我去,还真不少。怕你看烦,分成了三篇。
自己又看了几遍,挺想以前日子的。

在ThoughtWorks,PM的一周是怎样的(2/3)

接上篇《在ThoughtWorks,PM的一周是怎样的

周二

和大家配合的工作有

  1. 站会上再次观察问题。站会别弄成形式,确保大家在站会上说的话对项目有好处,是PM的本职工作。每当发现问题的时候,不要占用会上的时间马上纠正,不妨再观察一天,这也就是周一、周二两天都观察的原因;
  2. 和客户确认明天周例会的参加人和时间是否有变动。我的项目一般会把跟客户的例会安排在周三下午。一来,周一、二一般都会很忙,你拉着客户开会,他人在心不在更难受;二来,别等到后半周开,如果客户有变动,还有1到2天的时间修改。前四次例会,都要提前和客户确认,没养成习惯之前要培养。我记得有一个PM跟我讨论:“例会的时候不要提前跟客户说,到时候一开,打他个措手不及,这样客户稀里糊涂就开完了。要是提前提醒,他们万一变更个计划,就完了。”我记得我当时的回答是:“你四不四撒?这又不是暗杀?措手啥不及?过两天他得出空来想变更了,能不给你打电话?到时候傻的还是你啊?”所以,记着别给客户弄这“措手不及”。(利用客户政治斗争弄死他一个人的情况除外)
  3. 预约TL的时间,讲一下项目架构。你跟他说:“不用准备,粗略说一下,就10分钟。”不过,如果这个TL真的10分钟以内就说完了,那你悬了,绝对不是他技术不过硬,而是他没看上你这个PM。这个后面会说。话说回来,即使只是10分钟的会,也要提前说,绝不要给你的队员突然袭击。

自己做的工作有:

  1. 准备周例会的内容。尤其头几次例会,一定要跟给客户好印象,让客户觉得在会上的确有讨论的东西,而不是形式会议。而这,都得策划。一个人成熟的标志就是“相信这世间所有的自然而然都是有人背后辛苦策划的结果”。如果需要BA、TL的帮助,中午以前跟他们说。当然尽量能不麻烦他们的就不麻烦。
  2. 继续制定项目计划。制定项目计划绝对不是个拍脑袋的事,需要花时间想清楚,现在的用手拍脑袋,将来换成搬砖拍。
  3. 继续观察开发人员的负荷。
  4. 确定各个环境是否可用。比如CI、Git,上周PM应该拿到了这些系统的登录方式,登上去看看,这点儿事不用和活人确认,自己看最保险;

周三

和大家配合的工作有

  1. 站会。连续观察了两天了,如果还是有问题,PM要在今天的站会开始前,再次强调站会规则,说问题。另外,站会结束的时候,提醒一下:1、下午和客户的第一次例会
  2. 通知大家明天晚上聚餐。
  3. 客户例会。例会上PM主持(除非你的BA抢着主持),如果需要,BA可以参加,不过最好自己搞定;有一个例外,如果不是远程例会,是在客户现场,客户那边4,5个人,而且都是“部门领导级别的”,最好PM也带着BA和UX,显得重视。这是唯一的理由,虽然比较扯淡,但是也比客户下一次也一个人参加例会强。
  4. 预约BA和TL的时间,讨论项目迭代计划。三天了啊,项目计划应该差不多了,如果还没完,今天晚上自己加个班也得弄完。记得这真理:PM的计划,如果BA或者TL看着扯淡,那就真的是扯淡。
  5. 还记得昨天约过TL么?今天听他讲,相信我,一个纯种的TL说起来技术架构,如果他想说,10分钟是绝对说不完的。如果你是一个不懂技术的PM,唉。。。怎么说呢?我也不知道怎么救你了。如果你懂点儿,那就把你的“提醒”提出来,注意,不是“建议”是“提醒”。什么叫“提醒”?就是你觉得肯定会出问题的地方。

自己做的工作有:

  1. 给BA减压加工作。项目的前几周BA的工作的确非常忙和重要,他们的压力会比较大,所以你要给他们减压。同时,由于事情多,肯定有一些落下的、不全的,你要给BA加上去,这就是“减压加工作”。听着是不是有点儿矛盾?解释一下啊,减压指的是精神层面的;加工作是物理层面的。人是可以“压力小的做很多事情的”。用什么办法减压加工作呢?自己找方法吧。老Twer如果还记得“大姐儿”、“叔儿”是怎么干的,可以给新人讲讲;
  2. 例会完了以后紧急调整本周工作。如果自己没想好,先自己想,有主意了和BA、TL讨论,然后修改本周计划;

未完,待续。。。

在ThoughtWorks,PM的一周是怎样的(1/3)

在ThoughtWorks,PM是受“歧视”的角色,因为他们的工作是“透明”的。确切的说就是“最好让项目组感受不到PM的存在”,或者换句话说,“PM努力工作的效果”最好让项目组觉得是“他们运气好,自然而然的顺利”,而不是背后有一个PM“玩命干活”的结果。
看,不要有存在感,这是PM最基本的素质。
我从一个项目的中前期(确切的说,就是I0刚完的时候)抽出一周,按天说,将一下PM是怎么活过这一周的。

周一

和大家配合的工作有
  1. 早上站会。到了这个阶段,应该早说过站会规则了,虽然不用每次都强调,但是要每次都观察,看看站会是不是有问题。在周一的站会PM要发言(即使你想做一个“大甩手”的PM,周一你也要发一次言),说一下本周都要完成的大致目标。顺便说一下,PM这个阶段主要盯住BA和TL两个人就行。
  2. 中午订餐,让上周安排好的一人做session,主题随便,目的就是一起吃饭,有个谈资。这样大家才能逐渐熟悉起来,熟悉了才能互相说话,互相说话才能有火花的出现。作为PM,千万别忘了营造“哥哥、姐姐、弟弟、妹妹”的气氛。
  3. 和BA闲聊,时间可以选在下午2、3点,吃完饭犯困的时候,一起喝个咖啡,瞎聊20分钟(买咖啡的来回),言语中表达出这么几个意思:“项目初期都是BA忙乎,一定要尽快把所有的卡做出来,可以不细,但是要全面”、“忙过这一阵,后期就不那么忙了”、“有任何的问题尽快找我”。如果你和BA已经特别熟悉,这套话说了好几遍了,恭喜你,咖啡钱可以省了。
自己做的工作有:
  1. 查看各个角色的配合情况。因为团队是一周前刚组建的,人与人不熟悉,PM要观察一下谁和谁“天生就好”、谁和谁“面向犯冲”,心里有谱;另外,一群不熟悉的人在一起最大的问题就是“信息发布”。由于不熟悉,大家都倾向于不说话,尤其不当众说话,这时候除了你要当个话痨之外(话痨是会传染的,一天到晚跟郭德纲在一起,你还学不会个贫?),还要引诱他们说,当然,你不能强迫别人说逗贫的话,但是可以强迫他们说项目相关的,比如前端开发给后端说一下前端框架用什么?比如BA给开发说一下Sketch是个啥?这都是信息发布,养成团队之间“信息发布”的习惯;
  2. review已经出来的Epic Story。相信上周已经有一些Story了,review一下,确定BA的水平和产能。当然,如果你和这个BA已经熟悉了,恭喜你,这事儿你可以做的不认真点儿;
  3. 了解技术栈和技术架构。相信上周已经有了一些基本的技术栈和技术架构,如果你不知道,至少了解个皮毛吧。跟TL聊天,框架名字读音不准是很丢人地。。。TL如果听你说:“咱这个后端是用’春’架构吧,’春mv’听说挺牛的,偶,对对对,后面还有个c呢,靠”,估计他以后会躲着你走;
  4. 回顾整个Inception和I0,开始制定项目计划。制定项目计划一定是PM的活,这活没有高科技,想全面就行,BA也能干,不过如果你真把这个交给BA干的话,除非你娶了这个BA。让他又得往全了想,又得往细了想,会疯。项目进度计划,一定要在第一周出来,否则PM面临的就是团队没目标,没事干。猜对了,在这个阶段,进度计划就是瓶颈,只有PM能解决这个瓶颈。
  5. 观察开发人员的负荷。项目组刚刚组建,开发人员此刻是最轻松的时候,他们的状态也不会太差,这时候要观察一下开发人员的状态,了解每个人的工作负荷和整体的工作负荷,还记得上一条是什么么?制定项目计划,工作负荷你都不知道,怎么做计划?
  6. 和客户联系人沟通,告知本周需要配合的事情,确定获得反馈的时间。如果本周有紧急的需要客户当周搞定的事情,一定周一就催,别等到周五,周五下午客户给过你资料,你求团队说“要不咱周六加个班”,多丢人?还要不要点儿脸?
未完,待续。。。

说话的顺序很重要

人嘛。是人,说话就颠三倒四的。
不过,说话的顺序直接决定了沟通的结果。我举几个例子啊。

比如你可能知道这个:
“屡败屡战,屡战屡败”,你一听,这描述的就是一蠢货啊;
“屡战屡败,屡败屡战”,不改变“战败”的事实,但是你是不是觉得这哥们有点儿韧劲儿?
所以下一次你想“侮辱”销售的时候,是不是可以说她“屡败屡战,屡战屡败”;你想保护她一下的时候,换成“屡战屡败,屡败屡战”是不是好点儿?

再比如这个:
“理无可恕,情有可原”,我们说一个人犯了大错,比如不尊重同事了或者不注重精神文明了,这么说她是不是这亲基本上就没事了;
“情有可原,理无可恕”,你感受一下,是不是她有点儿“悬”了?

再说一亲身经历,有次遇到一“不开窍”的客户,一事情解释了一万遍仍然不明白,表达这事儿有两种方式:
第一种:“我跟你说了一万遍了,这事是这样的:XXXX”
第二种:“一万遍了,我跟你说啊这事是这样的:XXXX”

我当时选择的是第二种,还在前面增加了一个语气助词“唉”。你感受一下啊,有没有点儿给人的感觉是:即使说了一万遍了,仍然还想再说。作为客户,他就不好意思不再听一遍,尝试理解一遍。而第一种呢?不用说了吧,客户一听前半句,就封闭沟通渠道了,即使你又说了一遍,但人还是没听进去。

感受到颠倒的力量了么?还不明显?

再举一昨天的例子。
我闺女和另外一个小朋友看我玩一个对战的游戏,一左一右坐我边上。对方犯了一个低级错误,我赢了。
我左边的小朋友说:叔叔真棒,跟你PK的人真傻!
我闺女在右边也想夸我一下,炫耀一下自己爸爸嘛,就说:对,我爸就爱跟傻子PK!

你感受到了么?反正我当时,立刻就不想再玩了。

论语 心得:不患人不知己,患不知人也

这句话的意思是:别总想着别人不理解自己,要常常想是自己不了解别人。孔子嘴里的“换位思考”。
“换位思考”,大多数时候我们做不到的原因是“不愿意做到”。不是不知道它的好处,不是不知道怎么做,不是不会做,而是不想做。

满座网有一个销售,老钱(必须是化名)。老钱一开始只是某分站的负责人,干的非常好,后来升到到销售总监,管理全国上千名销售完成每月几千万的销售额。不过他离职后发生的事,让我对他的看法完全变了。他离职后不久我发现有一个内部的账户消费异常,这个账户是为了灵活处理一些事情的,比如“销售给商家做演示,怎么购买,怎么付款,怎么结款”,再比如“先收来商户预付款以后,销售可以为商家批量代购”等,帐号使用满座网虚拟币,不需要实际支付一分钱,能生成真实可消费的订单。
就在老钱离职一周后,我发现这个账户出现了一笔不正常交易,而后一个月内,老钱的这个账户又有两笔不正常交易。那天下午我给老钱打电话询问情况,老钱说:钱,商户已经打给财务,他现在即使在用这个账户消费,也是花商户的钱,满座网没有损失。说实话我讨厌极了这样的对话,不愿意争论“占商户的便宜也不对”这个话题,迅速挂断了电话后,就和财务确认,结果不用猜都知道,这笔钱根本没有打给过财务,财务问我要不要处理一下,我说:算了,八、九几百块钱,别折腾了。
当时的满座网好比破了窟窿的帐篷,在暴风雪下不知道什么时候就会被掀翻,碰到这样的事情,我心里很沮丧,有种“破鼓万人捶”的感觉。

人,当被情绪控制了以后,“换位思考”就成了一句空话,当时我只想怎么“还手”。

事情发生一年多以后,当我了解到老钱的“被主动离职”以及离职前充当“分站解散大使”的角色(我曾经解散过几个分站,我知道“解散”这两个字背后意味着多少的谈判和煎熬),我也只能一声叹气:唉,其实丫也挺不容易的。直到这时候我才体会到老钱用这个账户消费的时候为什么能做到“心安理得”。我也有些后悔当时那天提交的那小段程序。

那天从财务出来,我觉得特别生气,一个写代码的,生气能怎么办?还是写代码。回到座位上我分析了一下老钱这个账户的所有交易,增加了一段代码,逻辑是这样的:
  • 从老钱经常消费的商户和现在老钱这三笔消费的特征,找出客单价800 – 1200的并且及时验证的商户;
  • 如果老钱账户消费超过800元,则商户验证的时候出现提示:此单购买有误,请联系消费者现场付款;
  • 然后自动把商户,消费金额等信息给我发短信;
  • 最后自动封了这个账户;
一周后的一天晚上10点多,我收到了短信。此时老钱应该很后悔用这个账户买了两张599的团购券消费。不知道这时候商户会按照1198的团购价,还是按照888一张的原价和老钱结账。我登上后台,确认了一下账户的状态,舒了口气,接着干活。

从满座网离开以后,经历了这么多,我觉得“不再有我不理解的人了”,我的“线”越来越模糊,在下一个公司遇到的老方(必须也是化名)是最接近这根“线”的。
我入职以后,有人曾经跟我闲聊起老方,让我躲着点儿他,少打交道。但是我第一个项目就是老方的,躲不开。跟老方打交道一段时间以后,我觉得这个人还行,大多数时间虽然有些偏执,但是心不坏,乔布斯还偏执呢。
后来老方的变本加厉有一段时间让我特别痛苦,严重怀疑“老方完全不考虑自己”,自己也完全做不到“理解老方”。后来我看到了这三句话,开悟了:
The first to apologize is the bravest.
The first to forgive is the strongest.
The first to forget is the happiest.

我觉得forget应该是最高的境界了,老方的故事我可能永远都做不到forget,我能做到的是让这个故事“褪色”,故事还在,已再没有了愤怒的颜色。我选择原谅老方,准确的说是躲开老方。
说起apologize,我觉得我欠老钱一个道歉,下次遇到老钱,我会跟他道歉。