1. 项目过程

根据项目实践中遇到的问题，结合个人经验总结与培训所学知识，以下对项目开发过程中常见的问题及解决方案进行梳理。

1.1 签订合同

项目合同内的范围描述往往较为模糊，导致后期项目范围蔓延（Scope Creep），但项目费用保持不变。在国内的售前阶段，承诺往往难以落实到细节，通常在合同签订并启动后才会发现问题。

建议措施：

  • 合同中应明确需求变更的级别、对应的工作量及费用标准。
  • 签订合同是一项高风险技巧，建议将系统边界、功能范围及解决方案作为合同附件一起签署。
  • 当客户提出新功能时，可依据合同边界将其暂置或纳入变更流程。

1.2 团队建设

立项后应尽早确定项目负责人及项目经理。该角色至关重要，需具备很强的综合能力及人格魅力。

关键策略：

  1. 统一联系人：尽最大努力让客户指定一名统一联系人加入项目团队。避免多位领导（如“张领导”、“王领导”）直接下达不一致的指令，防止项目组卷入客户内部矛盾。项目初期需定好规矩：项目组只认单一意见，客户内部请先统一后再对接。
  2. 人员选拔：项目经理可能无法完全自主选择组员，但应发挥影响力寻找合适人选。团队成员组成因项目而异，但必须包含精通客户业务的人。在小项目中，这通常是项目经理本人；在大项目中，应配备行业专家（Industry Expert），以确保与客户沟通无障碍。
  3. 人岗匹配：项目经理需了解每位组员的情况，善用其特长。软件行业在项目管理及人员管理上具有特殊性。

项目经理的核心关注点：

  • 做哪些事情
  • 做到什么程度
  • 怎么交货
  • 手上的资源
  • 各个事情的优先级

所谓“多快好省”往往是相互矛盾的。考虑问题的轻重缓急时：

  1. 快（进度）：各方领导都会设定最后期限，保进度通常放在第一位。
  2. 省（成本）：企业的根本目的是盈利，若收入不能增加，至少需控制费用。
  3. 好（质量）：虽想精益求精，但若缺乏资源保障，质量可能需暂时妥协。
  4. 多（范围）：客户需求源源不断，降低客户期望值，使其从理想回归现实，也是项目经理的分内工作。

1.3 需求调研

在需求调研分析阶段，常见问题包括：项目组对客户组织结构、人员关系及工作职责了解不足，导致无法获取完整需求；项目经理和需求分析员工作不够细致；客户参与程度不高，责任人不明确，提出的需求具有随意性；多个用户代表意见不一致且希望尽早交付；过度注重领导需求而忽视实际使用者，导致后期需求变更频繁，引发范围蔓延、进度拖延及成本扩大。

许多公司虽概念上重视需求调研，但实际上为了赶进度，常省略文档工作或减少投入，导致无法对比功能变化与原始需求。造成上述现象的根本原因是未全面了解所有项目干系人（Stakeholders）的需求，以及对调研重视程度不够。软件开发没有捷径，省掉的工作后期会有更高代价。

软件开发项目的目的是实现项目干系人的需求和愿望。若缺乏充分沟通，导致项目范围不清或后期需求变更，可能造成工期延长、成本增加甚至项目失败。因此，从项目启动开始，需求分析员及项目成员需分清干系人，通过沟通协调驱动其支持项目，明确需求，减小阻力。

