我是怎么弄砸JobSite的

你玩过梭哈么?
那我问你一个问题:同花顺和一副牌是个什么关系?
在JobSite这个项目上,就是“把5周的项目做成了54周”(你想对了,大小王还不在我手里)。这个月底就是“整副牌”完结的时间,我能负责任的说,一定能凑够整副牌的。
听我仔细说说这个项目。
今年年初,1月份的时候,一个干瘦的人找到我们说要做一个APP,我们管他叫P先生吧,这个项目是一个简单的记账应用,P先生在建筑行业,负责盖房子,不是大北京那种高楼大厦,是小房子,第一个月开始挖坑,第三个月入住的那种。即便这样,一栋房子也会有好多承建商,比如负责门窗的,负责挖坑的,负责砌墙的等等,而总包商需要对他们做管理,协调他们生产,给他们付款,验收成果,还要把当前房子状态拍照给最终客户看。这样一套需求用一个大Excel加上一个共享目录放文件照片就可以搞定,只是不方便而已。
P先生找到我们,说:“后台已经全部做好,PC端的应用也基本上完成了,现在就差APP了,PC端是Restful风格,Json格式数据,理论上就是PC怎么调用,APP就怎么调用。就这么一个事情,你们看要多少钱?”
评估后,技术方案是用.net包装一下API,类似NodeJs包装Java API一个意思,前端用Ionic + angular2,预计咬咬牙的话,一个前端一个后端,哥俩儿2个月差不多能完成这个APP,实在不行,后端那哥们还可以帮帮前端,毕竟他的活儿简单,就是包一层而已。
方案和评估定了以后,被销售砍到了4周,一个月。
砍时间这事儿吧,不分国籍,全世界的销售都是这式儿的:和买裤子一样,照着一半砍。这销售要是TW的G先生,那一定会先喝一顿酒,然后一起看旅游卫视“有多远走(GUN)多远”。不过当时我是一个新人,公司唯一的销售还是合伙人,人家也是第一次砍,我这英语水平也不知道咋个“委婉”的回绝。。。(我还能写200多个理由,都省略了),最后我就说了句:“At least, one more week”,就这么凑成了5张牌。草草开始了。
一周后,后台的哥们提出要离岛到大城市,2周以后动身,考虑到也就是包一层的事儿,就跟他提了下面三个目标:
  1. 尽量在一周内努力完成
  2. 然后第二周可以放松一下,准备准备搬家什么的
  3. 第三周离职、搬家
结果呢,三个目标达成了2个,还不错吧,第二个和第三个目标毫不迟疑的达成了。
跟他聊了一下,得知由于“Java Session”的问题,无法和.net的壳儿做到安全衔接,所以整体方案眼看要扯淡,也就没有继续往下做。
你说咋整?找到CTO说了这个以后,CTO说他有方案可以跟他聊聊,聊完以后要求他再研究两天。两天后我跟进,发现仍然没有进展。又找CTO,以我雅思口语3分的水平和他争论,他意思是“再研究2天”,我意思是“人都要走了,谁给你好好研究?赶紧选别的方案呀”。
结果我赢了。等我说“要找一个Java开发工程师看看Java后台、直接连Java API”的时候,CTO说“就那个前端开发工程师就行,让他自己弄吧”。我照眼看了一下那个大胡子,我们叫他C先生吧,C先生得胡子长的都快分不清五官了,我心里有点儿犯嘀咕:这猴子能直立行走就已经是奇迹了吧。
后来又跟P先生开会,说了这个变故,P先生说,他可以让那个做网站的哥们(我们就叫他E先生吧)帮助我们弄后端的事情,不过人家有正经的工作,帮助我们只能算是茶余饭后的。
见了一面,发现他也是毛发浓密的。我这个脸上唯一毛发就是眉毛的人和两个猴子谈了一个下午,总算弄清楚真相了,才得知真相是多么的可怕:
  • 5年前P先生就开始做这个了,也就是说现在的Java后台是5年前的一哥们写的,话说5年前就Restful Java API,也算是浪尖上了;
  • 4年间,P先生重新做了1.0版本3遍,每次遇到重大问题的时候,Java开发就跟他说“基础没打好,得重新开始”,于是重写了3遍解决了3个大问题,但是功能上毫无进展;
  • 那个Java工程师是P先生的邻居,大学毕业生,闲散无业。前年得时候,在安省找到了工作,飞黄腾达去了,留下第三个未完成的1.0版本给P先生,于是P先生才不得已找到了E先生,无奈E先生只会Web端,这就才有的我们;
  • 那个1.0版本呢,虽然E先生有源代码,不过始终编译不过去,所以根本不敢动,无奈才用NodeJs包装。NodeJs是E先生的新玩具,现在正玩儿得乐呵;
