项目管理：项目owner的日与夜

诺将军 2023-07-23 03:53:38

项目核心

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

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

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

项目开展前期

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

解决这个问题的办法可以从这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在测试阶段就该介入。

为了项目的快速上线，往往预发阶段非常的短暂。假若是产品bug的问题，技术倒愿意快速解决；假若是产品功能完整性与原需求不匹配，技术可能会以功能不紧急为由拖延至下期开发，否则项目owner将只能接受项目延期上线的结果。我

曾经遇到过在跟技术的前期沟通阶段不存在问题，可到了测试阶段才发现双方理解有误，因此项目owner最好是测试阶段介入，了解产品功能开发完整性情况，确认整体情况是否与需求保持一致。而在预发阶段，更多地是对细节进行调整。

项目线上阶段

项目上线后，我们是否就是坐等数据上涨呢？答案是否定的。理想归理想，产品的市场验证才正式开始。

1. 项目效果不如预期

如果前期没有做好用户调研，以为小众的用户需求就是大众的用户需求，或者是遇见“幸存者偏差”，错误选择调研样本，就会出现上线的产品功能并不能很好地满足用户的真正需求。

也有可能由于开发时间准备不充分、需求排期不合理等，导致实现的技术功能不符合需求方预期。因此项目owner就需要在项目开发、测试和预发过程中，与产品和技术保持紧密地沟通。

2. 产品bug

技术代码出错、其他项目的上线对本项目的影响、测试范围不完善等都有可能产生bug。我就曾在产品上线后，遇到过如下问题：

其他项目上线后，导致我的产品回退。（是不是觉得很无辜~）
浏览器兼容性测试范围不全，导致部分浏览器打开我们的网页出错。

我们需要搭建系统预警机制，实现系统自动报警，当产品出现某些问题的时候，系统自动推送信息给相关的人员，以最快的速度解决问题，最大限度地降低产品bug的负面影响。同时我们作为项目owner，也需要频繁地以一个用户的角度去体验产品，发现产品的链路问题，以及时常思考产品的可优化空间。只有日积月累的体验产品，才能真正的了解用户的诉求。