有效措施：

  1. 尽快熟悉项目干系人全貌

    • 受进度影响，需求分析员常与技术部门交流较多，而忽视业务管理部门和实际使用者，导致软件试用后需大幅调整。
    • 熟悉干系人全貌是需求调查的基础。最重要的是理清建设单位中的人事组织与业务关系。
    • 建议绘制相关单位组织结构图，建立调研对象通讯录以保证及时沟通。
    • 注意干系人的主次关系，以便在需求矛盾时进行合理取舍。
    • 熟悉建设单位内部相关部门的业务划分及相互关系，为功能分析准备资料。
    • 特别要与客户方业务与技术的规划者和实际使用者深入探讨，收集原始资料，保证需求调查的完整性、正确性。
    • 在建设单位组织结构图基础上，绘制全体项目干系人结构图，以便更全面地进行需求调研分析。

  2. 详细描述各项业务，以利于让客户确认

    • 全面详细地调查并描述原有系统（包括不足、优点及用户操作习惯）和用户希望将来系统具有的业务流程。
    • 将业务流程文档化后与客户讨论，修正错误或不准确之处，最终让客户确认。
    • 对业务处理过程了解的完整性和准确性非常重要。虽然数据操作多为增删改查，但具体业务分为若干步骤，需调查清楚才能设计出适合各流程业务节点用户特点的软件。
    • 在软件概要设计时，要尽量排除业务流程的制约，将流程中的各项业务结点工作作为独立对象，充分考虑接口，通过业务对象相互调用实现业务流程。这样在业务流程发生有限变化时，能方便地修改系统程序。
    • 调查资料可包括：遵循的标准、工作手册、作业流程、上级通知、办事指南、登记表、统计报表及其他类似系统的技术资料等。

  3. 可视化需求调研，引导客户挖掘需求

    • 很多客户缺乏计算机知识，无法提出完整、准确、隐含或潜在的需求。需求分析人员应善于想用户所想，利用启发方式探讨潜在需求。
    • 利用可视化需求调研方法（如图表工具）启发用户清楚叙述需求。

    • 针对不同人群使用不同图表：

      • 高层领导：系统总体框架图。
      • 业务管理人员：业务流程图（描述新旧系统业务流程）。
      • 技术人员：数据流图、实体关系图或 UML 各种图形。
      • 各层次用户：用户界面图（UI 草图）。
    • 用户界面的重要性：建议在需求调研时（紧接着原有系统调研分析和系统模型完成之后）与客户讨论界面设计。此时客户对将来系统尚无清晰概念，画出用户界面草图与客户讨论，可激发其提供更为准确全面的需求。这些界面在后期开发中也可利用。
    • 所谓需求就是“当你按下各种相关按钮（或输入各种相关命令）时系统做什么”，所谓设计就是“系统怎么做”。需求的最终目的是完整准确地描述系统需要的各种接口或“界面”，及其相互关系。自顶向下把这些界面及涉及到的数据描述清楚，就是一份不错的需求。

  4. 与其他项目小组成员共同协作、持续完善系统需求

    • 需求文档完成后并非万事大吉。项目组其他成员对需求的有效性起到验证作用。
    • 上一阶段的工作成果往往要通过多次沟通才能被下一阶段成员接受，其有效性、合理性也要被下一阶段的工作所检验。
    • 无论是同一阶段不同人员之间，或是不同阶段人员之间，都应根据需要相互协作，共同完成软件开发任务。

  5. 《功能规格说明书》

    • 这是项目中最大的失误点之一，若缺失会导致后期客户改动让项目组很被动。《功能规格说明书》反映了客户提出的所有需求功能，后期客户的变化都可与之对比，具体变更按照变更流程执行。
    • 作为产品需求的最终成果，必须具有综合性，包括所有的需求。开发者和客户不能作任何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明，那么它将不能作为协议的一部分并且不能在产品中出现。

    • 注意事项：

      1. 完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。注重用户的任务而不是系统的功能将有助于避免不完整性。如果知道缺少某项信息，用“待确定”作为标准标识来标明这项缺漏。在开始开发之前，必须解决需求中所有的“待确定”项。
      2. 正确性：每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源，如用户或高层的系统需求规格说明。只有用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。
      3. 可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。最好在获取需求过程中始终有一位软件工程小组的组员与需求分析人员在一起工作，负责检查技术可行性。
      4. 必要性：每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如使用实例或别的来源。
      5. 划分优先级：给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制。
      6. 无二义性：对所有需求说明的读者都只能有一个明确统一的解释。尽量把每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。
      7. 可验证性：检查每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。如果需求不可验证，则确定其实施是否正确就成为主观臆断。
      8. 一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。在开发前必须解决所有需求间的不一致部分。
      9. 可修改性：在必要时或为维护每一需求变更历史记录时，应该修订文档。这就要求每项需求要独立标出，并与别的需求区别开来。每项需求只应在文档中出现一次。使用目录表、索引和相互参照列表方法将使软件需求规格说明更容易修改。
      10. 可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链。这种可跟踪性要求每项需求以一种结构化的，粒度好的方式编写并单独标明，而不是大段大段的叙述。

