【首发于公众号JohnnyHCM，坚持原创手打，腾讯朱雀大模型检测疑似AI含量为0% 】
如果开吐槽甲方大会，我估计“需求挤牙膏”能进槽点前十。
“该提需求的时候提不出来，问一点、说一点；系统临上线，又没完没了了，就里也不是他们想要，那里还有情况没考虑到”。
返工和延期，往往就是前期需求工作没搞好的恶果，对甲乙双方都顶级折磨。
但说句公道话，甲方要是有能力竹筒倒豆子般把需求事无巨细说得一清二楚，何不直接告诉AI让代码直出？
挤牙膏的原因和解法
在需求调研中往往有6个缺乏，专业的乙方应该有对策和准备：
缺乏讨论锚点
要讨论的流程那么长，如果想到哪儿就跳跃到哪儿，定有需求被略过；讨论系统设计全在纸上，不能身临其境，必有细节想象不到。而到了上线前，锚点有了，靶子清晰了，加上心态也急了、压力也大了，火力输出就集中了。
这就要求乙方在谈业务方案时，能尽早提供模版文档、标杆实践和提问清单，让讨论有条有理、有针对性；在谈功能设计的时候，能尽早拿出原型系统让用户体验。项目管理上，当然应该一早对需求变更约法三章，但谁都怕到时候没人认账。
缺乏全面视野
调研受访者可能对业务全局了解有限，只顾得上门前自家雪，看不看到跨组织、跨职能的流程衔接和数据拉通，而这些正是系统的妙用；可能对数字化价值理解有限，聊来聊去都是自己那点鸡毛蒜皮，看不到更宏观的价值潜力：搞不懂数据为什么能驱动决策，看不到系统能如何加强合规风控、创新落地和协作沟通。
这就要求乙方在需求调研阶段要找对人、找够人，也要求乙方从始至终以业务价值为导向，不断引导、不断洗脑。
缺乏业务标准
有的大集团管理不统一，有的小公司过度“伪精细”。特殊处理太多，谁都想不全所有情况、举不穷所有例外；很多规则全在别人脑子里，不得已只好先含糊其辞，说个大概。
我一直相信，这种情况业务必须先行改变，系统固化只是业务标准化的契机，但系统其实不太可能真的把业务给“倒逼”。
不过我过去有个误区：初步评估大概率做不上系统的业务，就不去扯这块麻纱了。但结果就是，很多业务问题也就不了了之，规则到底多复杂、为什么会这么复杂，始终都无人知。这种情况越多，越会限制系统发挥价值。虽然说甲方付的是系统交付的钱就不该奢望乙方还能干业务变革的管理咨询的活，但为了最终的价值交付顾问应该要更有追求。
缺乏踩坑经验
不吃一堑，怎长一智？哪怕是以前用过系统的人，用得太顺利的也想不到很多细节需求。甲方只说了“需要修一条A到B的公路”，是因为在他们的潜意识里路标、路牌、加油站默认就应该长在路边。他们也想不到：权限还可能控不住，报表还可能跑不出，上线人数一多页面还可能一直在载入。
这确实对乙方的产品成熟度和服务专业度有要求。比如系统后台管理、运维功能的需求和非功能性需求，甲方顺着业务流程思考是很难想得到的，需要乙方想得更多更全，并与甲方逐一确认。
比说不出更糟的情况是，根本就懒得说，可能是因为：
缺乏变革动力
不是所有人都对新系统感兴趣的，不是所有人支持新系统建设的，不是所有人都欢迎新系统带来的变化的。动力不足还好，更可怕的是刻意阻挠，早期先推三阻四，待到大限将至前再杀你个措手不及。
这是变革管理、利益相关人管理的话题，超出了普通系统实施顾问的力所能及。不过这也是很多乙方老江湖的功力所在。乙方顾问至少应该更具同理心，尝试在价值、愿景上多做些引导、在沟通上改变策略和技巧。
缺乏专业信任
假如甲方觉得跟你说了你也不明白，自然就不想和你多说了。项目之初，甲方对乙方专业度的信任是极难建立，却又极其脆弱的。当你听到甲方吐槽“乙方顾问还没我用系统用得熟”，你就知道这个项目可能会是双输。
这就要求乙方真有两把刷子，无论是法律和管理知识、业务实务、系统功能、技术应用还是项目经验。这也要求乙方会快速建立信任关系，但这几乎是我从业前十年的最大难题，也是我一直在写公众号的原因之一，这个值得单开一篇再叙。
挤牙膏的学问
一不小心我就情不自禁水银泻地般泄了这么多，其实我想引出的是：
完整的需求从来得来不易，“挤牙膏”常常在所难免。但早挤出来和晚挤出来可是天差地别的。那么要怎么挤，就是科学与艺术了。
这门学问就叫需求诱导（Requirement Elicitation），他属于商业分析（Business Analysis）或者需求管理/工程（Requirements Management/Engineering）的专业范畴。
这里我把Elicitation这个词翻译成“诱导”，你琢磨琢磨。
剑桥字典中这个词的常用用法，一是老师进行的“启发式”、“引导式”的教学；二是情报人员“套出”情报、执法人员“诱导出”供述。
ISO/IEEE 29148对需求诱导的定义是“使用原型、结构化调研等系统性的方法，主动识别和记录客户和最终用户的需要”。
咱们做需求发掘和分析的目的，并不只是为了把功能搞上线，而是能真正交付业务价值、让业务端更满意。
为此，咱们需要通过“诱导”获取表象之下的更多的信息，包括展开的细节、背后的缘由等等，才能更好决策需求优先级、实现方案和沟通方法。
我认为需求诱导有三个关键：
一是前期要做好充分准备，与利益相关者建立信任关系。
二是要能熟练地使用“诱导”的沟通和访谈技巧。
三是要具备专业敏感度。
在Phillip A. Laplante的《Requirements Engineering for Software and Systems》一书中，介绍了需求诱导的20多种组织形式，和它们适用情境，除了访谈和问卷，还包括：
头脑风暴 Brainstorming
设计师跟学 Designer as apprentice
联合应用开发（JAD） Joint application development
逆向工程 Reverse engineering逆向工程
卡片分类 Card sorting
用例 Use cases
用户故事 User stories
其中一些源自敏捷开发的方法。
在Frank Stopa的《The Human Skills》一书中，则总结了16种诱导谈话技巧，包括：
避免提问
虚假陈述
怀疑、挑衅、争论
奉承、幽默
条件交换
装天真
沉默
当然还是需要多练。
乙方顾问还需要有足够的专业敏感度，才能想得更周全，才能知道还需要获取哪些信息、应该将探讨引导至什么方向。
比如聊常规的入职流程，就会自然地开始考虑离职员工重入职、实习生入职、实习生转正入职、派遣转正式、退休返聘等情况会有什么不同。又比如聊到某个字段的数据维护，会自然地开始考虑未来维护的角色权限、流程、需要批量增删查改的场景。
这种敏感度主要源于落地实践的积累和复盘，同时也需要持续的学习充电。
前前后后的环节
一段糟糕的甲乙方关系，往往不是单方面的问题。
作为甲方，我们在正式的需求梳理前，应该提前整理给乙方输入材料，包括：
现有的规章制度，并重新审视与实务的差异及可优化的空间；
各种表单、台账、报表表样，并评估设计合理性和现有数据质量；
现有系统的账号和文档，并回顾现有系统的缺陷和不足；
当前工作中的痛点、断点、堵点，并量化这些瓶颈的耗时和成本。
在认识和心态上也要有所准备：
宣贯数字化愿景、目标和潜在业务价值，保证自上而下统一认识、看到未来。
了解系统建设的方法、周期和任务，理解需求阶段多花功夫，其实能避免后续多得多的时间和精力被浪费。
准备好迎接变化、主动变化的开发心态，聚焦业务价值，反思业务现状，对未来的解决方案不拘于过往，也不凭空幻想、不过分纠结于细节。
学习如何用数据说话、借场景说话、更有逻辑地说话，让与技术人员的沟通更顺畅。
挤完牙膏后，需求后续还应被验证和确认（Validation and Verification），通过评审、检查等方式，保证需求正确表达了利益相关人的意图、描述完整、编写符合要求。为了保证需求符合“完整性”的要求，应检查：
是否所有类别的用户都已经反馈了需求；
是否已确定了所有数据元的源头和用途；
是否已包含相关功能，比如：报表、用户管理、批量修改、安全、打印、日志等等；
是否已经考虑非功能性需求；
是否符合相关法律法规、行业要求。
【欢迎关注公众号JohnnyHCM】