（一）基本挑战概述
互联网公司的典型业务场景下，一个需求会涉及到运营、产品、前端、后端、数据、测试等不同部门的配合，一个需求正常情况下都需要拆解成多个模块，而其中的一些模块可能还涉及到其他模块的功能，导致需求完成的子目标比预期的多很多，需求的管理工作就会变得特别困难。
例如，产品根据运营同学的需要，设计了某款产品，能够看到运营指标的变化情况，大家在评审完需求后，发现了如下几个方面的问题：
一：前端支持，当前公司有了固定的组件，但并不能完全满足展示需求，出于长远角度考虑，应该将组件中加入新的功能，以支持当前需求，但排期很长；
二：后端支持，后端对于页面的展现逻辑提出了质疑，部分场景下展示数据过多或者组合逻辑太复杂，会导致潜在的性能问题，希望修改设计稿；
三：数据支持，数据的常规需求是支持T-1粒度的数据统计，但运营同学希望看到实时的变化，在架构的设计和维护复杂性上骤然增加了很多，需要增加对于实时数据统计的预研工作，排期要很久；
四：测试支持，测试同学由于公司集群的技术架构，不能够伪造数据来验证逻辑准确性，需要等其他部门完成后才能投入测试，工期一下子从并行变成了串行；
五：产品支持，某天部门领导参与了会议，发现需求稿存在很多问题，不愿意浪费时间，于是需求评审会议从一个变成了多个，总是定不下方案。
以上种种问题，就成为了大规模需求协作中难以绕过的挑战项目。
（二）挑战产生的基本原因
虽然每个公司都会有自己的需求管理平台，能够很好的跟踪每个需求的进展情况，但是对于每个人的时间分配，就缺乏相应的工作来支持了。在这种情况下，就会产生如下各种的冲突情景：
一：需求多且复杂，不同团队管理不同的项目空间，而分配到每个人的需求分散到了各个不同的项目空间中，难以窥探进度全貌；
二：管理方式不同，不同团队或者部门，都有自己的开发标准与需求管理方式，标准不同，进度就不统一，导致相互之间的依赖情况难以解决，延期就变得很自然；
三：需求优先级不同，虽然每个需求之间有大致的优先级，但具体到每个人上，需求的优先级就发生了变化，如果高级别领导提出了一些需求，对应的一些项目就要延期，增加了整体的排期难度；
四：需求数量难以度量：我们一直在做需求，但很难知道我们接下来到底有多少需求，有很多团队内部的优化工作因此而延期，系统变得越来越臃肿，士气就产生了巨大的影响。
（三）解决挑战的基本思路
没有那种方式可以一劳永逸，那么我们就需要尽可能让挑战变得可控，具体有如下几种指导思路：
一：问题及时可见：我们需要面对的挑战，存在很多隐藏问题，是导致延期的重要因素，因此及时的把这些问题提出来，就非常重要。但这种提出方式，并不是把问题放到线上就可以了，需要每个遇到问题的人去主动推进，为我们的重要决策提供很重要的参考依据。
二：过程相对可控：面对需求的过程中，总要有长期方案和短期方案的PK，短期大家都有时间成本，长期会导致上线时间不可控，因此如何对齐进度，是否需要存在中间过渡状态，需要每个人的参与、跟踪和同步。
三：问题主因回溯：每一次的会议都会有很多冲突，那么导致剧烈冲突的主要原因是什么，需要在会议之后进行总结讨论，如果各方存在自己的方案，能够对应不同的情况，那么就应该把这些方案达成共识，后续在遇到类似的问题的时候，就不会陷入重复的讨论。
不论哪种思路，需求管理都不会一直很难，每个人出于自身角度出发，都会多少去推动它的改善，最好能够有小范围内的聊一聊，有时候私底下说事情，会讲很多台面上听不到的东西，这对于你理解需求全貌，很有帮助。毕竟每个人都在走向Leader的路线上，纯技术的Leader，可太难了。
