课程报告

存档

课程报告命题

假如你被任命为该项目的项目经理，在拿到软件招标文件和合同之后，你该如何开展后续工作以保障项目的顺利实施及交付？

项目经理的责任

项目经理就是项目负责人，负责整个项目的计划、实施和控制，是项目管理的核心。-MBA智库

身为项目管理的核心，项目经理的责任重大。项目经理唯一的任务就是：确保项目成功。所以我认为，作为一名项目经理，在拿到招标文件和合同之后，必须对项目存在有敬畏之心。无论项目是大是小，是容易是困难， 项目经理要提高自己对项目的重视程度，把项目视为自己的生命。 这样才能带动项目组成员一起奋斗，才能推动项目的进行从而达到最后的成功。

准备工作

由于已经拿到了项目的合同书，并且任命我为项目经理，即项目以及进入实质的执行阶段。

如果我身处于一个大公司，而我的项目又只是公司内部大大小小的项目之一，我会通过邮件公告全公司的各个部门，通知他们以我为项目经理的项目已近进入了执行阶段。这样做的好处有两个：

• 通知各个部门，例如财务、人事部门，以便于各个部门之间的协调工作。
• 通知公司内部的技术人员，以便将来组建开发团队。

在完成通知之后，我将认真的阅读该项目的招标文件和合同，对项目有一个整体性的认知，并将一些关键的信息标注出来，以便于以后查阅。在完成对项目招标文件和合同的阅读、理解的同时，可以开始组建项目团队。

组建团队

组建需求调研小组

软件项目范围首先从项目需求开始

软件需求调研小组需要项目客户方进行沟通，对项目的需求进行调研。并攥写相应的需求文档，以结构化、规范性的文字对项目的各项需求进行阐述。所以，我认为，需求调研小组需要由以下人员构成：

• 技术人员

技术人员的主要责任是对客户的各项需求进行评估，以确保各项需求的可行性。并且对客户不可行的需求提出改进、改善意见。

• 对该项目业务熟悉的人员

隔行如隔山，真正的大项目往往是跨学科、跨领域的。例如，该项目是构建突发公共卫生事件应急指挥系统，那么，就需要有一个人对该项业务比较熟悉，明白项目需要做什么，做出来大概是个什么样子，有什么功能，这样才能与顾客更好的沟通。

• 文秘

文秘需要良好的文字基础，能够对客户提出的各项需求进行总结提炼，并攥写规范化、明确的项目需求文档，对项目需求进行精确的定义。

上述的所有人员都在于客户沟通项目需求前，都需要系统的学习该项目所设计到的业务逻辑，对业务有一个整体性的认识。另外，在人手不足的情况下，一个人也可以兼任多项职务。

项目需求文档的发布，并不意味着项目需求调研小组生命的结束。我认为，项目需求调研小组的生命是伴随整个项目的。因为需求是不断改变的，项目需求调研小组需要在整个项目的执行过程中不断的与客户沟通，修改完善项目需求文档。

项目需求调研小组作为整个项目组内最早的一批对项目有整体认知、对业务逻辑有充分了解的团队，还应该承担起对项目内其他人员的培训责任，让他们明白我们需要做什么。并且当项目开发遇到分歧或者困难时，需要对项目开发小组做出指导。

组建开发小组

在软件企业中同一职位上最好的员工比最差的员工的劳动生产率要高三倍。

《人月神话》中指出，需要协作沟通的人员数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果。这启迪我，软件项目应该由尽可能少的人员来开发。但是，小型、精干的工作团队，其对于大型的、系统的项目来说，工作进度太慢了，可能会使项目超期。如何处理这种矛盾呢？该书也出了解决方案：组建外科手术式的队伍：由一个人完成问题的分解，其他人基于他相应的支持，来提高效率和生产力。所以说，组建的团队构成应该是这个样子的：

• 首席程序员

首席程序员需要极高的天分、长时间的工作经验、熟练的业务经验，还有大量的系统知识和应用知识。他是团队里的技术核心。亲自定义功能和性能技术说明书。

• 副手

他是首席程序员的后备，能够完成任何一部分的工作，但是相对具有的经验较少。他的主要作用时作为设计的思考者、评估人员。他也可以参与到具体的编码。

• 文档编辑

文档编辑需要创建各种文档。根据首席程序员的草稿或者口述，进行分析和重新组织，提供各种参考信息。

• 程序员

程序员的工作很简单，即根据文档生成代码。程序员根据其掌握的不同技能，也有不同领域的划分，有的负责数据库，有的负责前端，有的负责后台。

• 管理员

项目中需要有一控制财务、人员、工作地点和办公设备的专业管理人员。一个管理员可以为两个团队服务。

• 两个文秘

管理员和文档编辑每个人需要一个文秘。负责项目的协作一致和非产品文件。

graph LR
首席程序员-->文档编辑
首席程序员-->程序员
首席程序员-->副手
首席程序员-->管理员
管理员-->文秘1
文档编辑-->文秘2

这样外科手术式的队伍，其优点就是能够保证项目概念的完整性，即所有的概念、思路都在首席程序员处汇集。但是，上述的设计只是针对10人左右的小的项目团队 ，不过针对更大型的项目团队，仍可以采用外科手术式的思路来建立团队。

组建测试小组