1.3.1 需求变更管理

项目的需求变化是肯定的，而且变化一般都很频繁。应对客户的需求变化，建议“以不变应万变”。

应对策略：

  • 前期准备：需求调研要做好，尽可能替用户考虑，达到功能质量满足最大化。
  • 签字确认：需求调研前期的《目标与范围》和需求调研末期的《功能规格说明书》都要跟客户签字确认。这既能保证我们所理解的需求就是客户所要的，也使得项目末期跟客户验收时有据可依。

  • 变更流程：在项目中期发生需求变更是很常见的，这时要做好需求变更管理流程。

    • 小的变更自己掌握。
    • 客户要求的变更由开发人员和设计人员共同商讨后提交项目经理。
    • 项目经理预估变更损耗工程时间，在一定阶段一起提交给客户。
    • 大的变更直接提交客户，并且要把需求变更对项目产生的影响让客户知道，将决策权交还给客户，让客户在进度、功能、资源三者中取舍出一个平衡来。
  • 分类评级：对需求进行分类评级，关键部分不能改动的做特别确认（如系统架构等，如果改变等于从头再来）。
  • 合同细节：完成客户签字确认，如果能将这部分写成合同细节中去是最好。

变更步骤建议：

  1. 第一步：客户提出变更内容

    • 客户提交的变更必须基于书面形式。

    • 客户提交的变更必须有充分理由。

      • 如果变更被拒绝，对业务的负面影响。
      • 如果变更被接受，对业务的正面帮助。

  2. 第二步：为能否实现变更作评估

    • 从实现方式上考虑新的变更可否实现。
    • 对于较复杂的情形，辅以简单的说明。欲详述，可作附件处理。
    • 对于简单情形，例如页面布局更改，则无须说明。

  3. 第三步：可以实现看进度

    • 进度几乎是绝大部分项目关注的第一要素。
    • 对于活动级别的进度影响。
    • 对于项目整体工期的影响。

  4. 第四步：变更成本

    • 人力相关的变更成本。

      • 是否需要额外的项目组成员。
      • 项目组需要增加的工时数（是否正常工时、工作日加班、节假日加班）。
      • 项目工数报价。

    • 非人力成本。

      • 软硬件费用。
      • 资料费用等。

  5. 第五步：质量和风险

    • 变更对质量的多方面影响。

      • 分阶段影响（需求、设计、编码、测试、维护）。
      • 可靠性、安全性、可维护性、可用性等。
    • 可能对团队士气的负面影响。
    • 可能引发的间接任务对工期的负面冲击。
    • 开发方的成本负担可能超出力所能及的范围。

  6. 第六步：需求变化的确定

    • 最终确认是否执行变更，并更新相关文档。

1.4 架构设计

撰写详细设计是一个逐步细化、深入的过程。没有人能一次就设计出完美的东西，需要及时的沟通，包括与客户的反馈，与其他项目组成员的讨论，这样有助于降低开发时偏离需求的风险。

设计原则：

  • 在开发之前，设计必须建立在设计者的想法有客户的确认和开发人员的理解的基础之上。
  • 设计撰写人必须与系统分析员反复讨论，以透彻理解用户需求。
  • 一项需求可能有多种方式实现，设计者必须与系统分析员确定该需求将采用何种方式实现，将达到何种效果，以消除将需求映射为设计的歧义。
  • 讨论过程中还可能会发现需求有不完备甚至错误的地方，在需求重新确定后设计者需修正设计。
  • 设计文档必须写清楚各个模块/接口/公共对象的定义，列明程序的各种执行条件与期望的运行效果，还要正确处理各种可能的异常。
  • 设计文档应该遵循一定的写作模式与版面风格，使用统一的术语或惯用语，使得小组成员很容易理解。

