小型软件企业的项目管理

1、小型软件企业的项目管理20年前，项目管理的应用仅限于美国国防部的承包商和建筑公司。如今，项目管理的 基本思想已被广范应用于国防，建筑，制药，化工，电信，软件开发，银行，广告，会计， 司法，政府和联合国等领域和机构。这些机构已经意识到了项目管理和生产率之间的紧密关 系，及其在当今商业环境中的至关重要性。一项调查表明，大约70%的软件开发项目超出了估算的时间，大型项目平均超出计划交 付时间20%至50%，90%以上的软件项目开发费用超出预算，并且项目越大，超出项目计划的 程度越高。因此，软件开发迫切需要进行项目管理。但是，软件开发不同于其他产品的制造， 软件的整个过程都是设计过程（没有制造过程）；

2、另外，软件开发不需要使用大量的物质资 源，而主要是人力资源；并且，软件开发的产品只是程序代码和技术文件，并没有其他的物 质结果。基于上述特点，软件项目管理与其他项目管理相比，有很大的独特性。第一章小型软件公司的特点俗话说，聚沙成塔，没有在金字塔地层下大量的小型的甚至是作坊型的小软件公司，就 不可能有大型的特大型的软件公司。现在，无论是大学的教程，还是书本，讲的软件工程管 理都是针对大中型软件公司的，连网络上也很少有针对小型软件公司的项目管理文章。小型 的软件公司只有实行软件项目管理，才能生存和发展，才能向大中型软件公司迈进，才能使 软件产业更加繁荣！一个企业的管理，大公司有大公司的方式，小公司

3、也有小公司的方式，如果把别人的经 验生搬硬套到自己身上，可能会适得其反。同样，管理一个软件项目也一样，大项目和小项 目的方式不完全一样。但从另一个角度来看，项目的大与小并没有本质的区别，很多方法是 共通的。本文的目的是从作者的经验来谈谈小型软件公司的项目管理。小型软件公司相对与大中型软件公司而言，有以下的特点：1、项目负责人一般也是公司的老板，对软件工程有一定的了解，但不全面，相对而言， 对市场的了解较为透彻或对技术很精通；2、项目功能相对较少，涉及面相对较狭窄；3、开发人员较少，人员结构简单；4、开发周期较短，少则两三个月，多则一到两年。总的而言，大中型软件公司，软件开发主要分为六个阶段：需

4、求分析阶段、概要设计阶 段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段。软件公司将软件配置管理、软 件质量管理、软件风险管理及开发人员管理四方面内容导入软件开发的整个阶段。小型软件 公司的软件开发同样分为六个阶段，但比较模糊，侧重点也不一样；至于软件配置管理、软 件质量管理、软件风险管理及开发人员管理四方面内容则比较少。大中型软件公司开发软件就如八股文一样:总体规划、项目立项、需求分析、系统分析、 系统设计、编码实现、项目测试、文档制作（八股文：破题、承题、起讲、入手、起股、中 股、后股、束股），一切都按部就班。小型软件公司开发软件就是写现代文：不拘泥于形式， 但同样符合规则！为了符合小

5、型软件公司的管理特点，本文将小型软件公司的项目管理分为三个部分：编码前的管理、编码的管理、编码后的管理。第二章编码前的管理无论是项目，管理都必须在以人为本的前提下进行。以人为本，指的不只是软件开发人 员这一部分。这里的人主要指的是一些与项目有利害关系的一些人，即项目干系人 (stakeholders)，一般包括客户或者用户、项目团队、项公司的管理层等一些主要的利害关 系者。一个项目能否成功，很大程度上取决于能不能分清楚这些项目利害关系者各自对项 目的影响，不能利用好这些人力资源，沟通协调好他们之间的关系。一、管理方式的改变在土木工程的项目管理中，成本主要分为三部分：人员工资等费用、管理费用、材

6、料费 用。其中人员工资等费用、管理费用随着经济的发展所占的比重越来越大。土木工程的项目 管理为了降低人员工资费用、管理费用，采取了这样一条措施：尽量缩短工期，节假日以项 目为准，平时周末不放假，项目完成在不补放。很明显，在软件开发不需要使用大量的物质资源，而主要是人力资源，人员工资费用占 软件开发成本的大头。要减低人员工资费用，我们不能削减员工工资，更不能削减必要的人 员，提高软件开发人员的效率才是根本。进行软件开发有这样的一个特点：你放下的时间越 长，你要重新理清前面的关系需要的时间越长，构思连续性也不好。很多小问题，也是因为 中间间隔的时间太长，开发人员忽略导致的。现在，一般的软件公司，特

