大公司往往指成立时间比较久、业务线/部门繁杂、员工数众多的企业；和敏捷的勇于探索商业模式的公司相比，在大公司里想要从某一业务线发起跨部门甚至全公司范围内的项目，从立项到推动一路困难重重。

  作为一名产品经理，通常被老板认为是问题终结者，所谓「问题到我为止」；那遇到跨部门项目牵扯广泛的需求，尤其是第一次牵头立项时，可以怎么做呢？

  我以主题“APP体验提升项目”为例，分享立项前全盘分析的思路，权作抛砖引玉，以供参考。

  做跨部门项目和自己业务线做需求截然不同，除了事情大小差异之外，更大的差别在自己产研团队的需求，自己是产品经理，自己说了算。

  任务的发起人层级，决定了项目的实质影响区域；如果项目影响区域超过了发起人的管辖区块，则需要仔细考虑如何把影响力扩散出去。

  以APP体验提升来举例，可能是是产品侧这个一级部门发起的任务，那么至少在同一个一级部门下，无论是开会沟通还是寻求帮助，都会比较顺利；但体验提升除了产品本身的改进迭代之外，必然是需要业务侧和运营侧共同支持的，那如何能拿到他们的支持呢？

  除此之外，一级部门老板发起的任务，可能最后是落在一个三级部门头上在重点落地，那么其他兄弟部门只有配合义务，如何能带动他们的主观能动性？

  抛开人的问题之后，这个事情还有无另外的困难点：比如工作量巨大，现有人力没办法支持，如何申请HC？比如老板诉求紧迫，时间比较短如何将项目拆分排列优先级并行处理？

  项目发起的大概背景在老板布置任务时趁机了解，需要从老板口中明确初步的「范围-问题-目标」，你需要知道：

  这些问题在老板布置任务时是不可能了解地清清楚楚的，不然老板也没必要让你来做了；很可能老板只是想到了问题的核心要点，至于这个事能做到多大、产生多大的效果，这些都需要你调研清楚反复反馈后才能得到进一步的结论。

  以APP产品体验提升为例，可能项目的发起导火索是因为大老板/用户反馈的体验问题日渐频繁；在经过自己翔实的调研之后发现，过去公司快速地增长掩盖了很多问题，当下核心产品逐渐成熟，体验问题解决带来APP整体体验提升带来的ROI比日常业绩提升还高时，你就明白这件事很有价值，能推下去。

  通过用户行为数据、用户反馈和典型用户深度沟通，去了解目前的产品体验痛点和用户口碑现状，最好能落实在商业经济价值指标上，如对拉新/促活的影响，对转化提升的影响。

  对产品调研主要是深度走查和竞品分析，走查是看核心流程和分支流程有无明细的断点、卡点，有无不流畅、不符合用户习惯的流程设计，以及信息展示是否足够清晰、交互设计是否高效且友好；竞品分析主要是查漏补缺、扬长避短，尤其是核心流程，三人行必有我师。

  前期准备是做到位了，但就像前面说的一样，跨部门项目和自己产研团队做需求最大的不同是：你的需求你说了算，老板发起的任务你说了不算。

  调研完一圈之后，你对事情的理解从一开始模糊只知道个大概，到心中有数，明晰：发现了什么样的问题、造成了什么影响、解决后要达成什么目标。

  结合你的调研结果，老板也会通过和你的沟通中来修正自己一开始没有想清楚的地方；所以此阶段和老板共同很重要，沟通之后你和你的老板都相互确认了我们要做什么事，要拿到什么样的结果。

  要做什么事确认清楚之后，很重要的就是表达自己打算怎么做，按照什么样的节奏把项目拆分，先做什么、再做什么、最后做什么，以及各个阶段对应的产出物。

  这个阶段和老板沟通主要是确认两点，一个是时间节奏是不是满足老板预期，毕竟任务是他发起的，他知道更多信息能决策时间点是否ok；另一个是把控具体的方案，按照他的信息了解和资源范围，评估你的方案是不是合理，成功的可能性有多大，要不要调整。

  这次的确认很重要，一方面你有了老板认可的阶段性产出物来表明自己的工作产出；另一方面这个方案是老板认可的，即使后面结果不太理想，自己也不会背大锅。

  凭空增加了许多活，现在的职责还不丢，算上加班也做不完，那必然是需要老板提供额外的资源支持。

  事都还没做呢就直接要人，多少显得能力不够，底气不足；可以在汇报的时候明白准确地提出困难点，而不直接说个人需要增加多少人手。

  在项目真正开始后，取得了阶段性进展，老板看到确认事情在朝着预期的方向在跑，此时资源增加就是水到渠成的事情。

  小结：在做自己无法决策的大项目之前，需要先：想清楚、多调研、常确认，才能让自己负责的项目更容易顺顺当当结项，让自己的努力付出收到对应的回报。