常见问题：
一些公司的详细设计通常是由程序主管或少数核心的程序员撰写的。他们技术最为精湛，对架构最为熟悉，最有资格评价现有架构是否能适应新的用户需求。但是由少数人来负责所有的详细设计可能造成开发过程中的瓶颈甚至是设计的错误。当任务比较集中的时候，设计者可能忙得透不过气，而负责实现的同事反而在等米下锅。于是为了让自己不成为拖累进度的“罪人”，某些设计者就会采用一种快捷方式来交付设计：他们会与系统分析员进行初步的讨论，然后撰写一份粗糙的但仍然叫做详细设计的文档，把它交付给负责实现的同事，再通过讨论、即时通工具、电子邮件等方式解答对方提出的疑问。但由于详细设计本身不完备，他们不得不花费更多的时间和精力与负责实现的同事沟通；而且他们却很可能忘了把这些交流的成果更新到详细设计中去！其结果很可能是当产品开发出来后，我们才发现它跟用户要求的完全两样！原本在详细设计阶段就应该发现的需求漏洞与在那时应该确定的技术方案在实现阶段甚至测试阶段才暴露出来，而这时大家往往有木已成舟的感觉，改动的难度比设计阶段高数倍甚至十倍以上。

解决方案：全员设计
全员设计的含义就是把详细设计的工作进行适当地分解，把它们分摊到小组内其它同事身上，让大家都参与设计。

  • 当一组用户需求基本确定下来后，程序主管需要估计需求的相关性、需求的优先级、设计的难易程度、设计的工作量等，将该组需求分解为一或多项设计任务，并指定给适当的同事。
  • 参与设计的每个人必须负责至少一项设计的撰写任务。
  • 设计者从系统分析员处获得详细的用户需求，并与系统分析员反复沟通以透彻理解用户需求。
  • 他还要分析系统架构及产品的已实现与/或已规划部分，理解架构的设计理念，理解产品不同模块之间的协作关系，理解架构与产品之间的约束和依赖。
  • 一项设计任务，它可能需要多个程序员完成。比如用户界面或网页由某位或某组同事负责，而业务逻辑组件则由另一位或一组负责，数据库部分则又由其它同事负责。
  • 设计者必须考虑他们的立场，以各方面都相对容易理解的方式写清楚主要的模块/接口/对象定义，明确相应的调用规则与主要逻辑处理。
  • 如果某项设计任务所涉及的内容太专业化，设计者并不熟悉相关的内容（比如某位 C# 程序员并不熟悉如何编写一个存储过程），他可以用描述性的文字说明该部分的设计要求，并知会相关的同事补充。
  • 在设计文档完成后，设计者必须把他提交给程序主管或由程序主管指定的程序员审阅。个人推荐由其它程序员而不仅仅是程序主管来审阅。
  • 大家可以并行地工作，不必是 A 审阅后才能 B 审阅。可以交叉审阅，即 A 的设计由 B、C 审阅，B 的设计由 A、C 审阅等。
  • 审阅意见可以用多种方式（如讨论、即时通工具、电子邮件）反馈给设计者，设计者负责汇总这些意见并修正设计。
  • 通常设计交付审阅后半天内就可以收到反馈意见了。设计经过反复地修正直至没有人再提出修正意见，这时就可以由程序员实现了。通常一份设计两、三轮反馈后就可以定稿了。

  • 如果多次反馈后仍不能定稿，极有可能是：

    • 需求尚未明确，各个方面（包括客户、系统分析员或设计者）对需求的看法不统一。
    • 技术或系统架构存在严重的限制，无法用较方便的方式实现。

