空芯人

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

聋子系列 – 微调

写在前面

曾经有个聋子看人放炮仗,说,怎么好好地一个花纸卷,放地上,一会儿说散就散了呢?因为他的感官缺少了一个维度,因此他没有办法理解爆竹怎么引爆的。
作为PM,你在生活中可能是一个特别二的人,但是项目中你只能敏感。
“聋子系列”一共三部分:
“信息透明”部分集中说一下如何发现、解决信息不透明的问题;
“微调”部分说的是,进入项目组以后,如何逐步调整自己和团队;
“检验”部分说的是,敏捷项目中的项目检验指标;

透明、微调适应、检验。你觉得这三个关键词还用在哪儿了?

微调

只有在瀑布方式开发的公司待过一段时间,才会知道瀑布流的工作方式在他们脑子里面是多么根深蒂固。尤其是以微软技术为技术栈的公司,他们对于MS Project是多么熟悉和运用娴熟。

没错,上几周我做的就是项目计划这事。我不是PM啊,我只是帮忙写Proposal的,在我愁眉苦脸的思考着某英文应该怎么写才“官方”一点儿,打算问问边上PM的时候,转头却看到她也是一副愁眉苦脸样儿,屏幕上赫然是MS Project。还没等我开口问,她倒先说了:“我记得你说过,你原来是PM?”我回答她:“对,没错。项目计划我们从来不用MS Project,因为根本想不清楚细节。”她惊诧的看着我,我想可能是出于两个原因:
第一,我怎么知道她要问我什么?
第二,我怎么知道她的困难在哪儿?

她叹了口气:“是啊,我怎么知道这些项目细节呢?需求都不知道。我得在需求调研完了以后才能做项目计划”
我说:“你又错了,即使需求调研完了,项目计划完美的做完了,也只是大家觉得满意、高兴、完美,而实际上,慢则一周,快则一日,需求就变了,刚刚满意的项目计划就要重做”
我想起来刚到ThoughtWorks的第一个项目,热衷于显呗“项目管理”的“硬技能”,做了个完善的甘特图,资源占用完全没有空隙,任务顺序安排的妥妥的,给TL看,他第一句话就是:我们不用甘特图。
我当时有点儿抽,反问:那就没有项目计划么?
几年前的这个问题和那天那个PM问我的一样:“要是用敏捷,是不是就没有计划?”
这又让我想起了3年前的一个项目,客户的名字不能透露,但是他们的Logo酷似扇贝,加上客户所在城市临海,所以项目聚会扇贝必点,必须带壳儿 ,清蒸、烤,怎么解气怎么来。在一次例行的扇贝餐时,项目组被我们尊称为“大哥”的大龄女青年,一边拿筷子敲一个空壳,一边说:“你知道么?大叔。他们老觉得敏捷就是没有计划,不用项目管理,所以从根儿上不愿意付咱俩儿的钱,觉得咱俩儿是闲人。其实敏捷不是没有项目管理,而是管理的更精细了。”
我把她敲得那个空壳翻过来,摆正,Logo冲着她,“对啊,我觉得你说的对,就是把原来集中在一起的项目规划打散在数十个迭代中,随时规划和预测,PM可不是没事干。”
“可不?我每天都快TM忙死了,还觉得我闲。大叔你可能一天闲的蛋疼,我不管,我可不是啊。”大哥最喜欢的事就是那我开涮。
我把走神的思绪拉回来,开始回答面前PM提出的问题: “敏捷项目管理,怎么说呢?”我努力的构思用英语怎么说他能印象深刻,“二战,你知道么?二战”我伸出食指和中指比划了一个2,然后接着说:“日本人有一钟鱼雷,叫Kaiten,k – a – i – t – e – n,这么拼写。打的特别准,把美军打的很惨。。。”(我本想说“都打蒙圈了”会更形象点儿,不过实在没想出来“蒙圈”的英文)
“后来美军就纳闷,怎么回事呢?”我接着讲,“后来发现,鱼雷里面是坐人的,发射出去以后,虽然大方向不变,但是可以随时微调,这么做的结果就是,在发射前不必很精细的计算弹道,那时候也没有计算机,全靠人,发射前准备时间就少了,况且就算计算的特别准,但是目标做反应了,不按照预计的移动了,也没用,所以准不准要靠以后 微调。”
“在一开始粗略定义计划,然后项目中再随时调整,你是说的这个意思么?”没等我把这个比喻落实到现实,她倒是先明白了。
“对。所以敏捷PM不是不用做项目管理,而是做的更精细了。”我引用了“大哥”的话,还加了一段“而且,更讲究在什么时候做什么计划,做什么颗粒度的事情。比如现在,什么都不知道,根本没办法做细粒度的项目计划。MS Project是个好工具,但是不足之处呢,它会强迫你把所有事情想的很细,问题是在这个时间点上,你能想细么?”

“不能”她说,“特别同意。那我们怎么办?”

“这。。。”看着她可怜巴巴的样子“我来吧,你把这章留我吧”。你说你碰一这金发闭眼的跟你装可怜,你能怎么办?老话怎么说来着,谁的闺女谁不心疼?

两个小时以后,我给他了一这个:

“要是客户想要一个具体的怎么办?”她问我。
“靠说,有时候客户想要的不是一个真理,而是你给他说的看似明白就行了,他自己第二天就会忘了自己问什么了,只记得昨天自己的疑问被解决了,这就够了。”我把PM心法拿出来讲给她。
“好,下周三跟客户面谈,咱俩个一起去吧?我把邀请一会儿转你一份。”

