搬砖和搬砖机

3026961-7241e23709360c98
码农的命就是搬砖。

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

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

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

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

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

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

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

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

发表评论

电子邮件地址不会被公开。