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