7、别是大中型软件公 司，都实行这样的制度：星期一到五，朝九晚五上班；星期六、星期天放假。这样，这个软 件开发都给打断了，连续性很差，效率很低。经过对土木工程的项目管理的对比吸收，以及结合目前的软件公司的管理现状，本公司 实行以下的管理制度：对于开发周期在两三个月以内的小项目：周末也要上班，只在月末才放两天假。等整个 项目完成后，再把以前没有放的假期补放。例如，一个项目从三月一号开始开发，五月三十 一号完成。在这期间，三月底放假两天，四月底放假两天。因为从三月份到五月份的公众假 期有：27天，但前面有放了四天假，理论上可以给软件开发人员放23天的有薪假期。但实 际操作时给放了半个月的假。对于开发周

8、期比较长的项目，跟小项目类似，每月放两天的假期，但长假不是在项目完 成后放，而是每隔半年放一次，时间为一个月。这样的管理可以在一定程度上提高开发人员的效率，又可以避免长时间因为没放假，使 开发人员感到枯燥，情绪低落，动力不够，压力过大的情况。当然在实际操作时，开发人员 因为自身的原因需要偶尔放的假，都会尽量满足。本来，为了更好的提高效率，我公司还把白天的工作制度作了一些调整。一般进行软件 开发，特别时编写代码的人员都有这样的体会：晚上的效率特别高。这是有原因的，晚上所 受外界的干扰最少，人的精神特别容易集中，思路特别清晰。为此，我公司实行了以下制度： 开发人员统一居住，下午两点到六点工作，晚上

9、八点到十二点工作。实行这样的制度，开发 人员的效率得到很大的提高。但是，由于种种的原因，此制度不能实施下去。、项目风险的估计前面说到，小型软件公司的项目经理往往是老板本人，有很强的风险意识。但在这里还 是要着重说说软件工程的风险管理，因为项目经理认识的风险大多局限在商业风险(销售问 题等)中，对风险的理解很片面。软件风险是指软件开发过程中及软件产品本身可能造成的伤害或损失。风险关注未来的 事情，这意味着，风险涉及选择及选择本身包含的不确定性，在软件开发过程及软件产品都 要面临各种决策的选择。风险是介于确定性和不确定性之间的状态，是处于无知和完整知识 之间的状态。另一方面，风险将涉及思想、观念、

10、行为、地点等因素的改变。根据风险内容， 我们可以将风险分为项目风险（成本提高，时间延长等）、技术风险（技术不成熟等）、商 业风险（销售问题等）、战略风险（公司的经营战略发生了变化）、管理风险（公司管理人 员是否成熟等）、预算风险（预算是否准确等）等。另外，我们还可以将风险分为已知风险（如员工离职等）、可预报风险（从以往经验得 出可能有风险的）和不可预知风险。例如，在一些订单开发的软件中，存在着很大的商业风险。林子大了，什么鸟都有。客 户多了，需要就不同，客户相关的风险出现的概率就不一样。一些人只知道他们需要什么； 而另一些人知道他们不需要什么。一些客户希望进行详细的讨论，而另客户则满足于模糊的

11、 承诺。客户有不同的个性。一些人喜欢享受客户的身份，而另一些人则根本不喜欢作为客户。 一些人会高兴地接受几乎任何交付的产品，并能充分利用一个不好的产品；而另一些人则会 对质量差的产品猛烈抨击。一些人会对质量好的产品表示赞赏；而另一些人则不管怎样都抱 怨不休。客户和供应商之间也有各种不同的通信方式。一些人非常熟悉产品及生产厂商；而 另一些人则可能素未谋面，仅仅通过信件来往和电话与生产厂商沟通。一个“不好的”客户 可能会对一个软件项目组能否在预算内完成项目产生很大的影响。对于项目管理者而言，不 好的客户是对项目计划的巨大威胁和实际的风险。对于大多数软件项目而言，风险因素性能、成本、支持、进度，也代

12、表了风险参考 水平值。即，对于性能下降、成本超支、支持困难、或进度延迟，都有一个水平值的要求， 超过它就会导致项目被迫停止。如果风险的组合所产生的问题引起一个或多个参考水平值被 超过，则工作将会停止。在软件风险分析中，风险参考水平值存在一个点，称为参考点或临 界点，在这个点上，决定继续进行该项目或终止它（问题太多）都是可以接受的。下图以图 形方式表示了这种情况。如果风险的组合产生问题导致成本超支及进度延迟，则会有一个水 平值,即图中的曲线，当超过它时会引起项目终止。成西铝党三、项目进度成本效益的估计其实，这也是项目风险有着紧密联系，是项目风险发生的一大因素之一。为此，需要做 到以下几步：1、在