这两个猴子的英语说的太快,以至于我打断了无数次,让他们重说我才能理解个中意思。不得不说,从那天下午以后,我跟两个猴子成了好朋友,尤其是C先生,我的同事,这一年来没少教我说话。
跑题了,跑题了,回到正题。
得知了具体情况以后,我感觉这个项目是这些年来遇到的比较邪门的那种,但是还不至于绝望。于是就计划着,一定要让C先生roll off,换成一个毕业生,减少损失。
5周很快就过了,10周都是一晃而过的。10周后,我如期的把C先生换下,毕业生顶上,为此还安排了无数次毕业生露脸活动以便让P先生放心。
毕业生接手后,我下一个方案是:让P先生逐步看到Java程序不变不行,然后就可以跟我们签一个Java后台的开发合同,在这个合同里面,把这段时间的损失再找回来。对于这个计划而言,毕业生不给力反倒是一个助力。
可是毕竟是个毕业生么,太不给力了,给的助力太大了,把项目推沟里了。事儿是这样的:
有一天CEO给我打电话,说他约了P先生,一起讨论一下项目。这个会就在一咖啡店,我自然是打开记事本准备记录,毕业生也连好了网络随时准备着,然后就听CEO和P先生飞快的说着我完全听不懂的话,伴随着哈哈大笑,就这样说了半个小时,最后用10分钟大致过了一下现在的问题,每次毕业生或者我说出大致预估时间后,CEO都会帮着P先生砍时间,最后我都懒得再争论了。
事后我越想越不对,岛上的人都这么奔放么?为啥CEO和P先生有种一见如故的感觉?
我问那毕业生,”他们说了半天,说的是个啥?”毕业生竟然回答,一大部分他也听不懂,好像说的是CEO的房子怎么样和P先生在岛上的其他地方有什么活儿。我又找到销售求证这到底是个咋呀?才得到了一个惊人的秘密:
P先生是CEO的邻居。他俩儿已经认识了10年!
怪不得,怪不得。。。
想都不用想,用毕业生的不给力“逼迫”P先生重新做Java后台的计划流产了。
还好我还有最后一招,就是把毕业生编入维护团队,以后所有P先生的活儿都按照维护团队计时。我心想:眼看着大把工时投入,没有收入,CEO您自己琢磨吧。
于是30周以后,终于把这个APP纳入到了维护团队,50周的时候,就是上个月,这个APP上线了,毕业生现在全职维护各种线上突发事情,所有工时没有收入,P先生坚持认为“你们的Bug还想跟我要钱?”,也曾经和P先生纠缠过什么是“Bug”,P先生认为“Bug就是APP不是像我想的那样运行,因为我想的已经全部都跟你们说了,不对肯定是你们没理解”。
说实话,我觉得免费维护期可能会持续很久,如果非要给个期限,可能是一万年。
好了,这就是前因后果了,我曾经做过事后推演。拿出“项目标准化对照表”,存在的问题有:
项目开始前:
  • 没有详细的技术方案论证;
  • 没有第三方程序的调研;
  • 没有坚持项目的预估,使用销售的“预估”;
  • 没有让销售介绍各个Stakeholder的关系;
