让步还是继续前进

哎！可惜就是上层不支持啊，反而捣乱，我们都只能在没有被捣乱的时候抽出时间干点正常事。不过也因为这样，我对老板开始有不满了，而且表现出来了，同样老板也开始对我没有那么信任了，因为我没有同意他很多说法。当然我清楚这个倒是我的问题，我不应该表现出来，而且是我的说话方式有问题，让他能很明显地听出我在反驳他的意见。

对楼主遇到的情形深有体验，说说自己的切身体会，希望能给楼主带来些参考价值。


这里面混杂了两个关键问题，一个是管理层面的，另外一个是技术层面的。

在不考虑公司的规模和管理成熟度的前提下，从管理层面看，如果管理层（老板）连需求调研延期和需求不断变更带来的危害，以及管理层应该做出的相应反应都不清楚，说明你首先需要把这些问题带来的后果展示出来。最起码的，应该让管理层认识到这些原因会导致哪些问题出现。然后，管理层会做出相应调整决策，例如换人、增加资源、与客户加强协调，等等。

从技术层面看，需求不断变更，这是一个客观存在的事实，而对需求变更的控制能力，远不是靠管理层的“保证书”就能搞定的，对需求控制，需要有丰富的行业知识，能够对业务知识做出非常强势的判断和控制，能够在客观上说服客户，而不是靠管理层卖人情和稀泥。

作为技术人员，往往因为自身没有业务知识上的优势地位，会寄希望于管理层说服客户写“保证书”。但实际上在不是很规范的小公司，管理层很少会给开发团队作担保去说服客户写保证书，更常见的做法是换人，换高手，因为管理层认为就算写了保证书，客户一样会变，这种保证书，根本没什么用（事实也是如此）。

所以对于小公司来说，“需求调研的延期，需求的不断变更”在很大程度上是一个技术问题，而非管理问题，从管理层面切入是解决不了这种问题的，换句话说，找老板也没用，搞不好自己还被换掉。要说解决办法，还是会落回老套路上——提高团队自身的业务能力和开发能力，业务能力得慢慢提高，而XP提供了很多很基本的提高团队开发能力的技术手段，尤其是结对和持续集成，可以迅速将团队的平均开发能力提高到团队最高开发能力附近的高度上。


说来说去，提高团队的自身开发能力才是真本事，除非风险已经非常非常明显了，找老板也没用，因为他不是专门搞软件的，看不出来有什么风险。等到管理层能认同了团队发现的风险时，再与管理层一起做项目管理改进吧。
过早地与管理层发生冲突，会对双方都带来伤害，因为此时管理层和开发团队还不能互相理解。从楼主说老板在捣乱就能看出这种情形了，其实老板何尝不是在认为我们也是捣乱呢。

snomile的回复很有道理啊！现在我感觉项目终于开始有点进展了，至少内部的协调和编码能力比一开始好很多，当然虽然有点窃喜，却不敢松懈。因为随时都有突发状况的可能，而这个可能又肯定会引起我和老板的冲突，但是经过这么一说，我想我会学会控制自己，并且表现出来认同与顺从，而我们内部的流程不会因此而改变，希望这样能慢慢改变局面。

冲突的解决，我在这方面也处理的不好。
策略：解决，妥协，圆滑，撤退，强迫。在所有策略中，圆滑最难，特别是理工科出来的做技术出身的项目经理，几乎不会圆滑。这是个性所致，但作为一种技能，圆滑也是必要的。说白了，就是明一套暗一套，口是心非，如果做过客服，这方面能强得多。

很明显，我是技术出身的。更明显的是，我性格天生就是直爽，藏不住话，也不懂得隐藏情绪。不知道圆滑这个是否能慢慢学来，不过我还是想尝试一下！

我倒不觉得一定要使用“圆滑”这种技术人员很不擅长的手段。技术人员应该有技术的办法。
以前我的理解也是让管理层在面子上过得去，但私底下还是想怎么做就怎么做。但管理层不笨，时间长了他必然知道咱们在底下乱搞。所以后来我转变了一下策略，我在不断地做改进，而且我要把这种改进的成果show出来，让管理层看到（当然前提是咱们得让他们看得懂），只要管理层看到你一直在进步，很大程度上就可以让管理层的心放下来。

比较认可这个兄弟的观点；
这就是一个所谓的”安“的问题，对客户老板手下；其中给老板的安心，表现形式就是让老板看到改进和成果；

举个不太贴切的类比：做技术的人往往更注重底层或者业务层一样，老板注重的更多的是可见的形式化的，所以改变你的观点和层面，结合你的优势，对老板有交代，对手下有交代，从而形成一些层面的安

冰冻三尺非一日之寒。

想要用UNITTEST, 持续集成，JIRA BUG 跟踪，CHECKSTYLE, 先要确保你的小组成员是否都掌握了这些技能？

也许有局限性吧，我的绝大部分同事，几乎都没有使用UNIT TEST的。CHECKSTYLE也从来不用。持续集成更不用说了。JIRA倒是有用过。不过用的人素质不行。表达能力差得人，用了JIRA之后提的BUG,一样让人摸不到头脑。

所以管理真的是门学问，不是说说就能拉出去练的。

如果我是你，想达到（规范代码，使用UNIT TEST, 持续集成）这些目的，就一定要先保证小组成员都基本掌握这些技能。不会单元测试，你就举出几个ActionTest, ServiceTest。 不会checkstyle，你就先给他们一个eclipse/jalopy code convension,让他们有空就格式化下代码。他们闻不出代码的坏味道，你就带头做review。大家觉得持续集成没用，你就学习pragmatic programmer- automation 中的，自己买个绿灯泡，红灯泡，放饮水机前面，程序出错就亮火警灯吓吓他们。对于JIRA的使用做个视频，然后规定提交BUG的人要说明白出错时的环境，信息，报错情况，预期正确结果。改BUG的人注明BUG出错的原因，修改的思路和具体办法。


ps.
上面说的也是我自己一贯坚持的原则，只是我不喜欢命令别人，所以只好对自己下手，除了没有在饮水机前面放警示灯，其他的都做过。效果非常明显，非常好：）

如果你也跟我一样是个小兵，可以在自己身上先试试这些。只是在使用cruisecontrol时，log4j的 显示级别一定要在WARN以上，否则那LOG文件就太大了。。。

似乎我们做技术的都这样。

不过藏不住话没关系，你说的时候，一定要心平气和的说，让对方觉得你说的有道理。
不要太过情绪化，否则你有道理也变得没道理了。

看来，管理层还是很空闲的。当然不是说想怎么做就怎么做，要符合客观规律。
其实有另一个话题，管理层向你要一个最优方案，你提交的他们又不满意，要你再优化。你真的能再优化，管理层会觉得你开始时的方案有水份，“看来每次都要挤呀”;你没有新优化方案，管理层会觉得你故意不管理层过不去。其实你不得不稍加改动，把时间，质量，成本三个方向调整一下，说明要满足某个要求是可实现的，但要降低另一些要求，或提高另一些风险。
“圆滑”有书上写的，我的理解也有些偏差，“进步”，我不知怎么理解，也许以退为进吧。