13、制定项目计划时，必须进行项目的需求分析，明确项目的需求。在的需求分析阶段，往往存在着这样的误区：在项目的需求分析阶段，开发方与客户方 在各种的问题的基本轮廓上达成一致即可，具体细节可以在以后填充。因为无论开始时有多 么细致，以后对需求的修改几乎是必然的。当然这样做是有原因的：在具体实际中由于种种 原因客户方很难在需求分析阶段全面而准确地描述所有问题。随着开发进度的推进，往往会 有一些需求的改变。但是这样做，由于需求阶段对问题的描述不够细致，导致后来预算超出 或者时间进度达不到要求。正确的做法是：在项目需求分析阶段，双方必须全面地尽可能细致地讨论项目的应用背 景、功能要求、性能要求、操作界面要求

14、、与其他软件的接口要求，以及对项目进行评估的 各种评价标准。并且，在需求分析结束以后，双方还要建立可以直接联系的渠道，以尽早地 对需求变动问题进行沟通。并在项目需求分析完成后，和客户明确项目的哪些部分可以在日 后的进度中能修改，修改的限度，哪些不能修改。例如，应用背景、功能要求方面应该是在 需求分析阶段确定，日后不能做修改。而性能、界面及接口等可以在日后作有限度的修改。2、制定项目计划：有人这样说计划的，“计划，计划，纸上画画，墙上挂挂，计划不如变化！ ”。计划很 容易成为空话，特别是在软件工程中，影响计划的因素太多，计划就形同虚设了！但是，软 件进行项目管理的目的就是综合各种因素，制定合理的

15、计划，并通过计划的实施，使其规范 化，从而提高项目的效益，提高人员效率，降低项目的成本。制定项目计划首先对项目进行估算，粗算出项目的总体进度。然后进行精化：确定概要 设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段等阶段的具体要求、完成 时间、投入人力物力，并确定几个关键阶段。这些关键阶段的要求进度必须在指定日期之前 完成。最后做出项目进度表，列出在每个阶段的难点要点，要注意的问题。，并将需要分析 阶段的内容和项目计划、进度表整理成文档，分发到相关人员手上。3、充分考虑影响项目计划的因素，并做出相应的措施。影响因素可以分为主观因素和客观因素。客观因素有客户相关风险，外部环境的影响，

16、停电，机器损坏，不能上网等原因。客观因素在一定程度上可以转变为主观因素。主观因素 有：人的因素、技术因素，资源因素。人的因素，本项目是否有足够的人手，投入本项目的 每一个成员有没有要兼顾其他事情、项目，人员的流动、休假甚至是离职，这些对本项目的 计划有多大的影响，并对此作处相应的不久措施。技术因素，本项目是否涉及到技术问题， 所占比例是多少，以前是否有个类似的问题，新技术对本项目人员而言，新到什么程度，解 决需要的技术问题。要注意，盲目追求新技术，也会影响项目的进度，甚至拖垮整个项目， 成为技术先烈。还有一个技术问题是，本项目的人员，对要实施的软件的行业背景的熟悉程 度。根据这些因素决定是否对

17、本项目的人员进行培训！资源因素，项目经费是否充足，软 件配置，硬件配置是否及时充足。总的来说，可以把影响项目的计划划分为A一灾难的B- 严重的C-轻微的D-可忽略的，对相应的等级作处相应的应变措施。4、根据计划估算出成本。计划一旦确定，就可以通过人力资源成本、日常办公费用、 软硬件的损耗等算出本项目的成本。四、项目的立项：只要经过管理方式的考虑，风险的评估，项目进度成本效益的衡量，再综合其他方方面 面的因素，做出决定，是否立项。第三章编码的管理在这里首先要声明一点的是，虽然在这里并没有着重强调系统设计，但系统设计是软件 工程管理的很重要的一部分。这里，项目确定计划就包含了系统设计。在以前，甚至

18、是在现在，也有相当大的一部分人是这样认为的：软件程序主要由代码组 成，因此编码阶段是整个软件项目的最重要的阶段，应该给与大量的时间，并且集中主要的 资源。其实，与以前相比，由于软件的规模和复杂度的增加，以及半自动化软件代码开发平台 的出现，现代软件项目管理的中心发生了转移一不是着重编码阶段，而是着重系统总体/详 细设计阶段。一般说来，在现代软件项目管理中各种资源的合理分配比例是：项目论证、风 险评估阶段3%，项目需求分析阶段8%，系统总体/详细设计阶段45%，编码阶段10%，系统 测试阶段34%。但是，如果软件项目没有实施好的话，频繁地对软件进行修改、甚至重做，编码阶段就 会耗费大量地时间，在