项目进行中
  • 疏于站会,比如一周后才知道.net包装Java毫无进展;
  • 项目组缺人没有引起强烈重视,导致一个人做一个项目;
  • 腰杆不硬气,项目组有时候是需要“威胁”客户的,要知道他最怕什么,最怕什么就拿什么威胁。不过,如果每次“威胁”的结果都是CEO的回访电话,我也是服了。还有一个明显现象,30周到40周,所有的需求P先生都会抄送CEO了,可怕吧?还有更可怕的:从40周后,一些需求由CEO发出,抄送P先生!“或许是他们两个住的近,喝小酒的时候,因为CEO懂技术,所以他描述的比较清楚吧。”我这么猜。
  • 客户关系不熟,找不到切入点。这点是硬伤啊,对于一个东方人,口语这样,刚刚到这儿,连冬天要穿多厚的衣服都还不知道,怎么和土著人混关系?况且,有个懂技术的CEO做邻居,我要是P先生,我也不愿意跟你聊;
项目结束期:(好吧,这项目得1万年,远没到结束期,权且把上线前后当成结束期吧)
  • 没有倒计时的任务列表(这个列表有一个显著得作用“做完了这些,这事儿就完了”),所以导致“P先生认为没完,这事儿就完不了”;
  • 这个项目最后怎么样,谁也没有个说法。包括销售也不愿意豁出脸去要维护费,我更不会去了。可惜了那个毕业生,被豁出去了;
说了这么多问题,其实也有好的地方哈,比如:
  • 有周例会,一开始一周一次,从第十周开始,两周一次,当面Showcase,这就避免了“我说做完了,你说没做完”的扯皮;
  • 技术实践不错,有CI,按照规矩Push、Merge,毕业生学到了很多;
你觉得这个项目咋样?从事后沙盘来看,如果重新来,应该咋做?

空芯人

今天,回家的路上,看见了一件稀罕的东西:
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,你在生活中可能是一个特别二的人,但是项目中你只能敏感。

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

“信息透明”部分集中说一下如何发现、解决信息不透明的问题;

“微调”部分说的是,进入项目组以后,如何逐步调整自己和团队;

“检验”部分说的是,敏捷项目中的项目检验指标;

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

检验

检验并不是什么高科技的词,其实我们身边充满了检验。“检验”通俗的说就是“合格标准”,有很多事情可能你都想不到那个就是“检验”,比如:

赛跑,谁跑得快谁赢,怎么检验?弄根绳子横终点,谁先拿肚子顶上,谁赢;

跳高,谁跳的高谁赢,怎么检验?弄个杆子架起来,谁先拿屁股碰掉,谁输;

想象一下啊,赛跑发令枪响了以后,一伙子人即使不知道怎么算赢,但是仍然人人争先恐后;另一伙子人努力的助跑,往垫子上摔,垫子前面既没有裁判,也没有杆子,但是那伙子人还是兴奋的不行。

这不有病么?这可能么?

那么凭什么做项目的时候就可以没有检验,却期望每一个人跟打了鸡血似的干活呢?

检验,不仅得有,而且得让所有人都知道,得让所有人都能灵活了解。举个例子啊,问一个赛跑运动员“如果组委会找不到绳子放在终点怎么办?”,他可能一下傻了,拍着脑袋说“我去,这问题老大了。。。”么?

但是,如果你拉住一个PM,问他“如果客户又提了很多新需求”或者“如果团队主力病倒了”,再或者“如果BA和Developer对于标准不统一了”怎么办,他还真的有可能傻了,拍着脑袋说“我去,这问题老大了。。。”

这些看似“老大”的问题,都和“检验”相关,听我细说说。

首先,ATDD是指导思想

全称是Acceptance Test Driven Development。为什么加上个A呢?用TDD不是挺好的么?加上A以后,更能够说明和强调这不是一个技术手段,是项目管理手段。而TDD仅仅是ATDD用到的一种技术实践。

ATDD这个东西,用极端的话说:所有的模块都是为测试而开发的。以这个思想为指导,在所有模块构建的时候,就应该想好了怎么测试。换句话说,作为一个开发,如果你发现你即将要做的功能自己都不知道怎么做成自动化测试的,说明你没想好,或者BA给你的就是一个“假功能”。那就放下键盘,先找BA画逻辑图吧,肯定你的理解不全面。

