码农的命就是搬砖。

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

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

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

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

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

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

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

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