广州一直在下雨。

淅淅沥沥，磨磨叽叽。住的地方十分潮湿，玻璃上都是水珠，蒙蒙的。门也由于吸饱了水汽，变形了，关不上。

按照宣传的说法，这是一个多少年一遇的潮湿的春天，嘿嘿，我是有多么的好运，这是正儿八经的在广州过的第二个春天，就赶上了多少年一遇的潮湿。运气真不错。

从项目现场撤回公司，买了两台1u的机架服务器。

一台CVS+BVT，一台数据库+日报+BUG系统+备份。

硬件真是降价的厉害，6000，两台，二手货，之前编译需要接近2个小时，现在只需要20多分钟。

花钱了就得办事嘛，这是规矩。

我做主淘的二手机器，在那个预算下买全新的机器，估计编译下来还是需要1个小时左右的。

一得瑟就说自己买的是刀片，让同事BS得不行。

搬回公司反而和小曹沟通的少了，教了他几招五禽戏，讲故事这事，得找机会继续才行。

比如，一起喝点酒的时候。

YK同学的状态不错，外企养人，小曹说，华为的个体效率并不高，而集体效率很高。

是因为他们有这样那样的规范去保证。

想来，O记也是如此的。

和他谈起来将来个人的路线，发展，说起自己，想挖技术后，有自己的背景和所长，再做其他的事情。

比如团队，售前，等。

而他的看法却觉得具体的技术已经不太重要了。至少，在他的咨询顾问的工作中，无甚大用。

说起外企和国内小企业的区别，比如客户信任度的问题，这个问题够纠结。崇洋媚外是一方面，不可否认的是，鬼子确实做的还算不错。

这个差别很大，同一家客户，同一个问题，可能客户不会问O记的售前，但是客户真的会问我们的。

上次和客户的交流，学到的，最多的，应该就是领导思维和拔高落实的细节观察和执行力。

也就是J，才能算是颇游刃有余。为此，他一定也付出了很多倍的努力。

没有陪YK同学喝酒，下次一定补上。吃肉倒是把他吃顶了，哈哈。

他的思路的闭环性，逻辑性，和1年前比，进步很大，我很高兴。

我喜欢和希望我的朋友一个比一个NB，然后大家一人拉我一把。

晚上回来和XX同学聊了几句，哎。

就这么着吧，穷则独善其身，对己，莫不是一句好话。

和胖子合完代码，要写点专利和总结了。

和小曹接触的越多，越觉得这人有套路，有意思。

偶尔一起聊天，听来一些开发项目中的故事，权且记之，时候偶温习之，望有所感。

------------关于RDT带来的好处---------------

什么是RDT的模式，哥们只是很皮毛的做了点理解，说明如下：

可以说的是以小团队管理，加强沟通，快速迭代的方式开发。

小团队由R（需求），D（开发），T（测试）三种角色组成。

人数不限，一般以功能模块为团队，三种角色必须同时具备，同时参与项目的全生命周期。

全周期以经验数据为基础参考，项目评估数据为基础，全生命周期分为M0，M1等多个阶段。

每个阶段需要有交付产物，每个阶段结束有数据标准，包括质量标准，模块完成度标准等。

以上是名词解释，下述故事：

话说在做产品BTP时，项目一资源模型，schema定义，在IDE编译，生成JAVA代码。

对于schema的属性，生成对应的java type，type1，type2。

在项目需求阶段，和项目的设计阶段，没有人认为有问题。

IDE每次编译，都会重新生成，好了，当schema文件很多时，生成的java type就会有重复。

A schema生成java type1，B schema生成 java type1。

这样，server运行时，就会有问题，一个java type的调用，不知调用谁了。

这个发现，已经进入了集成测试的阶段。

如果修改，需要改需求，设计，IDE，Server。工作量一评估，2周。

在那个阶段，只能不改了。

本拟 RDT就应该带来这些好处，在开发之前，需要发现一定数量的BUG数。

在需求期发现bug，修改需要2个小时；

在单元测试和自动化测试发现的问题，修改需要一周；设计，server代码，自动化测试用例，单元测试用例

在集成测试发现的问题，修改需要两周；设计，server代码，自动化测试用例，单元测试用例，IDE代码，手工回归。

等到了产品发出去了，修改需要约一个月的时间。

得，这故事本拟说明RDT带来的好处的。

结果却得到了这么一个结论，不管采用什么样的开发模式，人员的经验都会非常非常重要。

------------关于成本核算引发问题---------------

带一项目，公司内部项目成本核算严格，预算多少，每个人成本多少，有严格的核算。

有一哥们，架构部的，贼拉NB了，在项目组工作，做soap1.0的服务封装。

提前工期2个星期完成。

得，这么贵一哥们，不能让闲着啊。

闲着第一是成本问题，第二是，当其他项目组看见他闲着了，一定会从项目组要走的。

那就让这哥们做soap1.2的服务封装。

结果soap俩规范相差太大，1.2的能跑了，1.0的挂了。

紧赶慢赶，在工期结前完成。

经验教训：闲着就闲着吧，不能瞎折腾，轻则数据不好看，扣KPI，重则项目发不出来。

------------关于砍需求---------------

和华为合作，大刀阔斧的砍需求。如：

人员紧缺，在开发最紧急的时候，客户需要改日志格式。如下砍：

1）日志格式和我们的日志分析工具相匹配，如更改格式，后期查问题，就用不上我们的日志分析工具了；

2）我们的售后这一块对于我们的日志体系很熟悉，如果更改格式，我们售后就不能快速响应华为的要求了；

biaji，客户心里犯嘀咕，这样一搞，没带来啥好处却有坏处，得，这需求不加了。

在另外一项目：

客户提出，编辑器双击打开图元编辑太麻烦，如果能在属性视图中编辑就好了。

这是一个大的改动，对IDE是一个较大的冲击。如下砍：

1）双击图元，我们鼠标会自动定位到第一个输入，不需要移动，而在属性视图中编辑，鼠标需要移动，带来开发的不便；

2）双击图元之后，开发人员可以使用tab和enter键全键盘操作，不需要用鼠标，和属性视图一比，开发效率高；

客户觉得，嗯，有道理，这个后面再讨论吧。

凡是砍需求，提到技术难度和工作量的，一般都砍不掉，而站在最终使用者的角度来砍需求，不止客户的需求，连自己项目经理的需求都是可以砍掉的。

另外一项目：

平时沟通，客户项目经理说，我们不能提供热更新，这个偶发性的问题，会查死我们自己的。

ok，以后如果在提出类似热部署，热更新的需求，可以从这方面去砍。

这就是客户的痛处和痒处。

-------------------------------------------------------------

to be continued………………