作为项目负责人，我们要在项目开展之前做足充分的可行性分析

作为项目负责人，我们要在项目开展之前做足充分的可行性分析，这几个问题必须思考清楚：

• 我们的用户对象在哪里？他们是一个怎么样的画像群体？
• 我们的商业模式是什么？如何实现商业变现？
• 整个市场的竞争环境如何？我们的产品差异点在哪里？

只有明确了我们的盈利模式，反向推导出我们目前这个阶段要做的事情是什么，才有利于保持项目开展过程中目标的一致性。

项目开展前期

企业内部通常都会出现资源紧缺的问题，每个部门、每个人都在争取项目资源，因此一般来说在项目前期遇到的最大困难就是项目推动难的问题。

解决这个问题的办法可以从这3个角度出发：

1. 逻辑和数据层面

人和人之间之所以容易出现矛盾和不解，主要是因为信息不对称的问题。

当我们在跟产品经理沟通项目的时候，一定要跟对方交代清楚项目的业务背景：可行性分析结果（市场分析结果、用户调研结果、商业模式）、产品规划（产品定位、产品蓝图、用户群体）、项目目的和目标等。以此从逻辑层面去告诉对方项目的业务合理性。

每个产品经理和技术人员手头上可能都手握多个项目，因此他们是非常关注每个项目能带来的业务价值。因此我们在沟通项目的时候，需要提前评估出该项目能带来的数据化业务价值。

如果这是一个从0到1的新项目，我们需要结合市场情况去预估大概的业务数据；如果这是一个成熟的老项目，我们需要通过历史数据去预估上线后的数据。

清晰的业务背景和明确的数据化业务价值是解决项目推动难最得力的方法。

2. 管理层层面

当你已经尝试了逻辑和数据层面的沟通方式后，仍旧无法说服对方，那此时急需要上升到上级层面，让上级帮你去进行部门间的沟通。当然该办法的前提是你必须把整体的业务背景和目标与领导传达清楚，他才有底气跨部门帮你进行沟通。

3. 降维打击的MVP方案

当我们在数据和逻辑层面尽力了，管理层也沟通了，可是客观情况是项目资源的确紧缺，或者是CEO有更看重的项目，此时我们看似无计可施了。

别着急，我们来个降维打击！

这时候项目owner需要梳理出整个项目的板块结构，将项目进行拆解，通过MVP（最小可行产品，Minimum Viable Product）方式，退而求其次选择次优的方案，将较长的开发周期缩短成若干个较短的开发周期，实现快速上线、快速验证和快速迭代。

对于用户体验而言，各板块的影响力如下：

产品功能>交互设计>视觉设计

因此在建设产品时，需要先做加法，通过充分地讨论，穷举所有需求和可能性；然后再做减法，对项目进行拆解，重新调整项目需求的重要层级。

项目开发阶段

当项目终于如我们所愿推动起来后，你以为就高枕无忧了么？不，还有更多问题等着你去解决！

在项目启动后，接下来是项目的需求排期、产品的设计方案、技术的设计方案、项目的开发和跟进、项目的上线前测试和预发等，基本上每个阶段都需要项目owner参与。

在这个阶段中，会出现很多无法预知的问题，影响项目的正常开展，而问题的根源主要有如下4个方面。

1. 业务逻辑完整性问题

我们在提出业务需求时，可能会在某些细节层面有所缺漏，没有把需求的整理链路想清楚，这时候就需要重新去完善需求细节。

2. 数据逻辑完整性问题

大多数企业都会有自己的数据后台，而搭建数据后台的工程量是庞大的。搭建期间会遇到非常多棘手的问题，比如数据来源不全面和不可靠、数据清洗不干净、数据埋点缺漏、数据统计不精准等。这时候项目owner就需要跟数据部门同事一起去进行数据来源统计跟踪、数据清洗方式跟踪、数据统计方式跟踪等，找出问题的根源并解决掉它们。

3. 产品实现合理性问题

在跟技术进行技术方案设计确认的过程中，技术可能会反馈部分功能无法实现的问题。这时候需要项目owner和技术方同时进行技术调研，确认问题的本质是什么：

• 开发成本高，需要较长开发周期。
• 技术人员开发能力不足以担任该开发工作。

此时作为项目owner，需要了解该问题无法解决的本质是技术人员能力不足还是市场成熟度不足的，千万不能因为技术说无法实现，项目owner就直接妥协。

作为项目owner要明白一个原则：现在没什么事情是解决不了的，只是成本高低的考量问题。如果的确在现阶段无法以最优方式解决，则需要调整开发方式，选择次优的技术方案；或者是跨部门进行调研，了解其他部门是否已有相关的功能组件可直接使用，通过跨部门整合资源降低开发成本，节省开发时间。

当我们在进行项目评审的时候，一定要将相关的人员集合到位，包括项目owner、产品经理、开发人员、测试人员、UI等，否则前期的点对点沟通极容易出现信息不对称的问题，导致后期出现诸多的意外。

4. 测试和预发问题

项目在上线前，会经过测试和预发阶段。一般测试阶段是测试人员介入，在预发阶段才交由给需求方介入。以我个人的经验建议，项目owner在测试阶段就该介入。