1、小型软件企业的项目管理方法探讨为了符合小型软件公司的管理特点，本文将小型软件公司的项目管理分为三个部分：编码前的管理、编码的管理、编码后的管理。 型软件公司项目管理方法 一、编码前的管理 1、管理方式的改变 软件开发不需要使用大量的物质资源，而主要是人力资源，人员工资费用占软件开发成本的大头。要减低人员工资费用，我们不能削减员工工资，更不能削减必要的人员，提高软件开发人员的效率才是根本。结合目前的软件公司的管理现状，本公司实行以下的管理制度： 对于开发周期在两三个月以内的小项目：周末也要上班，只在月末才放两天假。等整个项目完成后，再把以前没有放的假期补放。例如，一个项目从三月一号开始开发，五月
2、三十一号完成。在这期间，三月底放假两天，四月底放假两天。因为从三月份到五月份的公众假期有：27天，但前面有放了四天假，理论上可以给软件开发人员放 23 天地有薪假期。但实际操作时给放了半个月的假。 对于开发周期比较长的项目，跟小项目类似，每月放两天的假期，但长假不是在项目完成后放，而是每隔半年放一次，时间为一个月。 这样的管理可以在一定程度上提高开发人员的效率，又可以避免长时间因为没放假，使开发人员赶到枯燥，情绪低落，动力不够，压力过大的情况。当然在实际操作时，开发人员因为自身的原因需要偶尔放的假，都会尽量满足。 2、项目风险的评估 前面说道，小型软件公司的项目经理往往是老板本人，有很强的风险
3、意识。但在这里还是要着重说说软件工程的风险管理，因为项目经理认识的风险大多局限在商业风险（销售问题等）中，对风险的理解很片面。 软风险是指软件开发过程中及软件产品本身可能造成的伤害或损失。风险关注未来的事情，这意味着，风险涉及选择及选择本身包含的不确定性，在软件开发过程及软件产品都要面临各种决策是选择。风险是介于确定性和不确定性之间的状态，是处于无知和完整知识之间的状态。另一方面，风险将涉及思想、观念、行为、地点等因素的改变。根据风险内容，我们可以将风险分为项目风险（成本提高，时间延长等） 、技术风险（技术不成熟等） 、商业风险（销售问题等） 、战略风险（公司的经营战略发生了变化） 、管理风险
4、（公司管理人员是否成熟等） 、预算风险（预算是否准确等）等。 另外，我们还可以将风险分为知己风险（如员工离职等） 、可预报风险（从以往经验得出可能有风险的）和不可预知风险。对于大多数软件项目而言，风险因素性能、成本、支持、进度，也代表了风险参考水平值。即，对于性能下降、成本超支、支持困难、或进度延迟，都有一个水平值得要求，超过它就会导致项目被迫停止。在软件风险分析中，风险参考水平值存在一个点，称为参考点或临界点，在这个点上，决定继续进行该项目或终止他（问题太多）都是可以接受的。 3、项目进度承包效益的估计 其实，这也是项目风险有着紧密联系，是项目风险发生的一大因素之一。为此，需要做到以下几步：
5、 在制定项目计划时，必须进行项目的需求分析，明确项目的需求。在项目需求分析阶段，双方必须全面地尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面要求、与其他软件的接口要求，以及对项目进行评估的各种评价标准。并且，在学期分析结束以后，双方还要建立可以直接联系的渠道，以尽早地对需求变动问题进行沟通。并在项目需求分析完成后，和客户明确项目的那些部分可以在日后的进度中能修改，修改的限度，那些不能修改。例如，应用背景、功能要求方面应该是在需求分析阶段确定，日后不能做修改。而性能、界面及接口等可以在日后作为限度的修改。 制定项目计划首先对项目进行估算，粗算出项目的总体进度。然后进行精化：确定概要
6、设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段等阶段的具体要求、完成时间、投入人力物力，并确定几个关键阶段。这些关键阶段的要求进度必须在制定日期之前完成。最后做出项目进度表，列出在每个阶段的难点要点，要注意的问题。并将需要分析阶段的内容和项目计划、进度表整理成文档，分发相关人员手上。 充分考虑影响项目计划的因素，并做出相应的措施。可以把影响项目的计划划分为 A 灾难的、B 严重的、C 轻微的、D 可忽略的，对相应的等级作出相应的应变措施。根据计划估算出成本。计划一旦确定，就可以通过人力资源成本、日常办公费用、软硬件的损耗等算出本项目的成本。 4、项目的立项 只要经过管理方式的考虑，
7、风险的评估，项目进度成本效益的衡量，再综合其他方面的因素，做出决定，是否立项。 二、编码中的管理 与以前相比，由于软件的规模和复杂度的增加，以及半自动化软件代码开发平台的出现，现代软件项目管理的中心发生了转移不是着重编码阶段，而是着重系统总体/详细设计阶段。一般来说，在现代软件项目管理中各种资源的合理分配比例是：项目论证、风险评估阶段 3%，项目需求分析阶段 8%，系统总体/详细设计阶段 45%，编写阶段 10%，系统测试阶段 34%。 在编码阶段，只要不是原则性的错误，尽量不要推倒前面所做的一切，重新做，一切都作废，太浪费了。还有，要是数据库字段已存在，处罚万不得已，千万不要修改数据库字段，
8、能可添加字段。因为已经存在的字段，很有可能已被软件开发小组的其他成员在使用，不要因为你的修改而令其他人也要跟你做相应的修改。最后，软件界面的修改要慎重，界面的修改很容易使你忽略修改相应的内容，造成软件大问题没有，小问题一大堆。要想做到不修改，不重做，很不容易，要考虑的因素很多。 首先从软件的角度来说吧：对于专用软件，很多时候，一般用户对于软件要完成哪些功能已经有了一个比较清楚的轮廓，而且往往在开发合同中已经大致地规定了。但是，开发合同上规定的只是一个大概的框架，用户心目中的产品究竟是什么样子，有时不要说开发人员不知道，连用户本人也不知道。所以很多时候，都是到了开发工作的后期才发现开发人员的理解
9、和用户的要求有一些误解，那么必然造成时间上的浪费。对于通用软件，很多时候是到了开发工作的后期才发现某方面的功能不足，或要添加新功能等等。 在小型软件公司中，由于开发人员少，这样意味着不同人员的程序之间交互、接口相对少一些。开发周期短意味着往往是同样地几个人从头到尾负责一个项目。这两者都让人同意犯错误。往往是几个人碰一下头，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，没有一份较正式的文档。当有的人会对讨论出得接口、结构理解有偏差（应该承认人时会犯错误的） ，一个误解可能造成以后的返工。 其次从管理的角度来说吧：有效的团队组织，提高团队组织的工作绩效，提高组员的团队精神。这非常有利团
10、队有效，有序的工作。有效的团队建设，这是管理的重要内容；小组成员的沟通，协调，小组员的沟通，可以很好的加强团队组织的凝聚力，能更好的让项目良性的进行，而培养这种气氛，形成有效的沟通，这也是项目管理的基本内容。 最后从测试的角度来说吧。传统观点认为，测试是在编码后的工作。其实，测试盒编码是两个密不可分的阶段，交叉进行的，测试在编码后期进行的较多，主要有两个方面： 首先，不经过单元测试而直接进度系统测试，造成这一现象的原因是每个模块相对比较简单，但是为了测试一个模块需要建立一些测试环境。例如，为了测试一个函数是否正确，应该用一些测试数据去条用该函数，需要编写一些测试数据。但很多开发人员嫌麻烦，觉得
11、反正其他模块也很快出来了，直接用真正的数据来运行几次就行了。殊不知，一旦直接进度系统测试，发现运行结果不正确后需要一步步查找。不但耗费了大量的查找时间，而且后面的模块已完成了，修改签名的模块又会影响后面的模块，使得修改的难度增加，修改后导致新的错误产生的概率增大，另外，每个人的潜意识都不想否定自己，这种情况下很难真正去修改。还有由于这种测试不完全，真正运行系统，当调用某模块时，可能大部分时候都是正常数据，极少出现边界情况，可能某些边界情况容易被忽视，很久之后才被发现。但是如果对每个模块进行单元测试时都进行一下边界测试，就会容易消除一些隐患。真可谓欲速则不达！ 其次，如果在项目人员配置中设置了专
12、门的测试人员，编码人员会认为软件所有的内部测试工作全部应该由测试人员完成。众所周知：软件程序测试可以分为“白盒法”和“黑盒法”两种方式。由于使用“白盒法”对测试人员各方面素质的种种要求，在进行程序测试时测试人员总是最优先使用“黑盒法” 。他们的工作方式往往是先对程序进行“黑盒法”测试，如果测试没有通过，不得已这才考虑对程序代码进行“白盒法”测试。显然，这种对“白盒法”有意无意的“逃避” ，对软件的可靠性和稳定性构成了威胁，造成在编码后期，甚至是在试运行或运行阶段需要进行大量的修改。如何解决这个问题？一方面需要提高对测试人员的要求，另一方面也需要程序员完成部分的“白盒法”测试（实际上，程序员往往
13、也是进行“白盒法”测试的最佳人选） 。 在代码阶段，除了要想做到不修改，不重做外，还需要对软件的质量进度等进行控制，必须做到以下几点：定期召开项目工作会议，向项目开发人员及时了解项目紧张情况及存在的主要问题。一旦发现问题，管理人员应迅速查明原因，尽快采取措施，争取在尽可能小的范围内解决问题；在软件开发过程中，请专家和用户按照里程碑评审阶段性的成果，判定开发进度是否与软件项目定义的里程碑保持一致，开始时间是否与计划时间一致。 三、编码后的管理 编码完成后，就是软件实行试运行、运行阶段，并生成相应的版本，并进行相应的备份。这个工作很重要，特别是版本生成备份，很容易出错。笔者在曾经犯过这样的错：给了老版本给用户；把为甲做的版本发给用户乙；备份时把以前有用的版本覆盖了等等，不一而足。要避免犯这些错误，就必须要在每次生成不同的版本或者备份时，都要建立相应的文章。在文档中，尽可能详实地记录本版本或备份的时间、目的、特别是何其他版本的不同之处。写的越详实，出错的概率越小！
