国内中小软件企业项目管理讨论

国内中小软件企业现状
虽然没有调查，但在国内，开发人员小于30人的软件企业应该不在少数（在我面试过的单位中，有半数左右），这样的企业创建时间不太长， 可能在五年之内，有较固定的客户，企业的生存较稳定。
由于企业成立之初，多为解决企业生存问题而开发，相应的规范和质量管理并没有太多的关注，很可能是三四个开发人员简单的组合，分模块后就开始工作了，在紧张的开发后，就把认为能完成客户需求的应用交付了，但交付后，客户需求却才开始，项目开发越来越难以进行。之后，人员流动增加，数据维护比程序维护还要多，项目变得越来越不能满足客户的需求变化。

下面是本人所在公司的一个特例
这时，BOSS发现了企业要发展，需要规范管理和企业积累，需要提高交付质量，需要开拓新的市场。所以，改变就开始了。
原来的“扃平”管理方式要改，成立了部门，成立了项目组，挑选了干将做项目经理；
改变“大锅饭”制度，考评制度也有了；
要推行CMM*，要文档，要配置管理，要学PMP，要……
引进人才，进入重要部门，任要职；
与其它公司合作，补充业务和技术上的不足，增加对外实力；

企业总是要发展，要向前走，但是，这样做的结果会是怎样呢？如何做好呢？

问题的提出
公司要改变，无可厚非，BOSS要改变的信心也不容置疑，但是（总在有个但是），路要怎么走，怎么才能走好？
1  公司内的人员，工作时间都不超过五年，平均2年左右，对软件工程和项目管理没有什么概念，但是对现状也极为不满，有强烈的改变意愿
2  OO思想和设计能力有限，开发过程基本就是一个套路——开源框架的简单堆砌，或许这样说太夸张，但一点也不为过，对框架没有深入学习，只知道如何配置，如何使用插件开发，更变一点，就完全不知所措
3  公司选出来的“项目经理”，由于过去对如何实现业务关注太多，对OO和设计不关注（应该是没有时间和精力），思想上跟不上节奏，管理也只剩下“管”和“理”了，管理形同虚设，CMM*也只是走过场
4  外部人员与公司人员思维上无法接轨，起不到实际作用

困惑
面对种种压力和困惑，虽然接触过较规范的大型软件开发过程，想在这种环境下实施，但感觉到的压力比想象的要大得多， 如果按照自己的设想，要改变的太多，一已之力，自己要累坏了也不一定能做好，而且，我也不是全能。
-----------------------
做事，总想做的更完美，一个程序员的困惑。

开源框架的简单堆砌，呵呵，是的，即使工作了5年的人，能深入了解一个框架的又有多少？
多数是使用过某某框架而已，然后就称精通某某。国内就这样。

楼主说的问题在国内大多数公司都存在，主要是公司领导对技术不够重视，认为技术人员就是干活的，其他什么都不懂，在这种公司的技术人员是没什么地位的
此类公司的领导应该说是跟不上潮流的 思想还停留在资本经济上 不懂得什么叫知识经济，这样的公司注定要完蛋 可悲的是这样的公司一抓一大把

快速发展的企业大多都会面临选干部的问题
根据著名的彼得原理：在各种组织中,雇员总是趋向于晋升到其不称职的地位。
所以提拔干部首要的是要先让这些准干部们具备坐这个位置的能力。
让人坐在他不能胜任的位置上既损害了团体利益对他本人也没有太多益处。

所以，我的看法是提拔一个干部之前要先让他知道需要掌握什么技能才能做好新的工作，并协助他们掌握这些能力。

没有看出来LZ是做什么的？部门经理？项目经理？
一般的程序员怎么会有如此多的困惑呢？

在这样的公司，什么职位似乎并不重要了，职位越高，干活越多，一个人几个角色。
我只想把项目做好。


在小公司，人手总是最大的问题，项目工期短，事情一点也不少，一个人当几个人用，但是由于人员的都比较初级，边培训边做事，本身还有很多的管理和开发工作，所以难以有效管理，我想这也是管理中的重要部分之一。所以我很同意ball_cao的观点，不只在干部任选上。

既然上面的问题是个普通问题，项目管理又是如何做的呢？
这个项目刚刚开始，我采取了以下的办法来控制风险：

1  做好配置管理工作，这是项目的起点，对项目的后续展开有很大作用。
2  框架选型和使用，由一两个人（有一定的项目经验）来组建，对重点技术专人负责，项目组成员共享（知情或了解）
3  需求管理，由项目经理与业务专职（BOSS或外部业务人员）共同完成
4  根据项目需要，灵活把握设计尺度和输出文档（不完全根据CMM要求）
5  对需求细化后，形成工作任务，由项目经理和一个技术较强的人员合作完成概要设计和设计文档，供开发人员使用
6  开发人员完成编码和单元测试，根据需要完成输出详细设计文档
7  周会制度
8  定期进行集成测试和代码走读
9  客户沟通和公司上层协调，相关资源的准备

基本做法就是，在前期做好项目基础工作，监控开发、测试重点

不知道，这样做能不能将项目管理好，项目能正常运作的可能性有多大？
由于前期准备工作用的时间比较多和人员到位情况不好，项目有些滞后，准备工作和技术难点基本完成，开发进入正常步骤，如果按上面的方式管理，是否能够完成，希望能够得到指点。
先谢过各位。

   楼主的话题说中了中国的软件行业里面很多公司的神经，说的很好，确实很多的公司没有安照一定的流程操作，后患待来很多的问题！值的我们去思考！

确实如此啊。其实中国的软件企业经历的时间还不长，就和我们个人的生活一样。在一定时期内，解决了自己的温饱问题。就开始想向小康迈进，可发现小康远不像自己想象的那么简单：高物价、高房价等现实问题让我们招架不住。当你迈进小康之后，想提高自己的生活档次，进出高档寓所，那又面临礼仪、上层社会的潜规则等。
总之，我感觉不管是企业也好，个人也好，向着更标准化的流程迈进就是一件好事。看自己怎么去把握，自己也可以从中学到知识与经验。

ps：我是80后 ：）

是被环境改变，还是做点什么改变环境，就看你个人的心态了！

这个项目刚刚开始，我采取了以下的办法来控制风险：

1 做好配置管理工作，这是项目的起点，对项目的后续展开有很大作用。
2 框架选型和使用，由一两个人（有一定的项目经验）来组建，对重点技术专人负责，项目组成员共享（知情或了解）
3 需求管理，由项目经理与业务专职（BOSS或外部业务人员）共同完成
4 根据项目需要，灵活把握设计尺度和输出文档（不完全根据CMM要求）
5 对需求细化后，形成工作任务，由项目经理和一个技术较强的人员合作完成概要设计和设计文档，供开发人员使用
6 开发人员完成编码和单元测试，根据需要完成输出详细设计文档
7 周会制度
8 定期进行集成测试和代码走读
9 客户沟通和公司上层协调，相关资源的准备

对于小公司来说，对于变更的及时响应也是非常重要的。
根据楼主的这几点看法来说。这些动作，我们公司都有进行。但是效果都不很很理想。
1,高层前期和后期的干涉过于频繁
2,周例会的氛围过于单一。如何提高这种会议的效果是需要考虑的一个问题。
3,持续集成和代码走读。到目前为止都进行不是很彻底。
  我个人其实比较倾向于小范围的结对检查，然后核心重要部件进行走读或评审
9,多部门的协调，由于测试部不属于开发部管理，所以往往出现测试计划和产品的发布计划有不协调的状况出现。
  另外研发部对于工程实施的反馈也了解较少，应着手进行整理以调整产品发展方向。。。