关于抵触情绪

一.调试时应用服务器的使用

 

     以前项目组使用jboss做开发调试。同样的应用部署情况下，jboss启动一般需要35s左右。

     jetty做开发调试，整个启动过程肯定在5s以内。

 

但是当这个希望大家试试的想法提出以后，居然没有引起大家的兴趣。

软件研发从诞生之日不久，人们就开始寻求真正的银弹，但是不管我们用什么方法，生产力都很难产生数量级的提高。

于是我觉得起码我们每个人可以做的就是压榨出流程中可以节省的时间，当然首先要保证正确和有效。

 

原因：

     1.一个对小组比较陌生的人的建议或者想法大家还有一些防备，《影响力2》中说，当群众听到所谓的专家（当然我专家还不算）说教，首先人们会怀疑你的专业水平，即使不怀疑还会怀疑你的动机。尤其是对从事自然科学的人。

自然科学者想来以推翻专家或前人的理论为乐（后面会补上一篇文章：《两种文化：社会科学和自然科学》）。

消除陌生并取得信任是做事情的前提。

     2.提起的方式，最好使用替代经验或者讲故事的方式。当然这个还需要实践，有效性有待评估。查迪.汉克斯说，问题分析是可以放在课堂被教授的，但是管理却不行，只有每个人通过自己的实践才能真正成为自己的知识。

     3.当时没有拿出具体的数字，即功课做的不够充分。

     4.在这个team前一个的项目，启动过程是以分钟计算的，所以这个35s对每个team member来说已经是个很幸福的数字了。还有项目中在后期可能需要一个必须依赖jboss的控件。

 

二.对于项目开发过程中，页面标签的抵触。

 

      好像是《人月神话》中提到，工程师往往会把上一个项目的遗憾，加倍的在下一个项目中弥补。

这个新的项目启动的时候就面临这个状况，上一个项目由于页面代码缺乏规划产生很多bad smell的页面代码混乱。

 

      在新项目启动期，构架师开始设计构架，希望所有的页面元素都组件化，杜绝非组件产生的代码。每个项目的工期都是

很紧张的，在没有经过基本的原型构建和论证前，这个构架就开始在实施中应用。

      问题的产生也是必然的，为了实现组件化，原本分离的层次被重新耦合，比较严峻的一个问题是页面布局也需要使用组件，也就是组件库要提供一个比<table>

标签表达更简练，功能更强，并可以整合数据展现的组件。就我目前的智力还是认为不是那么容易实现的。

 

      于是每个member开始在这个不成熟的组件上吃力的排列每个数据项，一个个疑问被提出后，小组也开始出现了明显的抵触，组件还是妥协了，同意同时存在table和组件。

 

      1.这次情形和上次有所不同，个人认为构架师应该具有厚积薄发，在面临即将和可能问题是才能游刃有余。

      2.睡在功劳簿上睡大觉显然要舒服一些，重新爬一个楼梯，开始总是不那么舒服，这是要让大家跳起来去爬的方式是展示给人们足够的有说服力的诱惑。启动‘个人动机’和‘社会动机’。

 

我还是相信因果论的，就像西方人说‘上帝不掷骰子’。每个问题的产生总有原因，而且有可能是无数的原因促成一个结果，但是往往存在所说的“关键动因”（影响力2）。