项目经理分享的心得体会：项目中的一点心得体会系列之一

小君 2023-02-01 08:19:46 311

项目经理分享的心得体会：项目中的一点心得体会系列之一1.4、简单即是美：通过多个业务产品验证、业务数据，稍微复杂的业务流程或者玩法，印度用户是玩不转的。比如说，大转盘这个业务，印度用户只需要点一下就能有可能领到一个奖品，它的业务数据特别好，后来我们给它加了一个每日签到送玩大转盘权益的功能，并进行实验对比，最终对比数据发现，有签到功能的实验数据指标反而下降了。神奇的一个国度。1.3、需求去留：较重要、较紧急的项目，务必要理清产品业务的主流程，一期保障主流程跑通，其它特殊需求分期迭代。对于复杂项目建议遵循”奥卡姆剃刀定理“-简化流程，遵循“简单与高效”的法则、理念和意识。主动和产品进行沟通，将复杂的项目，一起拆分为可快速落地的几期。买房子还可以首付分期的，是吧。举例：2019年中，裂变产品要上一个大奖团项目，一位产品同学将产品设计的很复杂，以至于需求初步评审时，全场同学没都没听懂，后面陆续产品和技术需求讨论会议有5 场，耗时差不多一个月，导

“ 查理.芒格的多元思维模型大概有100种，能够从多个角度解析问题，拥有了看清生活本质和目标的非凡洞察力。”

本文将从项目的初期、中期、后期三个时期进行讲解，讨论每个阶段需要关注的一些事项。内容核心：沟通多元思维。多沟通，拉平认知，是解决运营、产品、技术之间‘信息孤岛’的有效方式。多元思考，不仅从技术角度考虑问题，还要从运营、产品角度尝试着考虑问题，技术做最后的兜底。查理.芒格的多元思维模型大概有100种，能够从多个角度解析问题，拥有了看清生活本质和目标的非凡洞察力。文中提到的公司为做印度市场的某跨境电商公司，2019年曾做到印度电商第二。

—

需求讨论

项目经理分享的心得体会：项目中的一点心得体会系列之一(1)

1.1、业务对接：一般情况下开发不宜直接对接运营(业务方)，大部分情况下运营和开发对同一个问题的切入点和认知不在同一个频道上，知识背景差异导致同一句话理解上偏差很大。在和业务方沟通时，尽量从非技术角度沟通，尽量少用技术专业术语，多从生活中的普式例子进行举例讲解。

1.2、产品跟进：大部分情况下，产品同学对技术有一定的理解，能够将业务需求转化为一个相对完善的产品。但是需求中的每个点的技术实现复杂度，需要开发同学和产品同学多对焦，功能点换一种方式可能会极大降低复杂度，缩短开发周期。一切出发点：梳理清晰产品需求，完善产品业务流程。否则，较大的概率我们收到的需求prd将会是几行文字，或者几个图片，一切全靠技术同学去猜，存在太多不确定，轻会导致项目延期，重则上线即触发故障，为后续的迭代埋下太多坑。

1.3、需求去留：较重要、较紧急的项目，务必要理清产品业务的主流程，一期保障主流程跑通，其它特殊需求分期迭代。对于复杂项目建议遵循”奥卡姆剃刀定理“-简化流程，遵循“简单与高效”的法则、理念和意识。主动和产品进行沟通，将复杂的项目，一起拆分为可快速落地的几期。买房子还可以首付分期的，是吧。举例：2019年中，裂变产品要上一个大奖团项目，一位产品同学将产品设计的很复杂，以至于需求初步评审时，全场同学没都没听懂，后面陆续产品和技术需求讨论会议有5 场，耗时差不多一个月，导致技术迟迟无法跟进介入，或者说技术实现上的成本很高，稳定性很差。最终，在和产品总监一起努力下，重新对产品业务流程进行了设计，去繁存简，最后只花费了一周左右时间，一期产品即上线，后续不断的迭代验证，成为公司拉新的一个核心产品业务。

1.4、简单即是美：通过多个业务产品验证、业务数据，稍微复杂的业务流程或者玩法，印度用户是玩不转的。比如说，大转盘这个业务，印度用户只需要点一下就能有可能领到一个奖品，它的业务数据特别好，后来我们给它加了一个每日签到送玩大转盘权益的功能，并进行实验对比，最终对比数据发现，有签到功能的实验数据指标反而下降了。神奇的一个国度。

1.5、横向同步：随着公司业务不断快速增长，很多项目均会涉及到多个团队，需求讨论时叫上相关团队的同学有利无弊，避免项目进行一半的时候临时向其他团队提需求，兄弟团队同学真的会一脸懵逼。

1.6、身临其境：需求讨论时，如果对业务足够熟悉，那么讨论时我们应该将其各个功能点在心中，进行串联，模拟业务流程的流转，提出自己的疑问，一句话很重要：不懂就问。切记问过之后要有自己的思考，和产品、运营同学进行思想上的交互。不要担心自己问题是否很低级，有些问题大概率存在我们觉得想当然的一些点中。另外，需求讨论前，先向产品同学要下初稿，提前进行了解，是不错的。若是新同学，对业务不熟悉，那么需求讨论时，提前了解需求背景，将自己设想为消费者，进行用户界面上交互流程心中跑通，再和组内资深同学进行沟通，模拟业务流程是如何在各个系统之间进行流转。总结一句话：不懂就问，和产品同学互动，心中模拟业务流程。

—

需求评审

项目经理分享的心得体会：项目中的一点心得体会系列之一(2)

2.1、评审：如果前期需求讨论足够，那么到prd评审时，更多的是一些流程和功能点的double check。

2.2、需求拆分：正如 1.3中所讲，去繁存简，确定项目各个版本的产品目标和功能点，项目一期主流程是必须要上的，那么在保证主流程完善的情况下，是否有足够的资源和时间去捎带哪些特色功能。这些都是需要进行讨论和均衡，方案没有最好的，只有更合适。以快速落地、验证、稳定性重于一切，为目标。

2.3、勾搭项目关联的横向团队，一起参与，是很重要的。孤岛效应是永远存在的，我们只能尽量去减少其影响。横向团队的产品需求排期、项目优先级、团队资源情况、功能点的实现成本等，均是不可控点。

2.4、项目排期：一般情况下，产品同学都会给大家一个期望上线时间，开发、测试同学都会大概盘点下手头上的事情，进行简单评估时间节点是否有可执行性。若有多个项目并行时，需要技术和产品沟通项目的优先级，若涉及多个产品同学，那么需要产品同学之间进行讨论确定多个项目的优先级。

2.5、prd核心关注点：清晰的完整业务流程图、简单的交互设计demo图、和与之配套的核心功能点描述。如果没有看到”业务流程图“ 最好让产品同学画出一个，或者自己画，然后和产品进行对焦。大部分情况下，文字描述太抽象，容易有歧义，文字太多，容易让人各种阅读疲劳，就比如我这篇文章。so，just show me ‘业务流程图’。它是保障项目如期上线，业务稳定性的基石，很香，值得花时间去做。下图为某虚拟项目业务流程图：

项目经理分享的心得体会：项目中的一点心得体会系列之一(3)