1.4.1 全员设计的好处

  1. 有助于平衡工作量，加快开发进度：详细设计的任务分解后，程序主管或核心程序员可以有更多的时间处理其它的事务，比如关注软件的开发质量或改善系统架构。详细设计的撰写任务分解后它们可以并行地撰写，这将极大地提高设计撰写的进度，节约时间。
  2. 有助于培养程序员的大局观：每位撰写设计的程序员不再仅仅只关心自己负责实现的模块，他必须从更高的层次考虑和理解设计。
  3. 有助于加强同事之间的交流与协作：设计者需要与系统分析员、其它程序员、审阅者进行反复的交流和沟通，实际上每份设计都是多人协作的成果。更多的沟通有助于集思广益，有助于避免一、两个人的倾向性意见导致错误的设计。每位设计者都需要对自己撰写的设计负责，他还要向其它同事的设计提供审阅意见或技术建议，彼此的工作是互相支持和依赖的，这有助于减少“只扫自家门前雪，不管他人瓦上霜”的想法。

1.4.2 推行全员设计的潜在风险

  1. 交流成本增加：在某种意义上，全员设计可能增加交流的成本。两个人之间有一条交流途径，三个人之间最多有三条，四个人之间最多有六条。途径越多，信息量就越大，而这些信息不见得都是有用的信息。详细设计的任务分解后，不可避免地有更多的人参与交流和沟通，大家要花更多的时间来理解他人的想法，也可能要花更多的时间向他人阐述自己的观点。特别是在并行撰写详细设计的过程中，系统分析员反而可能成为另一个瓶颈了。但从总体上来看，在设计阶段花费适当的代价发现更多的问题，比在实现阶段或测试阶段再发现问题，仍然是划算的。
  2. 设计冲突：分解后的详细设计可能引入冲突的设计内容。由于设计由不同的程序员撰写，他们考虑问题的角度和思维的方式不可能完全一致，这增大了不同的设计内容之间的计算口径或交互方式不一致的可能性。这需要设计者们尽可能遵循一致的设计原则，也需要审阅者们尽可能找到这些不一致的地方。
  3. 人员适应性：并不是所有的程序员都适合参与设计。很明显，例如刚入职的同事就不适合参与设计，他们对系统架构还缺乏足够的认识。另外兼职的同事也不适合参与设计，他们的工作方式可能无法保证及时提交设计文档与参与讨论等。

1.5 沟通

在项目的开发过程中，团队中的成员之间以及和客户之间是一个不断的交流和沟通的过程。我们的开发过程最好是一个迭代式的开发过程（尤其是国内的项目）。这样我们可以尽早发现开发出来的功能是不是符合客户的需求，以免开发完了，客户说这个不是我们需要的后果。

1.6 计划执行控制

制定系统的整个计划，任务的划分以及分配工作，跟踪任务的进度，使我们的项目进度在控制范围之内。

1.7 风险管理

风险是随着项目的不同阶段变化的，不同的阶段风险是不同的。我们必须分析当前面临的风险的数量、影响程度等，以及怎么去解决这些风险。

1.8 测试

测试工作目前在国内的中小公司做的都不太好，但是从我们做项目或者产品必须重视测试工作，把握好质量关。

1.9 验收为目的的思想

在开发过程中，内部管理还要注意的一点是时刻强调以验收为目的的思想。每个任务的最终可交付成果一定要是可以被检查的。

  • 反面案例：比如【界面要求：美观大方、简洁明快】，这个要求我就不知道如何检查。
  • 正面案例：给开发小组布置任务的时候就要考虑如何检查结果。比如我见过一个计划，里面有一个任务【开发人员熟悉 EJB 编程】，这个任务，除了让这些人去参加一些专业认证考试，否则，结果很难被检查。

所以，时刻考虑如何检查结果、如何向客户交付是项目经理一直要注意的事情。我听说有些老项目经理拿到项目是倒排计划的，即首先看如何验收和验收标准，然后决定工作计划。很多项目开始了很久，还不知道如何验收，那么这个项目出问题的可能性就很大了。做项目就是为了验收，我们的角色不是研究机构，我们的目的就是在付出那么多劳动后得到结果。

说明：本文基于传统软件开发项目管理经验总结，文中提及的 EJB、C# 等技术栈及部分管理流程（如详细设计文档化）带有特定时期或特定开发模型（如瀑布模型与迭代模型混合）的色彩。在实际应用中，请结合当前敏捷开发实践及现代技术栈进行调整。