项目经理如何解决模型集成中的电商需求变化？

2. 背景介绍

患者职位：商场团队项目经理

公司（项目）情况：我们团队主要负责B2C商城项目的开发，目前正在开发B2B云链商城。

问题描述：新项目一开始就是一个完全独立的项目。 在此基础上，对整个系统架构设计和后期扩展考虑进行了新的规划。 然而项目进展了三分之一，领导要求嵌入到原来的b2c商城中，开放用户系统，让用户感觉这只是原来商城的升级版。

在不能说服领导的前提下，仍要求工期保持不变。 目前能做的就是加班加点赶进度，然后梳理需求，砍掉必要分支以外的功能。 然而，即便如此，为了赶上进度，也必须这样做。 如果放弃一些有利于后期扩展的想法，后期的维护成本也会很高。

我想知道是否有更好的解决方案？

3. 主治医师

首先要找准问题：领导需求需要嵌入到原来的b2c商城中，打通用户体系，让用户感觉只是原来商城的升级版。

其次，确定项目目前所处的位置：项目已获批，已完成三分之一。 更重要的是，领导无法信服，说明这是典型的变革管理要求。

解决步骤：（实施难度：从1到5-简单-困难）

步骤1：

项目经理应该与产品经理和需求分析师开会，明确领导的要求，并首先将其转化为基本的、明确的、可衡量的要求。

难度系数-2（需求分析师和产品经理都很棒，学会尊重、分析、倾听、引导、协调，基本没问题）

第2步：

正式提交变更请求，然后将新的需求提交给技术团队（项目组会详细讨论可行性）看是否可行。 如果没有，则返回给产品经理和需求分析师。 如果可行，提供解决方案（最好原设计方案不可行）。 移动，并增加中间对接层，从而保留原来的设计方案，保证可扩展性，并考虑到新的需求），并由技术负责人对新的功能需求进行排序。

难度系数——4（这个比较难，需要架构师能力强，如果架构师没有问题3就可以了）

第三步：

项目经理组织产品经理和技术团队开会，确定这段时间必须完成的任务。 然后，他先把不必要的分支以外的功能砍掉，然后再看原来的设计方案，看看哪些功能现在不紧急。 将其删除，然后将需求中除分支以外的功能以及原设计方案中删除的功能保存并记录。 有需求时可提出二期工程。

难度系数——3（这个需要选择，要考虑的东西比较多）

第四步：

由于本次变更规模较大，且设计依据（立项项目章程变更），正式变更需要提交变更委员会审批。 如果变更委员会批准，变更请求将正式提交给项目团队。

难度系数-1（体力劳动，按流程进行）

第五步：

为了正式实施变更请求，项目经理组织产品经理和技术团队召开会议，正式删除不必要的功能，然后提交给技术团队实施。

难度系数-2（这个基本在第三步就实现了，就是过一遍，然后再仔细检查那些忘记的或者需要小改动的，然后技术团队的基本功就完成了）

第六步：

项目经理始终监控项目的执行情况。 如果项目组任务较多，进度缓慢，可先采用进度压缩，然后再采用加急工作。 若仍达不到进度要求，可申请动用项目应急储备，以保证质量。

难度系数-1（只要持续监控，基本没问题）

第7步：

更改实施后，记得更新项目文件并记录更新日志。

难度系数——1（走流程，体力劳动）

第八步：

项目变更已完成。

难度系数——1（就过一遍流程，回顾一下，看看有没有遗漏，体力劳动）

总之，如果有变化，就按流程走。 这是一个原则问题。

项目基本保持原设计，保证了扩线需求和维护成本。

不紧急的定制需求可以预留给项目二期进行。

需求剪裁+工期压缩+抢工+可能的项目应急储备，确保项目进度和工期要求。

针对此案，我整理了以下七点：

1、B2B和B2C实际上都是基于交易的。 B2C是商家对客户，以小额、小批量、网上交易为主，效率高； B2B是商家对商家，更多的是商家获取信息。 、评估商家和产品，如果想建立长期的合作关系，结果和交易金额会比较大，可以选择线下洽谈、签订合同、进行交易。

2、针对这两种模式，我们的项目整合必须求同存异，满足两种交易模式。

不难发现，B2C和B2B项目都有商家、产品、列表、订单等功能。 不同的交易方式、沟通方式、谈判方式等都是不同的。 在建项目初期，并没有考虑与B2C的整合。 突然的整合肯定会影响已完成的B2C项目和在建的B2B项目以及已完成的模块的设计。 时间紧、任务重。 这是不可避免的；