有了ATDD指导思想以后,下面的这些是方法:

code review、Retro

知道这两个活动的人可能会奇怪,为什么把这两个看似不相关的东西放在一起说呢?其实仔细想想啊,他们的作用是一样的,只不过Code review是给技术宅准备的;retro是给项目组准备的(当然也包括技术宅),他们的作用都是回顾过去,找到问题,找到现行和标准之间的差异,讨论改进办法;

kick-off meeting、sign-off、show case、CI

如果说code review和retro是概念性的和粗粒度的,那么这四样东西就是更加具体的行动和做法。

首先,每一个iteration开始的时候,都要有Kick-off meeting,在这个会议上,BA讲解这个迭代中的全部故事卡,PM将这个迭代的目标与大家讨论,达成一致。这就好比赛跑中告诉运动员“看见前面的绳子没有,谁先拿肚子顶上谁赢”;

然后,在这个Iteration结束的时候,所有的故事卡BA都应该已经sign-off了,每一个故事卡完成以后,BA都要确定“按照要求”完成了,这就好比冲过终点后,运动员们对于名词有了认可;

接着,show case meeting,在这个会议上,项目组把产品增量给客户演示,得到客户的反馈。这就好比裁判最终认可了比赛成绩;

最后一个,CI。CI是个啥,CI是Continuous integration的缩写,是一种方法,CI可以保证每一次提交都不会破坏整体的功能,还记得上面提到的TDD么?只有用了TDD以后,CI server才可以完成自动编译、测试、打包等事情,保证一切顺利。

Story card & Planning Wall

这两个东西也必不可少,他们是一个项目的全部载体,在以前,项目的需求“藏”在电脑的某个深层的目录的文档里(除了岛国片你可能藏得更深之外,很难再找到藏得更深的东西了);项目的计划藏在甘特图里面,这个漂亮、光鲜的图虽然随时可用,但是受到责难的苦主一般第一句话就是:这是个“假计划”,情况变了,这个计划是2个月以前的,现在早变了。而此时,PM除了后悔自己没有“及时”修改甘特图之外,还后悔自己没有早点儿认识黑社会的打手。

敏捷开发是怎么解决这个问题的呢?用故事卡,故事卡就是需求,既有描述又有测试标准,团队每天的工作就是围着这些故事卡。Planning Wall就是贴满了这些卡的一面墙,谁说文档就一定要在电脑里面,我边上这堵墙就不能当成一个文档么?

最后,我们说一下:Velocity Estimation

在软件项目中,最难做的“检验”的事情,恐怕就是团队的产能了。

我们都知道,在付钱的时候,人总会问一句:多少钱?

比如你想买一个电脑,销售会说我这里有10种,价格从3千到3万块,相同的电脑我这里的价格不算贵;

比如你想买个房子,销售会说这个房子每平米6万,按照建筑面积算,公摊小,我这里的价格不算贵;

那凭什么客户想做一个软件的时候,人问多少钱,我们就忸忸怩怩的呢?

这又涉及到另外一个问题:你一天吃几碗干饭?

人,最可贵的品质就是知道自己吃几碗干饭。作为一个PM,你除了要知道你自己,还要知道团队能吃几碗干饭。我们先不展开说,就说这个比喻:“干饭”,你是不是需要知道“多大的碗”,“饭有多干”?这些是外部的关键点,你是不是还需要知道“自己当时饿不饿”、“有没有好菜”这类的内部关键点?

单说“干饭”这事,你就已经评估不出来了。何况更加复杂的团队产能估计(Velocity Estimation)。

不过,敏捷项目管理还真的有招:用“故事点”评估。(这篇文章说的是“检验”,所以评估方法就不细说了,想听的话,留个言啥的,我单写一个文章说“敏捷团队产能评估”)