狗带啊!

聋子系列 – 信息透明

写在前面

曾经有个聋子看人放炮仗,说,怎么好好地一个花纸卷,放地上,一会儿说散就散了呢?因为他的感官缺少了一个维度,因此他没有办法理解爆竹怎么引爆的。

作为PM,你在生活中可能是特别二的人,但项目中你必须敏感。

“聋子系列”一共三部分:

“信息透明”、“微调”和“检验”

透明、微调适应、检验。你觉得这三个关键词还用在哪儿了?答对有奖哈~

言归正传,第一篇:

信息透明

记得有一个项目,客户在一开始的时候给了我们一个PPT,是他想做的创业项目。做敏捷项目的都知道,咱不能上来就干,必须分析一下Vision、Persona、User Journey,然后出Story、Wireframe,技术框架、最后出项目计划。这份东西要和客户讨论,同意以后再动工才有谱。我作为一个“资深”PM,特别注意和客户确认,Inception(上面的几个步骤)的3周时间,每周都和客户例会,顺利完成了Inception。但是接下来要做Prototype的时候,还是出事。

客户发飙了:我已经有了Prototype,你们为什么还要做?

我也迷惑了:哪儿来的Prototype?咱前几周说的东西还有大量的变化修改呢,您自己这还不靠谱呢,哪儿可能有Prototype?

继续发飙:我在项目第一天的时候就给你们Prototype了,这几周你们干的活,我以为是为了直接开发呢?合着说,这几周你们干的活是为了重新做Prototype,那我时间和你们时间都白浪费了。

那场面老尴尬了。。。

回去以后,我立马翻文档,百分制一万了,就一个PPT。我又给客户打电话,问他:我只收到一个项目意向的PPT,你说的Prototype是那个PPT么?得到客户肯定的答复:嗯哪。

我当即撂了电话,出去抽了一根。。。

的确,那个PPT里面是有5个图片,像这样的:

fb-fake-news-reporting-germany

还包括两张像这样的:

ba615c36505729.571f15fd4e98b

可关键是,我一直就没拿他们当Prototype啊,我的亲!这不是典型的“Idea的示意图”么?

随即打过电话,解释了半天,未果。人客户说了,我把这5个图从PPT里面截图,然后放在手机里面,给人做演示的时候,所有人都特别喜欢,所以才打算做这个创意的,当初请人做这个PPT的时候可是花了大钱了的。现在你说改界面就改界面,那不扯么?

就这样,从Wireframe开始就得返工了,视觉走查,那更白做了。

知道哪儿出问题了么?

千算万算就差了一点,没有让客户明白Inception的目的是什么。如果让客户知道Inception的其中一个目的,就是根据我们达成一致的想法,出一个Prototype,然后才能做MVP,就没这个事了。

如果说和客户要保持项目的目标、进度、任务透明,和团队之间保持这种透明度就更加重要了。我见过一个PM,项目组的工作完全被主力组员左右,作为非项目管理人员,那位主力不可能有项目规划的想法。所以项目组明天干什么,后天干什么完全是今天说了算。也没有个最终目标。

那个PM哭诉:项目进行中,很多没有头绪的事情,计划做了也会完全改变,况且那个主力队员也完全不配合我做的计划,这个项目计划没办法做啊。

我跟他说:这些都不是没有计划的理由。从今天开始,就干两个事:

第一、一定要做计划,两周做不出来,就做一周:下周的,然后全组员统一,并且本周就着手准备下周的任务,铺平道路;

第二、如果项目主力队员强势,就凡事都和他商量,让他做主,让他规划。但是“必须有规划”这件事没得商量;

说到怎么透明和引起团队(或者客户)的重视,不妨把这事当成借钱,就简单了。假设我管你借100万,你又必须借,因为你做大保健的证据抓在我手里,那你会怎么办?

第一、写借条,让我签字,是不是?

第二、隔三差五的,请我吃个饭,让我想起来还有你这个人,这回事,是不是?

第三、如果发现我有不还钱的倾向,死缠烂打,促膝谈心,是不是?

第四、所有招儿都没用的话,找几个小流氓,在我家门口泼猪血,写满“欠债还钱”,是不是?

作为PM,做到信息透明,全员重视,完全可以照搬啊:

第一、凡事和客户商量,达成的一致让客户签字;

第二、隔三差五的,请团队吃个饭,让团队想起来,还有一个“虽然不干活”,但是人还不错的“哥们”;

第三、如果发现某个人(客户或者组员)有不按计划的倾向,死缠烂打,促膝谈心;

第四、如果发现的确管不了了,把所有计划打印、张贴在显眼的位置(团队的必经之路和客户办公室门口都是好地方);

只要你没有做大保健的把柄抓在项目组手里,你怕啥?

在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. 和客户联系人沟通,告知本周需要配合的事情,确定获得反馈的时间。如果本周有紧急的需要客户当周搞定的事情,一定周一就催,别等到周五,周五下午客户给过你资料,你求团队说“要不咱周六加个班”,多丢人?还要不要点儿脸?
未完,待续。。。

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

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

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

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

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

那天从财务出来,我觉得特别生气,一个写代码的,生气能怎么办?还是写代码。回到座位上我分析了一下老钱这个账户的所有交易,增加了一段代码,逻辑是这样的:
  • 从老钱经常消费的商户和现在老钱这三笔消费的特征,找出客单价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,我觉得我欠老钱一个道歉,下次遇到老钱,我会跟他道歉。