小型软件企业的项目管理
--------------------------------------------------------------------------------
51CMM原创 作者：冯志桔 [2003/10/16]
20年前，项目管理的应用仅限于美国国防部的承包商和建筑公司。如今，项目管理的基本思想已被广范应用于国防，建筑，制药，化工，电信，软件开发，银行，广告，会计，司法，政府和联合国等领域和机构。这些机构已经意识到了项目管理和生产率之间的紧密关系，及其在当今商业环境中的至关重要性。
一项调查表明，大约70%的软件开发项目超出了估算的时间，大型项目平均超出计划交付时间20%至50%，90%以上的软件项目开发费用超出预算，并且项目越大，超出项目计划的程度越高。因此，软件开发迫切需要进行项目管理。但是，软件开发不同于其他产品的制造，软件的整个过程都是设计过程（没有制造过程）；另外，软件开发不需要使用大量的物质资源，而主要是人力资源；并且，软件开发的产品只是程序代码和技术文件，并没有其他的物质结果。基于上述特点，软件项目管理与其他项目管理相比，有很大的独特性。
第一章 小型软件公司的特点
俗话说，聚沙成塔，没有在金字塔地层下大量的小型的甚至是作坊型的小软件公司，就不可能有大型的特大型的软件公司。现在，无论是大学的教程，还是书本，讲的软件工程管理都是针对大中型软件公司的，连网络上也很少有针对小型软件公司的项目管理文章。小型的软件公司只有实行软件项目管理，才能生存和发展，才能向大中型软件公司迈进，才能使软件产业更加繁荣！
一个企业的管理，大公司有大公司的方式，小公司也有小公司的方式，如果把别人的经验生搬硬套到自己身上，可能会适得其反。同样，管理一个软件项目也一样，大项目和小项目的方式不完全一样。但从另一个角度来看，项目的大与小并没有本质的区别，很多方法是共通的。本文的目的是从作者的经验来谈谈小型软件公司的项目管理。
小型软件公司相对与大中型软件公司而言，有以下的特点：
1、项目负责人一般也是公司的老板,对软件工程有一定的了解，但不全面，相对而言，对市场的了解较为透彻或对技术很精通；
2、项目功能相对较少 ，涉及面相对较狭窄；
3、开发人员较少，人员结构简单 ；
4、开发周期较短 ，少则两三个月，多则一到两年。
总的而言，大中型软件公司，软件开发主要分为六个阶段：需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段。软件公司将软件配置管理、软件质量管理、软件风险管理及开发人员管理四方面内容导入软件开发的整个阶段。小型软件公司的软件开发同样分为六个阶段，但比较模糊，侧重点也不一样；至于软件配置管理、软件质量管理、软件风险管理及开发人员管理四方面内容则比较少。
大中型软件公司开发软件就如八股文一样：总体规划、项目立项、需求分析、系统分析、系统设计、编码实现、项目测试、文档制作（八股文：破题、承题、起讲、入手、起股、中股、后股、束股），一切都按部就班。小型软件公司开发软件就是写现代文：不拘泥于形式，但同样符合规则！！
为了符合小型软件公司的管理特点，本文将小型软件公司的项目管理分为三个部分：
编码前的管理、编码的管理、编码后的管理。
第二章 编码前的管理
无论是项目，管理都必须在以人为本的前提下进行。以人为本，指的不只是软件开发人员这一部分。这里的人主要指的是一些与项目有利害关系的一些人，即项目干系人(stakeholders)，一般包括客户或者用户、项目团队、项公司的管理层等一些主要的利害关系者。 一个项目能否成功，很大程度上取决于能不能分清楚这些项目利害关系者各自对项目的影响，不能利用好这些人力资源，沟通协调好他们之间的关系。
一、 管理方式的改变
在土木工程的项目管理中，成本主要分为三部分：人员工资等费用、管理费用、材料费用。其中人员工资等费用、管理费用随着经济的发展所占的比重越来越大。土木工程的项目管理为了降低人员工资费用、管理费用，采取了这样一条措施：尽量缩短工期，节假日以项目为准，平时周末不放假，项目完成在不补放。
很明显，在软件开发不需要使用大量的物质资源，而主要是人力资源，人员工资费用占软件开发成本的大头。要减低人员工资费用，我们不能削减员工工资，更不能削减必要的人员，提高软件开发人员的效率才是根本。进行软件开发有这样的一个特点：你放下的时间越长，你要重新理清前面的关系需要的时间越长，构思连续性也不好。很多小问题，也是因为中间间隔的时间太长，开发人员忽略导致的。现在，一般的软件公司，特别是大中型软件公司，都实行这样的制度：星期一到五，朝九晚五上班；星期六、星期天放假。这样，这个软件开发都给打断了，连续性很差，效率很低。
经过对土木工程的项目管理的对比吸收，以及结合目前的软件公司的管理现状，本公司实行以下的管理制度：
对于开发周期在两三个月以内的小项目：周末也要上班，只在月末才放两天假。等整个项目完成后，再把以前没有放的假期补放。例如，一个项目从三月一号开始开发，五月三十一号完成。在这期间，三月底放假两天，四月底放假两天。因为从三月份到五月份的公众假期有：27天，但前面有放了四天假，理论上可以给软件开发人员放23天的有薪假期。但实际操作时给放了半个月的假。
对于开发周期比较长的项目，跟小项目类似，每月放两天的假期，但长假不是在项目完成后放，而是每隔半年放一次，时间为一个月。
这样的管理可以在一定程度上提高开发人员的效率，又可以避免长时间因为没放假，使开发人员感到枯燥，情绪低落，动力不够，压力过大的情况。当然在实际操作时，开发人员因为自身的原因需要偶尔放的假，都会尽量满足。
本来，为了更好的提高效率，我公司还把白天的工作制度作了一些调整。一般进行软件开发，特别时编写代码的人员都有这样的体会：晚上的效率特别高。这是有原因的，晚上所受外界的干扰最少，人的精神特别容易集中，思路特别清晰。为此，我公司实行了以下制度：开发人员统一居住，下午两点到六点工作，晚上八点到十二点工作。实行这样的制度，开发人员的效率得到很大的提高。但是，由于种种的原因，此制度不能实施下去。
二、 项目风险的估计
前面说到，小型软件公司的项目经理往往是老板本人，有很强的风险意识。但在这里还是要着重说说软件工程的风险管理，因为项目经理认识的风险大多局限在商业风险（销售问题等）中，对风险的理解很片面。
软件风险是指软件开发过程中及软件产品本身可能造成的伤害或损失。风险关注未来的事情，这意味着，风险涉及选择及选择本身包含的不确定性，在软件开发过程及软件产品都要面临各种决策的选择。风险是介于确定性和不确定性之间的状态，是处于无知和完整知识之间的状态。另一方面，风险将涉及思想、观念、行为、地点等因素的改变。根据风险内容，我们可以将风险分为项目风险（成本提高，时间延长等）、技术风险（技术不成熟等）、商业风险（销售问题等）、战略风险（公司的经营战略发生了变化）、管理风险（公司管理人员是否成熟等）、预算风险（预算是否准确等）等。
另外，我们还可以将风险分为已知风险（如员工离职等）、可预报风险（从以往经验得出可能有风险的）和不可预知风险。
例如，在一些订单开发的软件中，存在着很大的商业风险。林子大了，什么鸟都有。客户多了，需要就不同，客户相关的风险出现的概率就不一样。一些人只知道他们需要什么；而另一些人知道他们不需要什么。一些客户希望进行详细的讨论，而另客户则满足于模糊的承诺。客户有不同的个性。一些人喜欢享受客户的身份，而另一些人则根本不喜欢作为客户。一些人会高兴地接受几乎任何交付的产品，并能充分利用一个不好的产品；而另一些人则会对质量差的产品猛烈抨击。一些人会对质量好的产品表示赞赏；而另一些人则不管怎样都抱怨不休。客户和供应商之间也有各种不同的通信方式。一些人非常熟悉产品及生产厂商；而另一些人则可能素未谋面，仅仅通过信件来往和电话与生产厂商沟通。一个“不好的”客户可能会对一个软件项目组能否在预算内完成项目产生很大的影响。对于项目管理者而言，不好的客户是对项目计划的巨大威胁和实际的风险。
对于大多数软件项目而言，风险因素——性能、成本、支持、进度，也代表了风险参考水平值。即，对于性能下降、成本超支、支持困难、或进度延迟，都有一个水平值的要求，超过它就会导致项目被迫停止。如果风险的组合所产生的问题引起一个或多个参考水平值被超过，则工作将会停止。在软件风险分析中，风险参考水平值存在一个点，称为参考点或临界点，在这个点上，决定继续进行该项目或终止它（问题太多）都是可以接受的。下图以图形方式表示了这种情况。如果风险的组合产生问题导致成本超支及进度延迟，则会有一个水平值,即图中的曲线，当超过它时会引起项目终止。
三、 项目进度成本效益的估计
其实，这也是项目风险有着紧密联系，是项目风险发生的一大因素之一。为此，需要做到以下几步：
1、在制定项目计划时，必须进行项目的需求分析，明确项目的需求。
在的需求分析阶段，往往存在着这样的误区：在项目的需求分析阶段，开发方与客户方在各种的问题的基本轮廓上达成一致即可，具体细节可以在以后填充。因为无论开始时有多么细致，以后对需求的修改几乎是必然的。当然这样做是有原因的：在具体实际中由于种种原因客户方很难在需求分析阶段全面而准确地描述所有问题。随着开发进度的推进，往往会有一些需求的改变。但是这样做，由于需求阶段对问题的描述不够细致，导致后来预算超出或者时间进度达不到要求。
正确的做法是：在项目需求分析阶段，双方必须全面地尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面要求、与其他软件的接口要求，以及对项目进行评估的各种评价标准。并且，在需求分析结束以后，双方还要建立可以直接联系的渠道，以尽早地对需求变动问题进行沟通。并在项目需求分析完成后，和客户明确项目的哪些部分可以在日后的进度中能修改，修改的限度，哪些不能修改。例如，应用背景、功能要求方面应该是在需求分析阶段确定，日后不能做修改。而性能、界面及接口等可以在日后作有限度的修改。
2、制定项目计划：
有人这样说计划的，“计划，计划，纸上画画，墙上挂挂，计划不如变化！”。计划很容易成为空话，特别是在软件工程中，影响计划的因素太多，计划就形同虚设了！但是，软件进行项目管理的目的就是综合各种因素，制定合理的计划，并通过计划的实施，使其规范化，从而提高项目的效益，提高人员效率，降低项目的成本。
制定项目计划首先对项目进行估算，粗算出项目的总体进度。然后进行精化：确定概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段等阶段的具体要求、完成时间、投入人力物力，并确定几个关键阶段。这些关键阶段的要求进度必须在指定日期之前完成。最后做出项目进度表，列出在每个阶段的难点要点，要注意的问题。，并将需要分析阶段的内容和项目计划、进度表整理成文档，分发到相关人员手上。
3、充分考虑影响项目计划的因素，并做出相应的措施。
影响因素可以分为主观因素和客观因素。客观因素有客户相关风险，外部环境的影响，停电，机器损坏，不能上网等原因。客观因素在一定程度上可以转变为主观因素。主观因素有：人的因素、技术因素，资源因素。人的因素，本项目是否有足够的人手，投入本项目的每一个成员有没有要兼顾其他事情、项目，人员的流动、休假甚至是离职，这些对本项目的计划有多大的影响，并对此作处相应的不久措施。技术因素，本项目是否涉及到技术问题，所占比例是多少，以前是否有个类似的问题，新技术对本项目人员而言，新到什么程度，解决需要的技术问题。要注意，盲目追求新技术，也会影响项目的进度，甚至拖垮整个项目，成为技术先烈。还有一个技术问题是，本项目的人员，对要实施的软件的行业背景的熟悉程度。根据这些因素决定是否对本项目的人员进行培训！！资源因素，项目经费是否充足，软件配置，硬件配置是否及时充足。总的来说，可以把影响项目的计划划分为A—灾难的 B－严重的 C－轻微的 D－可忽略的，对相应的等级作处相应的应变措施。
4 、根据计划估算出成本。计划一旦确定，就可以通过人力资源成本、日常办公费用、软硬件的损耗等算出本项目的成本。
四、 项目的立项：
只要经过管理方式的考虑，风险的评估，项目进度成本效益的衡量，再综合其他方方面面的因素，做出决定，是否立项。
第三章 编码的管理
在这里首先要声明一点的是，虽然在这里并没有着重强调系统设计，但系统设计是软件工程管理的很重要的一部分。这里，项目确定计划就包含了系统设计。
在以前，甚至是在现在，也有相当大的一部分人是这样认为的：软件程序主要由代码组成，因此编码阶段是整个软件项目的最重要的阶段，应该给与大量的时间，并且集中主要的资源。
其实，与以前相比，由于软件的规模和复杂度的增加，以及半自动化软件代码开发平台的出现，现代软件项目管理的中心发生了转移--不是着重编码阶段，而是着重系统总体/详细设计阶段。一般说来，在现代软件项目管理中各种资源的合理分配比例是：项目论证、风险评估阶段3%，项目需求分析阶段8%，系统总体/详细设计阶段45%，编码阶段10%，系统测试阶段34%。
但是，如果软件项目没有实施好的话，频繁地对软件进行修改、甚至重做，编码阶段就会耗费大量地时间，在整个软件工程所占地时间比例也大大增加。很多软件工程，不能按计划完成就是因为编码阶段的问题太多了。
编码阶段，要成功，就必须牢记一条：能做到少修改，不重做，力争一次成功！！
在编码阶段，只要不是原则性的错误，尽量不要推倒前面所做的一切，重新做，毕竟以前做的时候也是考虑了方方面面的因素的，现在出现的问题只是在某方面考虑不周而已，一切都作废，太浪费了。还有，要是数据库字段已存在，除非万不得已，千万不要修改数据库字段，能可添加字段。因为已经存在的字段，很有可能已被软件开发小组的其他成员在使用，不要因为你的修改而令其他人也要跟你做相应的修改。最后，软件界面的修改要慎重，界面的修改很容易使你忽略修改相应的内容，造成软件大问题没有，小问题一大堆。
要想做到不修改，不重做，很不容易，要考虑的因素很多。
首先从软件的角度来说吧:
对于专用软件，很多时候，一般用户对于软件要完成哪些功能已经有了一个比较清楚的轮廓，而且往往在开发合同中已经大致地规定了。但是，开发合同上规定的只是一个大概的框架，用户心目中的产品究竟是什么样子，有时不要说开发人员不知道，连用户本人也不知道。所以很多时候，都是到了开发工作的后期才发现开发人员的理解和用户的要求有一些误解，那么必然造成时间上的浪费。 对于通用软件，很多时候是到了开发工作的后期才发现某方面的功能不足，或要添加新功能等等。
在小型软件公司中，由于开发人员少，这样意味着不同人员的程序之间交互、接口相对少一些。开发周期短意味着往往是同样的几个人从头到尾负责一个项目。这两者都让人容易犯些错误。往往是几个人碰一下头，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，没有一份较正式的文档。当有的人会对讨论出的接口、结构理解有偏差(应该承认人是会犯错误的)，一个误解可能造成以后的返工。
其次从管理的角度来说吧:
1、 有效的团队组织。
提高团队组织的工作绩效，提高组员的团队精神。这非常有利团队有效，有序的工作。有效的团队建设，这是管理的重要内容。
2、 小组成员的沟通、协调。
沟通，也许在各行各业都已提到了一个相当重要的位置。在一、二十年前，也许您会经常听到某位大侠单独完成了某种创举，成了人们崇拜的对象。可今天，这种大侠，已经很难有生存空间了。取而代之的是，某军团，又攻克了一座什么样的宝垒。这样，沟通，可以说已经变得无比的重要。在软件业，沟通可以说是快速学习和掌握新知识，达到技术上的更高层次的最佳途径。 小组员的沟通，可以很好的加强团队组织的凝聚力。可能更好的让项目良性的进行。而培养这种气氛，形成有效的沟通，这也是项目管理的基本内容。协调几个人的工作比自己完成一段编码更重要。如果小组成员在协调上出了漏洞，可能导致很大的问题，所以项目负责人必须随时监控各开发人员的工作，包括内容是否与要求发生偏差，进度是否滞后等等。
最后从测试的角度来说吧。
传统观点认为，测试是在编码后的工作。其实，测试和编码是两个密不可分的阶段，交叉进行的，测试在编码后期进行的较多！！主要有两方面:
1、 不经过单元测试而直接进入系统测试;
造成这一现象的原因是每个模块相对比较简单，但是为了测试一个模块需要建立一些测试环境。例如，为了测试一个函数是否正确，应该用一些测试数据去调用该函数，需要编写一些测试数据。但很多开发人员嫌麻烦，觉得反正其他模块也很快出来了，直接用真正的数据来运行几次就行了。殊不知，一旦直接进入系统测试，发现运行结果不正确后需要一步步查找。不但耗费了大量的查找时间，而且后面的模块已完成了，修改前面的模块又会影响后面的模块，使的修改的难度增加，修改后导致新的错误产生的概率增大，另外，每个人的潜意识都不想否定自己，这种情况下很难真正去修改。还有由于这种测试不完全，真正运行系统，当调用某模块时，可能大部分时候都是正常数据，极少出现边界情况，可能某些边界情况容易被忽视，很久之后才被发现。但是如果对每个模块进行单元测试时都进行一下边界测试，就会很容易消除一些隐患。真可谓欲速则不达也！
2、 如果在项目人员配置中设置了专门的测试人员，编码人员会认为软件所有的内部测试工作全部应该由测试人员完成。
众所周知：软件程序测试可以分为“白盒法”和“黑盒法”两种方式。由于使用“白盒法”对测试人员各方面素质的种种要求，在进行程序测试时测试人员总是最优先使用“黑盒法”。他们的工作方式往往是先对程序进行“黑盒法”测试；如果测试没有通过，不得已这才考虑对程序代码进行“白盒法”测试。显然，这种对“白盒法”有意无意的“逃避”，对软件的可靠性和稳定性构成了威胁，造成在编码后期，甚至是在试运行或运行阶段需要进行大量的修改。如何解决这个问题？一方面需要提高对测试人员的要求，另一方面也需要程序员完成部分的“白盒法”测试（实际上，程序员往往也是进行“白盒法”测试的最佳人选）。
在代码阶段，除了要想做到不修改，不重做外，还需要对软件的质量进度等进行控制，必须做到以下几点：
1、 定期召开项目工作会议，向项目开发人员及时了解项目进展情况及存在的主要问题。一旦发现问题，管 理人员应迅速查明原因，尽快采取措施，争取在尽可能小的范围内解决问题。
2、 在软件开发过程中，请专家和用户按照里程碑评审阶段性的成果，判定开发进度 是否与软件项目定义的里程碑保持一致，开始时间是否与计划时间一致。
第四章 编码后的管理
编码完成后，就是软件实行试运行、运行阶段，并生成相应的版本，并进行相应的备份。这个工作很重要，特别是版本生成备份，很容易出错。笔者在曾经犯过这样的错：给了老版本给用户；把为甲做的版本给了用户乙；备份时把以前有用的版本覆盖了等等，不一而足。要避免犯这些错误，就必须要在每次生成不同的版本或者备份时，都要建立相应的文章。在文档中，尽可能详实地记录本版本或备份的时间、目的，特别是和其他版本的不同之处。写的越详实，出错的概率越小！！