每个迭代以后,PM都会得到一个新的以故事点为单位的团队产能,PM要做的就是拿这个与以前的比较、预估,得到一个最新的“更准点儿”的产能数据,用于衡量下一个迭代。如果项目的时间很长,比如1年(24个迭代),那么在7,个迭代以后,就应该可以得到相对准确的产能,PM也能拍着胸脯应对客户的这类问题了,因为他会了“检验团队产能”。

聋子系列的三篇完成了,下一系列,你想听听什么么?

你觉得你做不到的,别人可能毫无感觉的就做到了

这个道理我懂,而且很久以前就懂。我给你举个例子啊,比如生孩子。

不过,直到这段时间我才真正感觉到什么叫“不是做不到,而是不想做到”,体会了一把自己逼自己的难受劲儿。也顺便体会了一把“正确的做法和错误的做法就是一线之隔,很容易就滑到错误的怀里”。

话说我现在这个项目,就是那个利用Gamify理论的,准确的估计已经90.82%可能性胎死腹中了。我强迫症,所有的事情只要是不好的结局必然事后一番回味,这事当然也不例外。我回忆了一下截止到现在犯的所有错误:
1、没有和客户沟通就擅自开始Inception,甚至连通知客户“我要做Inception了”都没有;
2、Inception全程没有客户参与,自己团队,确切的说是我一个人加上两个40%甚至更少时间在这个项目上的人;
3、第一次Inception汇报是远程电话会议,没有得到客户的任何反馈,除了“好,干得不错”
4、汇报以后,开始做Prototype,仍然没有客户参与,果然,Prototype被客户一顿狠批,具体情况可以参考这篇《聋子系列 – 信息透明》
5、第一次和客户面对面交流是在项目快死前的两周,面对面沟通才发现,客户原来人不错,两个老太太挺亲切,花了半个小时讲解了Google Doc怎么分享以后,两个老太太基本上认可了我是一有IT经验的人,不过,正经事几乎没达成一致的,大家还仅是面儿熟;
6、从客户那里回到公司,着手修改所有的Prototype的时候,又犯了老毛病:真的不愿意沟通;

终于,上周五项目组开了个会,决定“唉。。。还是让它死了吧”

我记得我一个亲问过我:“我知道PM的做法不对,我也知道应该怎么做,但是我不知道怎么跟他说,你说怎么办?”
我当即回答:“聊啊,说啊,你不说他怎么知道?”
“我就是不知道怎么说,一跟他说我就累,就急,最后就放弃了,我不是一个爱跟人吵架的人”她回答我。
“那。。。那TM就没辙了,你又不说,谁能管你。。。”
后来,我觉得她应该还是和那个PM说了一些,但是仍然没有达到预期的效果,项目还是做得不理想,我也就一直把这件事情当成“年轻人成长的痛”,认为“长大了”就好了。

直到在这个项目中,我自己也变成了她。
唉,我是真TM不想跟他们丫说话啊我是。我曾经认为很简单的事情现在都难得不行。我从没有因为要和谁聊个工作而影响自己任何的事情,也从来没有在任何场合怯场,这得感谢满座网的几年,活脱儿的把我锻炼成一不怕死,二不要脸的典型。你说,一个人,他死都不怕,脸都不要,那还有什么 能让他着急的事呢?

所以,我在某速运公司的项目上“威胁”客户:“需求您要是这么改,我可没办法保证按时完成”
客户软了:“那要不就修改一下文字吧,把这几个Lable的文字改了”。
“一点儿都不行”客户软了,咱必须得更硬。
“好吧,那标记这个Sprint失败吧,项目延2周,现在这样我也没办法跟大领导汇报”
“别,别。跟大领导汇报啊,那咱必须改啊。。。”

我也能在客户故意刁难项目组的时候压住火。在陆家嘴金融中心15层楼上,当客户刁难“你们的PM连项目计划都沟通不清楚,这样的PM我也能去你们公司当!”我明知道项目组已经尽力做到最好,是客户朝令夕改、故意排挤我们,但还是以“我们特别欢迎您能来我们公司指导敏捷项目管理。。。。”开头。