3、对于B2C项目，我们采取的策略是对现有功能进行抽象，形成服务。 我们定义不同服务之间统一的通信格式和通信方法来完成服务之间的信息交互。

这样，我们首先完成了B2C项目的改造，为以较低的成本实现B2C和B2B的融合奠定了基础，并确定了技术路线。

剩下的工作就是根据服务思路对现有项目进行改造。

4、由于我们比B2C项目更熟悉在建项目的设计，因此我们可以基于从B2C项目中抽象出来的服务对现有项目进行改造，对现有项目的功能进行剪裁，并尽可能多地复用现有的服务功能。 服务相对稳定，可以减少功能的开发和单元测试的时间； 剪裁是困难的，只要你迈出第一步，改变你选择开发的模式，以建设性的心态，专注于组装服务。 只开发剩余的不可复用的功能，并以服务的形式连接到现有的服务模块。

5、针对B2B和B2C之间不同的交易形式，我们可以进行需求引导，让商户之间的交易模式更接近或与商户和客户之间的交易模式相同，将商户之间的每一笔交易都视为一笔商户和客户之间的交易。客户按类型区分。 附加功能动态绑定到商户与商户之间的交易模型上。 交易模型的复用才是B2B和B2C项目真正的融合。

交易模式多样化，可以自主开发配置客户和商户选择不同的交易模式。

6、商户在交易大厅列出商品、商户和客户进行购买、选择商品的功能都非常相似或相同。 B2B与B2C最大的区别在于多元化交易的动态配置。 不仅完成了两种模式的融合，而且解决了后期维护困难的问题，并且方便以服务的形式进行扩展。

7、个人项目经验，随着互联网技术的发展，B2B和B2C的融合将是必然趋势； 这不仅仅是两种模式的融合，更是我们项目管理思想的融合以及影响项目开发模式选择的变化。 面向对象的结构化开发方式已经不能满足不规则项目需求的扩展和业务的扩展。

当项目返工且工期不变时，项目成员需要加班才能完成项目，这对于士气和工作强度都是不利的。

返工会降低成就感，加班会因边际效益递减规律而导致工作效率下降，工期可能会延长。 面对这样的问题，并不一定有完美的解决方案。 只能考虑从各个方面入手，优化或减少这两个负面因素对项目成果的影响。

问题分析：

通常在开发项目中，面临需求变更问题是比较常见的。 此时产品负责人一般处于主导地位【不排除在某些团队中，由于能力问题，会由其他人担任该角色】。

因此，当遇到需求变化时，项目经理必须尽快召开会议，与产品负责人和相关技术经理进行沟通。 之后，项目经理协调团队经理再次与领导沟通，反馈团队会议达成的共识。 目标是获得领导的认可和支持，让团队达成一致的结果，以便进行下一步的执行。 [可能还需要多次来回沟通]

那么团队内部会议的沟通方向是什么？

1.了解领导做出变革决定的原因？

产品负责人和团队管理层非常有必要站在领导者的角度去思考需求变更的最根本原因。 领导者可能会因为竞争产品压力、线上压力、战略调整、资金等问题而做出改变项目的决定。 有时候，一些领导者只是基于片面的了解而做出判断，并不了解背后的企业需要付出的成本和价格。 什么都不知道。

2.针对不同的根本原因，团队可以通过不同的方式提供解决方案。

2.1 若因时间或成本限制而进行调整，必须以最小工作量调整功能为基础，不得大面积偏离原产品整体规划。 有时候，旨在快速推出的产品只是为了提前占领市场。 如果是这样，你可能需要在一定程度上放弃功能和体验上的优势，但必须在后期的迭代和维护中尽快弥补。

2.2 如果是因为领导者知识有限，可以对不同方案进行对比分析【从侧面为领导者提升知识】，从产品、运营、市场竞争、后期业务拓展和维护成本等多个方面进行比较，比较可能的解决方案。 将其造成的技术影响展示给领导，让领导有更直观的对比评估，全面的产品开发、运营推广、技术实施、项目效率的提升，能够有一定程度的视角市场竞争力，从而引导领导者做出更合适、更有利于企业发展的决策。

3、如果手臂最终不能扭动大腿，最差的解决办法是什么？ （如何避免再次调整以及执行前如何与团队沟通。）

如果领导仍然坚持执行他的决定，那么团队需要制定一个完整可执行的调整计划，并尝试以最好的方式提出解决方案——比如使用原来的商城框架来减少返工时间； 或者在现有的商场框架中。 根据进度，将部分部分移植到原商城，减少开发量； 第一期上线的产品功能，牺牲了一些可能影响以后扩展、增加维护成本的功能，多了几个开发周期短、不影响扩展和维护的功能。 成本，有一些亮点和特色的产品特征可以用类似田忌赛马的方法来提升一期产品的竞争力——“削顶取中，舍中补”底端”。 同时也可以为技术团队打下底层基础。 提高产品的可扩展性，争取更多的开发时间。

