组长F三是很消极。对用户需求从来不好好分析，也不和用户有效沟通，用户今天说把1改成2，今天就改成2;明天用户说没想好得把2再改成1，就再改回去。天天反复做一堆无用功。

组长F四是没担当，当我对用户改来改去提出质疑时，人家F说:让他们说，咱就改，合理不合理，反正最后咱们没责任。组长F五是邀功，事干个烂叽叽，每次跟自己领导和客户领导汇报，天天说自己技术多先进，自己多辛苦，虽也捎带我们，但让人一听觉得他是大功。说这么多不好，是感觉吧友肯定有人将来负责项目，可将反面教材，引以为戒。

6.责任与担当
再到后来，情况也有些不好，我们领导也看出F不想带这个项目，F还是想回原项目组，虽不是负责人但是核心项目，他舍不得。就顺水人情，让我负责了这个N项目。我也是头回带项目，虽然只带两个人干，但也是项目负责人了，我开始做了几面工作。

第一是，去向业务部门了解一下现系统使用情况。业务部门反应第一点就是慢，二就是反应系统业务太理想化，与实际有些脱节。
第二是，去我们运维部门了解一下运维情况，运维兄弟说，这个架构把二进制文件全部存到OracⅠe数据库，造成数据库容量迅速扩大，而且数据还不按业务年度拆分，备份有很大问题。

第三是，我认真审视团队的这两个程序员，都是合作公司外派的。一个是小A二十四五岁，水平不咋地，还挺拧，天天迷迷糊糊的。一个是老B，老油条，比我还大三岁，水平够，但是给对付着干，能省事就省事，极不负责任。

因为我做了几方面改变，一是改变原因与用户沟通方式，不再是用户今天1改2，明天再2改1的这么干了，首先自己努力学习人家业务，好与人家领导与业务人员有效沟通。你不可能让用户学软件开发与你沟通，而是你去学业务与人家沟通。

在沟通过程中，从系统设计、扩展、应用的角度去和用户谈，说原来业务设计中的问题，争取让用户认可，用户都不是傻子，觉得你的方案好他为啥不同意，所以说沟通很重要。

在沟通过程中，需要技巧方法，这些东西什么软件工程，项目管理理论都不好使。只能自己动脑子，例如:你觉得用户说需求不对，你不能上来说你这个不对不能这么干。而是要说你这个想法挺好，但我们从XX系统中有XX经验，你把把关是不是这么设计也不错呀。后来他一看，觉得自己说的不对，但台阶又有了，有可能说，你即然那么弄过，就按你的来吧。类似这种经验，什么书上能有呀。

说到与用户交流，几年前我们这有一趣事。有一次服务器故障，用户系统用不了(不是所有系统都做成集群达到高性能、高可用，成本多高呀)。用户电话打到项目负责人J那里，J并没和用户说:我们服务器坏了，正在抢修，估计两个小时恢复。而J这样和用户说:为了更好让你们应用，我们正在升级服务器，估计两小时后完成，用户最后还感谢J。同样的事，不同说法，用户感觉不大相同。

所以说软件开发虽是技术活动，但终究是社会活动。一昧研究技术(不是说技术不重要)，脱离社会肯定发展不好。情商商的肯定混得好，智商高情商低的有不少混不开。和《摔跤吧!爸爸》上阿米尔汗说的一样，一昧的健身成不了摔跤高手。得力量与技巧同时练才行，放软件开发也是，技术与沟通同时练。

7.解决问题
其次用户反应系统慢的问题，原系统架构为客户端(C#WinForm)+服务器(NET的WebService服务)+数据库(Oracle)三层技术架构。在我们眼里，吧友们讨论的什么Web和安卓哪个方向好，Java和NET或PHP哪个好没什么意义，能降低成本，按时保质完成，只要用户不特殊提技术要求，什么好用用什么，当然肯定结合团队实际技术情况。

经过分析测试，发现慢有几个方面，一是有些功能设计不考虑性能，例如:该系统存有大量项目文档，Word，Exce|，pdf多种格式，用户每次看文档都需要在网络下载，那怕是同一个没有修改过的。

二是所采用的WebService的SOAP协议效率差，主要是采用xml描述数据，远不如开放式二进制协议，例如Hessian协议。此外其系统结构存在问题，所有业务逻辑及计算采用Oracle存储过程封装，基本是数据库服务器又存储又计算。而中间件硬件配置挺好的服务器，只是转发请求和响应。就像两匹马拉两袋子货，其中一匹马驮两袋子，另一匹马啥也不驮道理一样。

三是发现NET服务端随压力增大不是十分稳定。倒是满足这个业务也可，因为这个系统全省用户也就一二千人，没那么大并发量。

知道问题所在后，针对业务问题，重新设计系统界面，全力适应用户并兼顾系统扩展需要。针对慢的问题，仍采用三层架构，客户端采用C#的WinForm，客户端缓存用户文档数据，不用每次访问网络，即减少少资源消耗，又让用户打开文档速度提升，其实工作做了许多。