“聊”,这事到了我这儿,完全不是一个需要用脑子的事,只要先前想明白对策,现场运用特别随心所欲。不过,限于中文,面对的是中国人,尽管南北不同、方言不同,但是有着相同的幽默感,有着相同的招式。就好比两个武术家,他一撤拳我就知道他在蓄力准备出击,我就知道准备躲,我一近身,他就知道我佯装进攻,下一招一定防守。那是一种什么感觉,是争斗么?明明是默契的配合。摸到规律后,既不气也不累,行云流水一般,玩呗。今天我占你一便宜,明天你吃我一亏,几个项目下来,谁也不亏不赚。

可你有想过一个武术家和街头小流氓打架么?
流氓一个近身,武术家认为他佯装进攻实则防守,于是出脚踹裆,而此时流氓的裆也到了。。。结果呢?死了,鸡飞蛋打。
另一个流氓见此一个撤身,武术家以为他要蓄力出脚,于是护住自己裆。不想那个流氓撤身、转身、撒丫子,跑得比谁都快,嘴里大骂:你丫等着,你丫等着。
先不说输赢,你就说这事,愉快么?行云流水么?虽然没踹到,是不是也蛋疼?

我现在就是这感觉,正经事7成能听懂,玩笑事5成能听懂可只有2成会觉得好笑。聊天开玩笑,只有1成把握能预测对方反应,这和原来9成的预测简直天壤之别。就这样,我是真不想主动跟那个客户打电话确认东西,项目的事情咱不说,占用人时间咱也不说,一句话让人家重复咱还不说,那你总得让人有种“聊天 ”的感觉吧,可是就连这,我也没太大把握。

现在我能体会到我那个亲的感觉了,那种死都不想跟丫解释浪费彼此时间还闹不愉快的感觉了。

不过,话得说回来,都这样了,项目能不砸么?

当我意识到,我自己成了一个“需要我帮助的对象”的时候,虽然对这个项目来说已经晚了,但是对我来说,一直都不会太晚。微信的签名被我改回“不着急,不害怕,不要脸”,共勉之。

自救 – 永远做不到的共感