整个团队需要大量合适的测试用例，而测试人员则负责根据项目要求产生测试用例，测试软件是否能够正常的运行。他也负责计划测试的步骤和为单元测试搭建测试平台。

我阅读了很多相关的书籍和资料，发现了一个很有意思的现象：有的开发团队将测试人员视为开发小组的一部分，认为软件测试时软件开发中的一环；有的则建议将测试小组从软件开发小组中独立出来。我对后一种方式比较认同，所以我认为，测试小组需要单独组建，并且和开发小组分离开来。

原因很简单：测试的工作和开发的工作是相对立的。 如果说开发小组的工作是通过代码来构建整个软件，那么测试小组的工作则正好相反，他们通过代码（也可能是其他的方式，不过现在自动化测试是主流的测试方式）来摧毁这个软件，使软件无法正常运行———即寻找软件的BUG。测试小组如同整个软件项目中的黑衣人，他们以寻找软件的漏洞为乐趣。

将测试小组和开发小组隔离开来，好处就是：团队内部会形成一种良性的对抗。测试小组想尽了各种方法来刁难开发小组，开发小组也会竭尽全力确保代码的质量。这种良性的对抗会使原本无聊的编程变得有一丝“乐趣”，从而提高代码的质量，从而提高软件的质量。
但是，有一个很严肃的问题是：这种对质量的追求会不会拖慢项目的进度？

《人件》中的一句话给出了答案：

质量是免费的。

对质量的追求会使程序员更加专注于工作，而这种专注又会使工作的效率提高。

人员流动

在上述团队构建中，每个职位都是十分固定的，但是其人员并不是固定的，而是不断流动的。并且流动的方式多种多样：可以一人同时承担多职，也可以随着项目的进度而改变制位划分，更可以多个项目公用一个人（小组）。例如，测试小组可以是多个项目公用，他们是游荡在各个项目之间的“黑衣人”，为不同的项目提供服务。这种流动式的人员安排能够提高人力资源的利用程度，在某种程度上减少项目成本。

任务分解与制定计划

任务分解（WBS）

在完成项目团队组建，项目需求调研后，便可以开始进行任务分解。WBS任务分解结构是软件工程项目管理的重要基础，将工程项目的各项目内容按其相关关系逐层进行分解，直到工作内容单一、便于组织管理的单项工作为止。WBS分解应该由开发小组中的首席程序员牵头负责，确保项目概念的完整性。WBS分解可以按照目标分解，也可以按照项目产品的功能分解。并且WBS有两个原则：

• 横向到边。即百分百原则，指WBS分解不能出现漏项．也不能包含不在项目范围之内的任何产品或活动
• 纵向到底。指WBS分解要足够细，以满足任务分配、检测及控制的目的

制定计划

任务分解以后，我们的首要问题是对每个任务的工作量进行比较准确的估计，这样才能保证我们制定的计划的可实施性。制定计划的方式多种多样，最常用的呈现方式应该就是甘特图了。

gantt
dateFormat YYYY-MM-DD
section S1
T1: 2014-01-01, 9d
section S2
T2: 2014-01-11, 9d
section S3
T3: 2014-01-02, 9d

同时，建立关键路径图，也是合理安排项目计划的一种有效方式。

与客户的沟通

做足准备工作

软件开发小组针结合自身实际情况，积极主动去查阅相关资料，学习和了解与客户业务相关的基本知识。软件开发小组只有真正了解相关业务知识的情况下才能更好地理解客户使用软件的目的，消除与用户之间在业务知识方面的沟通障碍，更好地判断软件的系统功能和软件的系统流程是否符合用户的根本需求。

发挥引领的作用

由于客户缺乏计算机的相关知识，对需要规划设计的项目和系统软件的应用特点缺乏全面的了解，因此在进行需求调研时，用户仅仅关心局部的业务需求和数据需求，缺乏全面合理的规划设想因此，这就需要软件开发方在进行需求分析时充分发挥沟通引领作用，逐步引导用户进行全局考虑，鼓励用户进行前瞻性规划，尽量避免在需求分析中包含技术实施上有难度的功能。这也正是为什么需求调研小组中需要有技术人员的参与。

防止信息失真

从我自己的实际生活中来看，信息失真是经常发生的事情。信息失真不仅仅发生在项目组与客户的交流之间，同时也发生在项目组成员之间。信息失真往往会导致非常严重的后果，因为团队协作的基础就是沟通。所以，在沟通的过程中，需要使用正确的表达方式，尽量避免使用方言，从而降低信息的失真率。

参考文献

<code class="shell">[1]刘卓炯.软件项目任务分解的思考[J].电脑知识与技术,2009,5(8):1934-1935.DOI:10.3969/j.issn.1009-3044.2009.08.065.
[2]王红星.软件项目的成本管理研究[D].合肥工业大学,2007.DOI:10.7666/d.y1053403.
[3]钟银,孔祥斌.软件项目部署开发与项目实施过程中的沟通分析[J].网友世界·云教育,2014,(12):3-3.
[4]庄欠满.IT软件项目中的沟通管理[J].科技信息,2009,(31):853.DOI:10.3969/j.issn.1001-9960.2009.31.668.
[5]康壮.软件开发项目管理方法研究[D].对外经济贸易大学,2003.DOI:10.7666/d.y509842.