“业主的装修风格”——谈软件开发项目管理中关于“需求”的四个常见问题.

业主（产品经理）请了装修公司做装修。拍着工长（项目经理/Scrum Master）的肩膀说：按照样板间装修，我要现代简约风格。不要复杂的装饰。

工长听了以后给装修师傅（研发）安排任务：以现代简约风格，按照公司样板间施工。有问题和我说。 

于是经验丰富的装修师傅开始了热火朝天的装修工作。活干到一半，业主急着来看房，到了现场气急败坏地和工长说提了四个问题：

• “为什么没做吊顶？现代简约不代表没有吊顶。”

• “没有预留洗碗机空间，橱柜需要拆了重做”

• “我打电话和装修师傅说了，衣柜我要的浅色调是原木色，为什么做成了胡桃木色？”

• “我要的方案有没有图纸？”

从这个故事（纠纷）上看，这个装修工程（软件开发项目）存在四个问题：

• 需求模糊。“现代简约”风格的定义是什么？这个风格包括什么，不包括什么？业主没有提出具体的需求说明，只停留在原型概念的层面。工长也没有和业主做充分的需求拆解与理解。导致了需求模糊和不确定性性。

• 需求变更。在装修过程中，业主提出了预留洗碗机空间的新需求。而非在装修开始前。这将导致装修师傅工作（工时）的浪费、橱柜板材的浪费，和交付时间的延误。

• 需求理解。业主的需求是浅色调。那么浅色调的定义、规格是什么？“原木色”的色调是多少？这些信息并没有和装修师傅澄清，造成了需求理解的偏差。另一个问题是，这个需求是业主直接向装修师傅提出的，而非工长。而装修师傅也没有把这个需求传递给工长，而是自己决定了工作任务。

• 信息同步。业主的想法，工长、装修师傅是否都清楚？有没有装修图纸或工作清单？另外，业主对衣柜颜色不清晰的主观需求只传递给了装修师傅，而工长对此一无所知。

以上四点其也是软件项目开发过程中的常见问题。

首先，软件开发的目的是通过创造软件产品来实现产品价值，那么弄清楚产品要实现什么价值一定是软件开发的前提。这就离不开需求，即：产品的用户需求、商业需求、功能性需求等。后者往往是产品团队向开发团队传递的重要信息。 

关于需求的常见问题有如下四类：需求模糊、需求变更、需求理解，和信息同步。

需求模糊

关于需求的定义我理解一定是个精雕细琢的工作。产品的需求可以是一句话，一段文字说明，或是一篇产品需求文档（PRD）。 

举例说明。产品经理要做一个计算器，他的用户故事（User story）是：“作为一个计算器，我需要提供复杂科学计算功能，以便专业人士使用”。这是一个典型的模糊需求，接到需求后项目和研发的问题可能是：

• 复杂科学计算功能的范围？

• 功能的开发优先级？先开发什么功能？主要功能和次要功能分别是什么？

• 产品性能的要求？如运算速度，数据指标（指数、精度），功耗？

• 产品服务于什么类型的专业人士使用？

如果在这个需求的基础上，项目经理/Scrum master开始拆解需求、安排研发任务，研发启动开发。或者按照市场上的产品对标开发，甚至按照自己的理解去补充需求，后续一定会经历一个痛苦的需求理解、澄清，和修改的漫长过程。项目的周期也注定延误。

 

需求变更

在敏捷开发场景下，研发往往按照计划会（Sprint planning）制定的任务、方案去开发。在这个过程中如果需求方或产品经理突然提出方案要讨论需求，产生了需求变更，那么无论是产品需求侧的修改，或是产品需求与技术实现方案之间的妥协，都会导致沟通混乱、资源浪费和开发进度延误等问题。 

甚至产品经理直接找到技术负责人和研发讨论需求变更，然后研发开始了对变更的开发。甚至项目经理/Scrum Master几天以后才发现自己对变更全然不知，最终可能导致由于对优先级的破坏，和变更需求未充分评估而导致的项目延误和二次开发。 

需求理解

如果产品经理想要篮球，给大家在纸上画了个“球”。研发看过以后，经过两周的努力工作开发出了一个足球。而项目经理/Scrum Master到最后一天才发现大家不仅不清楚篮球的颜色、性能，和风格，甚至把开发篮球的需求理解成了开发足球。 

实际项目开发中的需求理解问题虽然没有可笑，但各方对需求的理解往往存在偏差。

信息同步

如果开发仅仅依据沟通群聊的聊天记录，或一次沟通会，甚至是单向沟通，没有任何需求文档，性能要求，和验收标准。

项目中的每一方都是一个信息孤岛，项目开发的结果也将是灾难性的。 

关于信息的透明与同步，共享文档的必要性尤为重要。如：各方达成的共识、会议结论、共享的信息等可以高效、简单地解决需求理解不同步的问题。解决问题的前提是信息透明，理解一致，和对各相关方的同步和共享。

需求类问题是软件项目开发中常见的前置问题，它影响了从项目启动前、计划、开发、测试、和交付的整条链路。特别是在前期起到了决定性作用。

这类问题的解决方案，离不开软件项目开发团队中各方的共同参与。

• 产品经理。在明确的用户价值基础上，制定详细的产品说明文档或其他形式的说明。向项目经理/Scrum Master、研发充分澄清产品价值、需求，和验收标准。

• 项目经理/Scrum Master。与产品经理充分沟通，理解产品需求文档后，安排研发任务和优先级，识别依赖方和潜在风险。并保证在敏捷开发的每个sprint中锁定需求不做需求变更。

• 研发。理解需求，评估开发方案。安排资源对接任务。

• 信息同步。关于信息共享的工具，包括并不限于：产品需求文档、开发任务（backlog）及优先级文档、项目进度跟踪工具、共享文档（confluence/wiki/知识库等）都是关于信息、进度的高效管理工具。

软件开发项目管理中关于需求的问题，如同装修项目，其中的任任何一方对需求的准确性和完整性，对需求变更的管控，和对需求的一致性理解，以及信息都决定了项目的成败。 

《人月神话》中关于陷入焦油坑之中的巨型猛兽的比喻，说明了关于复杂度、需求模糊，和沟通混乱导致的项目失控的典型场景。没有清晰的需求和沟通管理，再强大的猛兽也无法避免陷入泥潭的结局。 

软件开发工作中常常提到的“坑”，也许就是书中提到的“tar pit”（焦油坑）。