这个道理我懂,而且很久以前就懂。我给你举个例子啊,比如生孩子。
不过,直到这段时间我才真正感觉到什么叫“不是做不到,而是不想做到”,体会了一把自己逼自己的难受劲儿。也顺便体会了一把“正确的做法和错误的做法就是一线之隔,很容易就滑到错误的怀里”。
话说我现在这个项目,就是那个利用Gamify理论的,准确的估计已经90.82%可能性胎死腹中了。我强迫症,所有的事情只要是不好的结局必然事后一番回味,这事当然也不例外。我回忆了一下截止到现在犯的所有错误:
1、没有和客户沟通就擅自开始Inception,甚至连通知客户“我要做Inception了”都没有;
2、Inception全程没有客户参与,自己团队,确切的说是我一个人加上两个40%甚至更少时间在这个项目上的人;
3、第一次Inception汇报是远程电话会议,没有得到客户的任何反馈,除了“好,干得不错”
4、汇报以后,开始做Prototype,仍然没有客户参与,果然,Prototype被客户一顿狠批,具体情况可以参考这篇《聋子系列 – 信息透明》
5、第一次和客户面对面交流是在项目快死前的两周,面对面沟通才发现,客户原来人不错,两个老太太挺亲切,花了半个小时讲解了Google Doc怎么分享以后,两个老太太基本上认可了我是一有IT经验的人,不过,正经事几乎没达成一致的,大家还仅是面儿熟;
6、从客户那里回到公司,着手修改所有的Prototype的时候,又犯了老毛病:真的不愿意沟通;
终于,上周五项目组开了个会,决定“唉。。。还是让它死了吧”
我记得我一个亲问过我:“我知道PM的做法不对,我也知道应该怎么做,但是我不知道怎么跟他说,你说怎么办?”
我当即回答:“聊啊,说啊,你不说他怎么知道?”
“我就是不知道怎么说,一跟他说我就累,就急,最后就放弃了,我不是一个爱跟人吵架的人”她回答我。
“那。。。那TM就没辙了,你又不说,谁能管你。。。”
后来,我觉得她应该还是和那个PM说了一些,但是仍然没有达到预期的效果,项目还是做得不理想,我也就一直把这件事情当成“年轻人成长的痛”,认为“长大了”就好了。
直到在这个项目中,我自己也变成了她。
唉,我是真TM不想跟他们丫说话啊我是。我曾经认为很简单的事情现在都难得不行。我从没有因为要和谁聊个工作而影响自己任何的事情,也从来没有在任何场合怯场,这得感谢满座网的几年,活脱儿的把我锻炼成一不怕死,二不要脸的典型。你说,一个人,他死都不怕,脸都不要,那还有什么 能让他着急的事呢?
所以,我在某速运公司的项目上“威胁”客户:“需求您要是这么改,我可没办法保证按时完成”
客户软了:“那要不就修改一下文字吧,把这几个Lable的文字改了”。
“一点儿都不行”客户软了,咱必须得更硬。
“好吧,那标记这个Sprint失败吧,项目延2周,现在这样我也没办法跟大领导汇报”
“别,别。跟大领导汇报啊,那咱必须改啊。。。”
我也能在客户故意刁难项目组的时候压住火。在陆家嘴金融中心15层楼上,当客户刁难“你们的PM连项目计划都沟通不清楚,这样的PM我也能去你们公司当!”我明知道项目组已经尽力做到最好,是客户朝令夕改、故意排挤我们,但还是以“我们特别欢迎您能来我们公司指导敏捷项目管理。。。。”开头。
“聊”,这事到了我这儿,完全不是一个需要用脑子的事,只要先前想明白对策,现场运用特别随心所欲。不过,限于中文,面对的是中国人,尽管南北不同、方言不同,但是有着相同的幽默感,有着相同的招式。就好比两个武术家,他一撤拳我就知道他在蓄力准备出击,我就知道准备躲,我一近身,他就知道我佯装进攻,下一招一定防守。那是一种什么感觉,是争斗么?明明是默契的配合。摸到规律后,既不气也不累,行云流水一般,玩呗。今天我占你一便宜,明天你吃我一亏,几个项目下来,谁也不亏不赚。
可你有想过一个武术家和街头小流氓打架么?
流氓一个近身,武术家认为他佯装进攻实则防守,于是出脚踹裆,而此时流氓的裆也到了。。。结果呢?死了,鸡飞蛋打。
另一个流氓见此一个撤身,武术家以为他要蓄力出脚,于是护住自己裆。不想那个流氓撤身、转身、撒丫子,跑得比谁都快,嘴里大骂:你丫等着,你丫等着。
先不说输赢,你就说这事,愉快么?行云流水么?虽然没踹到,是不是也蛋疼?
我现在就是这感觉,正经事7成能听懂,玩笑事5成能听懂可只有2成会觉得好笑。聊天开玩笑,只有1成把握能预测对方反应,这和原来9成的预测简直天壤之别。就这样,我是真不想主动跟那个客户打电话确认东西,项目的事情咱不说,占用人时间咱也不说,一句话让人家重复咱还不说,那你总得让人有种“聊天 ”的感觉吧,可是就连这,我也没太大把握。
现在我能体会到我那个亲的感觉了,那种死都不想跟丫解释浪费彼此时间还闹不愉快的感觉了。
不过,话得说回来,都这样了,项目能不砸么?
当我意识到,我自己成了一个“需要我帮助的对象”的时候,虽然对这个项目来说已经晚了,但是对我来说,一直都不会太晚。微信的签名被我改回“不着急,不害怕,不要脸”,共勉之。

聋子系列 – 微调

写在前面

曾经有个聋子看人放炮仗,说,怎么好好地一个花纸卷,放地上,一会儿说散就散了呢?因为他的感官缺少了一个维度,因此他没有办法理解爆竹怎么引爆的。
作为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,做到信息透明,全员重视,完全可以照搬啊:

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

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

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

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

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