1 概述
如果你坚信客户参与是确保软件产品成功的关键因素，那么在项目的初始阶段就应积极地从各利益相关者 1那里收集意见。软件需求的准确性和项目开发的成功在很大程度上取决于开发者是否充分理解并采纳客户的需求。在之前的文章中，我们探讨了提供商业需求的一类客户——项目赞助者、愿景制定者或市场部门。而在本文中，我们将重点关注需求的第二层级——用户需求。
为了有效地获取客户意见，需要遵循以下步骤：
- 明确识别项目用户需求的来源。
- 确定使用该产品的不同类型的用户群体。
- 与各类用户代表进行直接有效的沟通交流。
- 尊重和遵从项目最终决策者的观点和决定。
客户参与是消除期望差异（即客户对产品的期待与实际开发出的产品不匹配）的唯一途径。然而，仅在项目开始时简单询问一两个客户的需求 2，然后就开始编码，这样的做法显然是不够的。如果开发者仅仅依据客户的初步需求来开发软件，很可能因为客户未能明确表述其真实需求以及开发者缺乏深入了解而导致重新开发。用户表达的“需要”特性并不总能等同于他们在使用新产品完成任务时所需的实际功能。
因此，在收集到用户的意见后，必须对其进行全面分析和整理，直至完全理解，并将你的理解形成文档记录。之后需与用户共同讨论这些需求，这是一个反复迭代且需要投入时间的过程。若不在这个环节下足功夫，导致对预期产品的共识未达成一致，最终可能导致项目返工，甚至推出的产品无法令人满意。
2 需求的来源
软件需求的来源广泛多样，这主要取决于所开发产品的特性和所处的开发环境。在进行需求工程的过程中，必须从不同的用户代表和渠道中全面收集需求，这突显了需求工程的核心在于多方交流与沟通。以下是几个获取软件需求的典型途径：
- 最终用户：直接使用产品或系统的人员，他们的需求通常关注于用户体验、功能易用性、操作流程等方面。
- 业务部门：负责制定战略目标和业务流程的团队，他们提供关于业务规则、工作流、关键性能指标（KPI 3s）等商业需求。
- 项目发起人/赞助者：通常是投资项目的决策者或组织高层，他们关注的是产品的总体价值、成本效益以及与企业战略 4目标的一致性。
- 领域专家/顾问：对于专业性强的系统，需要咨询领域专家以获得特定行业的技术要求、法规约束和最佳实践。
- 市场研究：通过市场调查、竞品分析来了解潜在客户的需求趋势和期望，为产品设计提供方向。
- 历史项目经验：参考以往类似项目的成功经验和失败教训，总结并提炼出适用于新项目的需求。
- 标准和规范：遵循行业标准、法律法规及公司内部规定，确保产品符合相应的合规性要求。
- 技术支持和服务团队：从维护和支持的角度出发，提出对软件可维护性、扩展性以及故障排查等方面的间接需求。
通过多维度地收集和整合这些不同来源的需求信息，才能更准确地定义软件需求规格，并为后续的设计、开发和测试活动奠定坚实的基础。
2.1 直接与潜在用户沟通交流
为了解新软件产品的用户需求，最直接的方法是与潜在用户进行面对面的交谈和探讨。寻找合适的用户代表至关重要，他们应能代表广泛用户群体的观点，并提供真实、全面的需求信息。
2.2 文档记录现有或竞品产品特性
编写文档以描述必须遵循的标准、政府法规或行业规则，这些文档可以作为设计新软件时的重要参考依据。
2.3 系统需求规格说明
对于包含软硬件组件的产品，需要一份高层次的系统需求规格说明书来概述整个产品的核心功能。其中，系统的子集需求会被分配给各个软件子系统中。通过分析系统需求，可以进一步细化出针对软件部分的具体功能需求。
2.4 前系统的问题报告及改进意见
从支持团队和技术服务人员那里获取需求是非常有价值的途径，他们通常会收集到用户在使用现有系统过程中遇到的问题以及对系统改进的想法。
2.5 市场调研和用户问卷调查
开展市场调查和用户问卷有助于从大量潜在用户中获得定量数据。确保选择相关用户并提出能够揭示关键问题的有效问题。
2.6 观察实际工作中的用户行为
通过观察 5当前系统用户以及未来潜在用户的日常工作流程，分析师可以获得宝贵的见解。他们可以通过观察用户与任务环境的工作流程，预测用户在使用当前系统时可能遇到的问题，并分析新的系统如何更有效地支持工作流程。相较于简单询问用户并记录其处理任务步骤的做法，直接观察用户活动更能准确理解用户需求。优秀的分析师还需将观察到的具体活动抽象总结，保证所提炼出的需求具有普遍性，而非仅针对个别用户。此外，他们还能基于观察结果提出改进用户当前业务处理过程的建议。
2.7 用户任务内容分析
通过构建具体的情景,活动序列或用例，可以明确用户利用系统需完成的任务，进而从中提炼出满足用户处理任务所需的必要功能需求。这是使用实例方法的核心所在。
3 用户类别
产品用户在多个方面存在差异，这些差异包括使用频率、应用领域及计算机技能水平、所用功能特性、业务流程、地理位置分布以及访问优先级 6等。基于这些差异，可以将不同的用户划分为若干个用户组别。其中，某些用户类别对项目可能更为关键，需要给予更多关注。
每个用户类别的需求都有其独特性，例如：对于不常使用电脑或经验不足的用户来说，他们更关注系统的易用性，因此界面友好、菜单引导和提示信息尤为重要；而对于每天长时间使用产品的用户，则更关心高效性和便捷操作，他们可能更倾向于使用快捷键、宏命令以及脚本功能。
另外，还有一些非直接或次要用户，他们虽然不是产品的直接使用者，但通过报表或其他应用程序访问产品的数据和服务，同样有自身的特定需求。“曾经是用户，永远是用户。”这样的用户类别也应当被识别并纳入考虑范围。
值得注意的是，用户类别并不局限于人，也可以包括与产品交互的其他应用程序或硬件组件，视它们为附加用户类成员有助于明确产品对外部接口的需求。
在项目早期阶段，确定并详细描述不同用户类是至关重要的，这有利于从各个重要用户类代表中收集全面的需求。例如，一个为65个团体用户开发业务产品的公司，在意识到可将用户细分为6个截然不同的用户类后，成功简化了对未来产品的需求分析。最终，应将这些用户类别及其特征详尽地记录于软件需求规格说明文档中。
4 寻找用户代表
在开发物流管理系统时，需要针对不同类型的用户角色 7设计相应的功能模块，并确保用户代表能在整个软件开发生命周期中提供关键需求：
- 仓库管理员：负责处理日常的货物进出操# 5 作，他们频繁使用系统来跟踪和管理仓库中的包裹、集装箱或其他物流单元。系统应包含实时库存管理功能，允许管理员快速查找并记录货物位置变动，同时支持拣货、上架和出库操作。由于操作频繁且货物种类繁多，系统必须具备高效的自动化处理能力和精准的库存追踪能力。
- 采购员：主要处理供应商 8关系管理和采购请求，他们可能对具体的物流细节了解较少，但需要一个简洁易用的界面来查询供应商目录，提交和确认采购订单。采购员不直接参与物流过程的具体操作，因此系统为他们提供的功能将侧重于订单创建与管理以及与外部供应商的有效沟通。
- 运输调度人员：作为物流流转的重要环节，他们要根据仓库情况及客户要求制定运输计划，安排车辆资源，确保货物按时送达目的地。系统应提供路线规划、车辆调度、装车清单生成等功能，并能够实时更新运输状态，便于跟踪和优化整体运输效率。
- 客户服务人员：用于处理客户的发货请求、查询货物运输进度以及解决物流过程中产生的问题。他们使用的系统模块需包括订单查询、客户反馈处理、异常情况报告等功能，并能生成符合客户需求的物流报表。
对于物流管理系统的项目，在获取用户需求时同样需要精心挑选不同类别的用户代表，如仓库管理员、采购员、运输调度员、客户服务人员等，并确保他们在产品开发的不同阶段都能提供有价值的反馈。尤其在商业软件开发中，如果不能直接接触最终用户，可以通过现有用户群、beta测试群体或者竞争对手产品的用户反馈来收集需求信息。核心用户组应当包括有丰富经验的专业用户以及初级或偶尔使用者，以保证覆盖所有重要的使用场景和需求层次。
开发者直接与实际执行任务的用户进行交流是获得最准确需求的关键；通过过多中间层传递信息可能导致误解和误差。如果有需要引入需求分析专家或其他中介角色来整理和传达用户需求，必须评估这种做法的风险和价值，确保这些代理真正有助于提炼出反映真实业务流程和用户期望的功能需求。尽管找到最合适的用户代表可能耗时耗力，但如果忽视了从最具代表性的用户那里获取一手信息，那么所开发的产品将难以贴近市场实际需求，影响用户体验和项目的成功。
5 产品的代表者
产品代表者在软件开发小组与用户团体之间的沟通协作中扮演了至关重要的角色。他们是实际用户的直接代表，具备应用领域的专业知识、良好的沟通能力以及对新系统潜在价值的深刻理解。他们负责：
- 需求收集与整合：从所代表的特定用户类别中获取第一手的需求信息，并协调解决不同用户群体之间可能出现的需求冲突或不兼容问题。
- 核心联络：作为开发者与用户之间的桥梁，确保开发团队准确理解并响应用户需求，同时将开发进度和决策反馈给用户团体。
- 决策参与：若赋予足够的决策权，产品代表者能够更有效地推动项目进程，他们的决定应反映整个用户类别的共识，而非个人偏好。
- 技术评估与可行性分析：基于其对所在领域和软件技术的理解，产品代表者可以判断哪些功能和技术方案是可行且适用的。
- 维护用户利益平衡：防止只关注自身需求而忽视其他用户的情况发生，确保最终产品的设计满足大多数甚至全部用户的共同需求。
- 激励与支持：优秀的产品代表者不仅传播项目的愿景，还能激发团队的热情，因为他们深知新产品对于改善工作流程和提升效率的意义重大。
通过这种方式组织项目团队和用户参与，能够构建一个结构化且高效的合作模式，从而提高最终软件产品的质量和满意度。然而，要确保产品代表者的成功运作，还需要为他们提供充分的支持和授权，并强调他们在项目中的关键作用。同时，鼓励他们保持开放透明的沟通，不断同其他用户进行交流以获得广泛认可和支持。
5.1 寻求产品代表者
在开发业务软件时，尤其是面向外部客户而非内部使用的项目，寻找并合作产品代表者可能更具挑战性。然而，若与大型公司建立了紧密的合作关系，这些用户通常会乐意甚至要求参与需求获取过程。此时，确保兼顾所有客户群体的需求至关重要，需先识别满足大多数客户的核心需求，然后再针对特定个体和用户类别进行个性化需求补充。
为了避免偏听某些产品代表者的意见而忽视其他代表者，可以采取以下措施：
- 保密协议：尽管签署不泄露商业秘密的协议有助于保护敏感信息，但依然存在风险。可通过这种方式限制产品代表者之间的交流，以防止内部业务流程或未来产品计划的泄露。
- 激励机制：为鼓励外部产品代表者持续提供反馈和贡献，可以考虑提供一些经济激励，例如产品折扣、聘请他们作为顾问参与讨论工作等。
- 专业背景的产品代表者：有时，聘请具有行业经验的专业人士担任全职或兼职的产品代表者是一种有效策略。例如，零售软件公司可能会聘请有丰富经验的零售店经理来全天候参与产品设计；医疗软件公司也可能聘请医生加入团队，以便更准确地了解并传达医疗行业的实际需求。同样，有的公司会直接从其大部分客户中聘请前雇员，这些人既具备深入的专业知识，又对客户组织的策略有深刻理解，能够更好地协助产品研发和市场接受度。
总之，在处理外部产品代表者的过程中，需要综合运用法律手段、激励机制以及挑选合适背景的专业人才等方式，既要保证充分收集和平衡不同用户的需求，又要妥善管理潜在的信息安全风险，最终打造出能够被广泛接受且符合客户需求的优质业务软件。
5.2 产品代表者的期望
将产品代表者的期望和职责明确地编写成文档，对于确保这一角色在项目中的成功发挥至关重要。针对不同产品代表者可能存在的表现差异，可以创建一个具体的期望实例表格，让每个代表根据自身情况填写，并以此作为讨论和确定各自具体责任的基础。
以下是产品代表者可能承担的一系列活动：
- 计划阶段（Planning）
- 确定产品的适用范围与局限性
- 定义与其他系统的外部接口需求
- 规划从现有用户应用程序过渡到新系统的迁移路径
- 需求阶段（Requirement）
- 访问并收集其他用户的详细需求描述
- 提出使用场景脚本和使用实例
- 协调解决多个需求之间的冲突
- 制定功能需求的优先级排序
- 确定质量属性和其他非功能性需求 9
- 参与评估用户界面原型
- 验证和确认阶段（Verification and Validation）
- 审查需求规格文档
- 确立用户接受标准 10
- 根据使用脚本编写测试用例
- 组织并参与beta测试
- 提供或协助准备测试数据集
- 用户帮助阶段（User Aid）
- 编写用户手册和在线帮助文档
- 准备培训材料，包括教学演示内容
- 为同行、潜在客户或最终用户提供产品演示
- 变更管理阶段（Change Management）
- 对缺陷报告进行评估并设置修复优先级
- 对增强功能的请求进行评估及优先级排序
请注意，在不同的项目中，产品代表者可能不会执行以上所有活动，而是根据项目的特性和需求，选择其中的部分活动开展工作。
5.3 多个产品代表者
在开发“物流管理系统”时，物流公司需要从其内部员工和业务伙伴中选取多个产品代表者来反映不同的用户群体需求。项目总负责人需要构建一个产品代表者团队，以便从各个利益相关方收集有效的需求信息。尽管这些产品代表者并非全职参与项目，但他们每周都会投入数小时的时间进行项目研究。
三个业务分析师与四个产品代表者紧密合作，共同完成需求收集、分析工作，并将各种需求转化为文档记录（由于采购部门和合规性管理部门的用户类规模较小且需求有限，因此可以由一位分析师综合处理这两类用户的需求）。在物流管理系统项目中，有四个主要用户类：仓库管理员、运输调度员、客户支持人员以及合规管理人员。
对于像仓库管理员这样人数众多的用户类别，期待单个产品代表者能完全涵盖所有需求是不现实的。因此，在物流公司中，代表仓库管理员用户类的产品代表者组建了一个预备小组，该小组由五个来自公司不同区域或部门的仓库管理员组成。这五位仓库管理员分别从各自所在的团队中收集信息，分析同事们对“物流管理系统”的问题反馈，并为他们的同事提供系统更新情况及项目进度。
这种分层方法能够增加获取需求的用户基数，同时避免了举办大规模需求研讨会 11或进行长时间一对一访谈所产生的大量开销。物流管理系统的仓库管理员产品代表者始终致力于达成共识，但在意见分歧时，他们愿意主动作出必要的决策以确保项目的持续推进，而不是陷入僵局无法向前。
6 谁做出决策
在软件开发项目中，尤其是在大型且涉及多个利益相关者的项目中，需求决策权的归属是一个至关重要的问题。如上面物流管理系统中遇到的项目经理面临来自四面八方的不同领导层的需求和决策，导致了混淆、冲突和项目进展受阻。
在收集到众多需求时，必须有明确的角色来解决冲突、澄清模糊点并协调不一致之处。项目的早期阶段应确定谁有权且有责任对需求问题做出最终决策。若决策者角色不清晰或授权人员无法或不愿做决定，决策的责任可能会转移到开发者身上，但这不是一个理想的解决方案，因为开发者通常不具备全面的业务视角和信息来做此类决策。
在不同的情况下，需要有不同的策略来处理需求决策问题：
- 个体用户需求冲突：产品代表者可以作为决策者，负责解决他们所代表的用户群体间的冲突需求。
- 不同用户类别的需求矛盾：基于产品的业务目标和潜在客户群体的价值分析，确定哪个用户类别的需求优先级 12更高。
- 多公司客户定制化要求：以项目业务目标为指导，优先满足核心客户的特定需求，而其他次要客户需求可能要推迟到后续版本实现。
- 客户经理与实际用户需求不符：确保客户经理提出的非直接使用产品的用户需求与详细的功能性规格说明保持一致，避免强迫开发者对争议性需求做出判断。
- 开发者观点与客户需求冲突：通常应当尊重客户的需求，但需避免盲目服从，应理解并评估客户意见是否合理，并基于项目实际情况作出决策。
- 市场部门与开发者愿景冲突：市场需求通常占据重要地位，但不应忽视其合理性和成本效益。应避免市场部门一味迁就客户需求或提供过少信息让开发者自行定义产品及编写需求文档 13的情况。
总之，没有放之四海而皆准的答案，关键在于项目开始前确立一个清晰的需求决策流程，以防止因决策不明或反复更改导致项目停滞不前。同时，团队领导者必须灵活应对各种复杂情况，根据项目特点、客户需求以及业务目标作出明智且及时的决策。
7 实践:
在实际工作环境中，听取客户需求的方法与图7-1中所示的流程紧密相关。首先，识别并分析交流联系中存在的问题，例如信息传递不准确、沟通渠道不畅或反馈滞后等。为确保最短且有效的交流途径，可以考虑采用直接用户访谈 14、问卷调查、定期会议讨论或使用在线协作工具等方式收集用户需求。
接下来，根据项目特点和业务场景确定不同的用户类型，并选择合适的产品代表者来代表每个用户类。参考表7-2所列出的产品代表者的可能活动，明确期望产品代表者在项目中承担的具体职责，如需求收集、需求分析、验证确认以及用户帮助等方面的工作。
与选定的产品代表者及其所在部门经理进行深入交流，共同探讨如何更好地协调资源，优化合作模式，以促进项目开发进程。
同时，评估当前在项目中负责解决需求问题和冲突解决方案的决策者的绩效表现。分析他们在哪些地方出现了失误，是否具备有效决策所需的洞察力、权威性和执行力。如果现有决策者不适合这一角色，那么在开发者被迫介入之前，应迅速决定由谁来接手需求决策工作，并提出改进协调机制的建议。
通过上述步骤，您可以逐步优化用户需求获取过程，明确各个用户类别的代表性意见，并确保在项目中有一个清晰、高效的决策层级结构，从而提高整个项目的成功概率。