19、整个软件工程所占地时间比例也大大增加。很多软件工程，不能按计 划完成就是因为编码阶段的问题太多了。编码阶段，要成功，就必须牢记一条：能做到少修改，不重做，力争一次成功！在编码阶段，只要不是原则性的错误，尽量不要推倒前面所做的一切，重新做，毕竟以 前做的时候也是考虑了方方面面的因素的，现在出现的问题只是在某方面考虑不周而已，一 切都作废，太浪费了。还有，要是数据库字段已存在，除非万不得已，千万不要修改数据库 字段，能可添加字段。因为已经存在的字段，很有可能已被软件开发小组的其他成员在使用， 不要因为你的修改而令其他人也要跟你做相应的修改。最后，软件界面的修改要慎重，界面 的修改很容易使你忽略修改

20、相应的内容，造成软件大问题没有，小问题一大堆。要想做到不修改，不重做，很不容易，要考虑的因素很多。首先从软件的角度来说吧：对于专用软件，很多时候，一般用户对于软件要完成哪些功能已经有了一个比较清楚的 轮廓，而且往往在开发合同中已经大致地规定了。但是，开发合同上规定的只是一个大概的 框架，用户心目中的产品究竟是什么样子，有时不要说开发人员不知道，连用户本人也不知 道。所以很多时候，都是到了开发工作的后期才发现开发人员的理解和用户的要求有一些误 解，那么必然造成时间上的浪费。对于通用软件，很多时候是到了开发工作的后期才发现某方面的功能不足，或要添加新 功能等等。在小型软件公司中，由于开发人员少，这

21、样意味着不同人员的程序之间交互、接口相对 少一些。开发周期短意味着往往是同样的几个人从头到尾负责一个项目。这两者都让人容易 犯些错误。往往是几个人碰一下头，讨论一下最基本的数据结构、函数接口便分头去做自己 的工作了，没有一份较正式的文档。当有的人会对讨论出的接口、结构理解有偏差（应该承 认人是会犯错误的），一个误解可能造成以后的返工。其次从管理的角度来说吧：1、有效的团队组织。提高团队组织的工作绩效，提高组员的团队精神。这非常有利团队有效，有序的工作。 有效的团队建设，这是管理的重要内容。2、小组成员的沟通、协调。沟通，也许在各行各业都已提到了一个相当重要的位置。在一、二十年前，也许您会经 常

22、听到某位大侠单独完成了某种创举，成了人们崇拜的对象。可今天，这种大侠，已经很难 有生存空间了。取而代之的是，某军团，又攻克了一座什么样的宝垒。这样，沟通，可以说 已经变得无比的重要。在软件业，沟通可以说是快速学习和掌握新知识，达到技术上的更高 层次的最佳途径。小组员的沟通，可以很好的加强团队组织的凝聚力。可能更好的让项目 良性的进行。而培养这种气氛，形成有效的沟通，这也是项目管理的基本内容。协调几个人 的工作比自己完成一段编码更重要。如果小组成员在协调上出了漏洞，可能导致很大的问题， 所以项目负责人必须随时监控各开发人员的工作，包括内容是否与要求发生偏差，进度是否 滞后等等。最后从测试的角度来

23、说吧。传统观点认为，测试是在编码后的工作。其实，测试和编码是两个密不可分的阶段，交 叉进行的，测试在编码后期进行的较多！主要有两方面：1、不经过单元测试而直接进入系统测试；造成这一现象的原因是每个模块相对比较简单，但是为了测试一个模块需要建立一些测 试环境。例如，为了测试一个函数是否正确，应该用一些测试数据去调用该函数，需要编写 一些测试数据。但很多开发人员嫌麻烦，觉得反正其他模块也很快出来了，直接用真正的数 据来运行几次就行了。殊不知，一旦直接进入系统测试，发现运行结果不正确后需要一步步 查找。不但耗费了大量的查找时间，而且后面的模块已完成了，修改前面的模块又会影响后 面的模块，使的修改的难度增加，修改后导致新的错误产生的概率增大，另外，每个人的潜 意识都不想否定自己，这种情况下很难真正去修改。还有由于这种测试不完全，真正运行系 统，当调用某模块时，可能大部分时候都是正常数据，极少出现边界情况，可能某些边界情 况容易被忽视，很久之后才被发现。但是如果对每个模块进行单元测试时都进行一下边界测 试，就会很容易