搬砖和搬砖机

码农的命就是搬砖。

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

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

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

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

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

搬砖指开发商业软件,比如满座网,比如企业内部系统,比如抖音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个月以后仍然没有动静的话,就得和客户谈了,两种情况:

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

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

有甲方PM参与又能咋地?

奴隶在经历了种种努力之后,终将会进入这个状态:“你们可以奴役我的身体,但是不能奴役我自由的思想和灵魂!“革命先烈也曾放狠话:生命诚可贵,爱情价更高,若为自由故,二者皆可抛。

可但是,有甲方PM参与的项目,人家就是既要奴役你的身体,又要奴役你内自由的灵魂,咋弄?

做这个项目以前,其实我并没有太多意识到这个问题。这很大程度上是因为我对中文语言的掌握。你不得不承认,你的确很难在谈话中奴役一个相声演员的灵魂(尽管你可以奴役他的身体:给钱就得给爷演)。有机会的话你自己试一下就知道了,当这孙子说10句你只能说1句的时候,你还想奴役他?

这就是语言的魅力。可到了别人的国家,说人家的语言,这落差可不止普通人和相声演员的距离。

很多做技术管理的到了北美,都宁愿做开发,而不是老本行,我现在特别能理解,做技术管理本来就累心,如果面对的还是不同的种族,说着不同语言,累心的程度可想而知啊,得早衰。说说我这个项目哈,项目组5个开发,2个测试,1个BA,1个TL,1个PM,1个架构师,11个人,来自三个公司的一群雇佣兵,一个中国人,一个土耳其人,其余的都是土著。会不会猜我是PM?这次不是,标题不是写着么《有甲方PM参与又能咋地》,我也不是架构师,万恶的资本主义国家怎么可能让社会主义国家的人做架构呢?架构师也是甲方的人,一个奔6的老哥,大板牙,吃东西时候跟铡草机似的。

我是那个TL。

项目技术栈么?Java,Microservice,API后端占比80%,这对于我倒没啥,虽然我做了这么多年PM,这点儿小破事还能对付。

第一周,我的确表现的像一个纯种TL:确定技术选型,和团队聊天确定团队能力,着手搭建基本框架,准备CI,做一切我在TW眼看着2BTL做的事情。转眼一周过去了,转眼又3天过去了,没见PM和架构师的影子,满屋子的人转眼下周就没啥事做了,我这强迫症又犯了,于是抄起电话给PM打过去:我们技术准备差不多了,请您指示下一步行动计划。我真是这么说的,特别生硬吧,能说出来就已经是大大的进步了。你猜PM怎么说,PM说他们这几周顾不上这个项目,让我们做足技术准备。我愣了3秒,随即直咂舌:这TM资本主义是有钱,已经做两周准备了,再做”足“又能足到哪儿去?好歹有个捏脚的服务也行啊,也能做足准备。偶,忘说了,这个项目没有目标,我们只知道要做一个”通用“的模块,能把任何数据库、文本文件的内容显示在网页上,仅此而已。根据我的直觉吧哈,目标都不清晰,再准备也是闹着玩。我倒不是不想闹着玩,只是都成年人了,放着那么多好玩的不玩,玩这个有啥意思?想到这儿,就回答PM:要不我弄项目计划吧。

从这句话开始,我这个自带PM光环的TL就翻开了PM的那篇。

在随后的一周,我开始准备故事墙,培训敏捷开发,确定主要业务流程,给余下的8个人分工开始干活。。。

项目开始一个月以后,我们第一次Showcase给PM和架构师看,这是他们兄妹俩第一次来项目组,我们展示了一个可运行的代码,他们看了以后,连说数个”牛逼啊“,然后那快60的架构师大哥说:我们得做一个可配置的,比如,”当有另外一个数据库的内容需要展示的话,不用写代码“。团队当时有点儿懵逼,我赶紧打个圆场“但是总的来说,我们的Showcase还是成功的!”,然后背地里我死说活说的要求架构师下周至少2天和我们在一起,详细说说”啥叫不用写代码“。。。

在项目的第三个月,我们终于搞出来了大哥要的东西,PM大姐比大哥还高兴,特别的高兴,买了一桌子寿司请团队吃,就着冰可乐。吃的我第二天直接sick leave了,在床上捂着肚子喝热姜汤的时候,大姐给我发短信说:项目完成的不错,又买了我们这群人三个月。我说:行,我明天就回去。不过等这次三个月到期了,咱能吃点而热乎的么?

(未完待续)

我是怎么弄砸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成的预测简直天壤之别。就这样,我是真不想主动跟那个客户打电话确认东西,项目的事情咱不说,占用人时间咱也不说,一句话让人家重复咱还不说,那你总得让人有种“聊天 ”的感觉吧,可是就连这,我也没太大把握。
现在我能体会到我那个亲的感觉了,那种死都不想跟丫解释浪费彼此时间还闹不愉快的感觉了。
不过,话得说回来,都这样了,项目能不砸么?
当我意识到,我自己成了一个“需要我帮助的对象”的时候,虽然对这个项目来说已经晚了,但是对我来说,一直都不会太晚。微信的签名被我改回“不着急,不害怕,不要脸”,共勉之。