其次，领导明确并批准了项目调整方案后，就要思考如何与项目组沟通。 这需要管理团队达成共识。 一方面，我们不应该降低团队的成就感，觉得项目不行，被迫调整。 相反，我们需要让大家认为我们的项目非常重要，所以我们需要挑战更高的难度。

另外，我们争取对团队的激励，提前与领导协商。 如果项目方向调整，团队仍然能够按时完成，我们希望为团队提供一定的奖励[无论是奖金、旅行、团队建设活动]，以便大家在可能需要加班的时候未来，你仍应保持斗志和热情。

同时，为了防止技术人员长时间加班，影响工作效率，整个项目的工作进度以及涉及的人员必须与技术总监进行拆分，尽量避免长期加班的状态对个别或部分员工，保证员工休息时间有一个宽松的度。

最后，为了避免项目执行过程中再次被领导调整，必须召开新产品评审会，领导需要共同参加。 这不仅可以让领导知道你的具体解决方案，还可以让领导和团队成员直接面对面沟通，表达自己的想法，了解团队的难点，知道项目的紧迫性，减少被调整的风险再次。

总结：

无论你是说服领导继续原来的项目框架，还是无法说服而不得不接受项目的调整，你都需要向领导清楚地解释项目调整对未来产品、运营、技术、运维等部门。 从企业利益的角度，评估项目调整带来的正/负经济效益和产品价值，尽自己最大的努力做出自己认为最好的项目方案，但也必须拥抱领导所坚持的改变，尽最大努力实现领导期望的目标。

4./我有话要说/

牧云-成都-产品展示：

“这个问题我们以前也遇到过，相当于独立的用户系统，相当简单，把原来系统的用户系统改为token，由老商城的用户系统分配，只需要连接用户-token系统，新项目通过Token认证就可以了，比如以前登录社保需要社保卡号和密码，现在强制要求使用第三方微信。 ，所以只要把微信和社保卡链接起来就可以了。”

小乐园-上海-AR:

“这个问题不是技术问题，直接打通账户系统可能会更简单。问题是它不仅连接到一个用户系统，而且商城的功能也连接到系统上。我希望这个可以细化，任务可以细化到每一天人员的发展内容，无论领导沟通得如何，说明当前存在的问题和耗时的问题，清楚地写下一些可以的功能。被切断也是必须的，最好提供一些解决方法。”

Ignatius-佛山-公益慈善：

“综上所述，我们目前的视角是降低技术实施难度，保证工期。既然是项目管理组，就应该从项目管理的各个方面来考虑。还有其他的可能。比如，既然B项目改为为了嵌入A项目，原A项目团队能否分配一些资源？

情商无-新疆-IT+教育：

“PMP的角度是提出一个方案，然后让双方坐下来谈谈，最好能说服他们采用这种方式进行后续的发展。如果不能被说服，就先搁置争议，寻求共同点。”保留分歧的同时，讨论一个可以接受的方法，让项目先上线。”

亮阁-杭州-旅游：

“我个人认为最大的痛点是：系统是全新规划的，自然数据库结构可能和原来不一样，差别可能很大。领导要求嵌入原来的东西，应该是这样的。”代码和数据库不匹配，我认为要达到领导效果，没有人能适应它……改变任何事情都太晚了……”

5. 组织讨论内容

【以上关于项目团队管理的内容来自西塞“PM创造营”群的话题讨论，由@小M妹姐姐组织，以下好友分享@神长胜@MISSdingHangzhouSoftware@Xinxin-成都-运营@风筝-魔都-IT@小魔王(◣_◢)-成都-电控@孤老狼-镇江-ERP@꧁云丹风清꧂-大连-电控@小明童鞋-长沙-档案数字化@青沁-北京-IT@cecilia@王昱-长沙-在线教育@张伟红-西安-HRP@老王-深圳-互联网@野-无锡-制造@kaixin-北京-IT@阿超-广州-互联网@阿干-广州-软件@鹏翔-上海-供应链SCM@深圳-Jason²-通讯@罗伊-济南-智能制造@Zen.Wu-官教大学@罗伊-济南-智能制造@黑科技-贵阳-IT@jane -东莞-通讯@Key-南昌-智能电网@㊧Anonymousshi㊨-上海-IT@Bysing-广东-制造@小狗仙-重庆-物联网@天边-呼和浩特-通讯@牧云-成都-产品@先生陈-杭州-医疗IT