现在各行各业都兴采用什么，矩阵管理的方式，号称可以提高效率，但是在软件行业一定适用吗？
据说，微软采取的就是这种矩阵管理的方式，每一个项目由技术人员，项目经理，测试人员三个
部门的人员组成。其中，项目经理负责项目的协调。看起来，是人尽其用，每个人只需完成它分内的工作
即可，但是在一个项目中，涉及到大量的沟通（正式的和非正式的，内部的和外部的），和协调。如果项目组成员仅仅完成自己分内的工作，而把剩下的工作全部交给项目经理去完成，那么工作效率之低就可想而知了。这理涉及到一个问题，如何提高项目组成员的工作主动性，主动去完成自己分外的，但是自己最合适的工作呢？当然可以提高员工的工资，但是人的欲望是没有止境的，长到多少合适呢，在说公司能够承受多少呢？
可见，涨工资不是解决问题的根本方法。因此我们需要想一些别的办法。
在矩阵管理的模式下，由于每个人不隶属于任何的项目，只隶属于自己的部门。因此，在项目经理
与组员进行沟通时，也仿佛在与其他部门进行交互一样，存在这推诿，敷衍等等许多问题。如何解决这
个问题呢，那就是让每个项目组成员都要与这个项目荣辱与共。这恰恰就是矩阵管理存在的最大问题。
在矩阵管理中，当项目组成员完成一步份工作后，可能就会撤出这个项目，因此这个组员也不会全
身心的投入项目的开发，因为它还要想着下一个项目。项目经理常常挂在嘴边的一句话，我的项目
怎么怎么样了（先不管这样说会让其它项目组成员心里怎么想），但是很少有项目组成员会说我的项目。。。。，这是为什么呢。因为不管嘴里怎么说，项目组成员在内心深处就没有把他当作自己的项目
他只需要完成自己的工作就可以了，没有必要作一些额外的工作，不在其位，不谋其政吗？这里所提到的
是矩阵管理存在的一些共性的问题，对软软件小组进行矩阵管理存在的问题更大了。众所周知，软件开发
是一种创造性的工作，其工作主动性所产生的作用更远远大于其它行业。在《人件》认为软件工程的管理
其实就是对人的管理，一切管理都要以人为核心。但是某些领导，往往忽视了这一点，把软件人员当作一种可以重复利用的资源，结果吃亏的将会是项目本身。
也许大家会说了，你是不当家不知柴米贵，不作领导你不知领导的难处，在这里发发牢骚谁都会，如果你是领导，你会怎么办呢？
当然了，作为非领导的我，只是从我的角度讲了一下我对这个问题的看法，另外我也不只是在这里
夸夸其谈，我呢，在下面也阐述一下，如果是我，我会如何管理，希望某个领导看到后也也考虑考虑。
1 软件小组依然存在，但是其作用已经发生的变化。首先软件小组对已经进入项目的小组成员不能
进行工作的安排。只能对在项目之外的软件人员进行工作安排。其次，软件小组需要担付起对新入职的
软件人员进行培训的工作，不能把培训大量的工作放到真实项目中，这样必然会降低项目的质量。再次
软件小组，对项目中一些通用的问题集中解决，对项目中的疑难问题提供技术支持。另外软件小组还需要
对小组成员代码的质量进行走查，提高软件小组的成员的技能。当然作为软件小组成员的行政单位，软件小组成员的考核还是要有软件小组主导的。
2 软件人员，尽能的参与项目真个生命周期，项目紧张人紧张，项目不紧张人员可以稍微放松，或及时进行充电。忽略了软件人员的对不断学习的需求，是当前软件管理的一大弊病。（可能有些上岗上线了，但这对调动软件人员的积极性和保持相对稳定的团队有这意想不到的作用）
3 项目经理，需要对软件开发的特点，和软件人员的管理有所了解，建议读一读《人件》这本书。当然
提高项目经理本身的软件素养才能根本解决问题，建议软件项目的项目经理一定要具备较强的开发能力和较为丰富的开发经验，公司不要心疼一点点工资，它可以给公司带来的效益要远远高于此。
4 项目经理不要说，“我的项目”，应该改成“我们的项目”，让项目组的每个成员由一种归属感。
作为一个项目组成员，我们需要的是一种经历风雨见彩虹的成功感，而不是一种机械的忙碌的工作。
5 最后，也是每一个软件人员都十分关心的问题，什么时候给我们换一个快点的机器呀。一个好一点的机器
比可能比更高一点的工资更具备吸引力，对公司来讲也是更划算的。（效率和人员流动上，呵呵）