我从事传统项目管理已经超过10年了，在数字化时代的背景下，我有很深的体会：
从个人能力和长远发展的角度来看，项目经理需要具备产品能力。
甚至在未来，也不再有独立的项目和产品，项目经理拥有产品能力是必然趋势。
因此，在进行专项项目管理的同时，我也在思考和探索，将产品思维融入到项目管理中。
笔者从专项的经验和不足之处总结了以下几个方面，供大家思考：
做主人的责任，积极推动
在传统的项目管理下，项目的时间受到限制，项目的目标被设定，很多时候被动地被用户的需求所接受。
每个部门用户的需求都不能从自己的部门和想法中跳出来，不能从公司产品管理的高度来规划，需求的紧迫性和重要性往往由各部门从自身利益出发来评估。
更何况，用户的需求不是很清楚，有的说，“你帮我想想。 有人说，“让我们尝试一个月，看看效果如何。 ”
起初，我也无语了：业务部门没有想清楚目的和价值要达到什么目的，提出什么要求，做什么项目。
越来越多的这种情况在以后发生我重新审视了自己的思维方式，发现我的思维局限于项目管理的框架，所以我总是认为：
1）首先要明确用户的要求，要求由用户决定，越清楚越好。
2）弄清楚需求后，考虑如何实现它们。
3）根据我们现有的工作计划确定需求的优先次序。
4）这件事情还需要其他组和部门的配合，等其他组和部门办完后再说。
在思考了使用产品思维之后，我意识到我需要成为产品和项目的“主人”，在任何环节遇到问题时，我都有责任和义务积极推动和解决问题，而这种热情来自于对需求和项目的主人翁意识
1）主动思考，挖掘需求
询问用户真正的痛点是什么，目标是什么。
现状与目的之间的差距是**。 同时，也要考虑用户的炫点，以及哪些方面和功能得到了改进，才能让用户感觉特别“爽”。
2）深入思考目标，而不仅仅是执行：
优先考虑你为什么要这样做，这正是用户想要实现的目标。
在组织架构调整专项中，对组织战略进行详细分析，提前在前端系统中预测“网格式组织架构”内容所涉及的配置调整，以承担建设方业务，提前完成相关配置; 识别建筑业务人员交接业务需求与现有职能的差距，提出对接改造方案。
3）根据目标确定合理的优先级
在以前的项目中，接手项目时首先要做的就是拆分与自己相关的任务，确定相应的负责人，并根据手头的工作安排开发。
在后期产品集成需求中，结合实际业务，我们认为用户的迫切需求是支持成本渠道中待销产品的设计、收入确认和公司间结算，因此我们配合营销服务数字化部门确定快速、最优的解决方案，并优先进行订单转型， 企业急需的发票和公司间结算流程;
预测数据维护的等效水平，提前完成所有数据维护。
4）主动推动并积极负责项目的进展
对于工作不明确，主动找其他部门**讨论清晰明了，而不是被动地等待指示。
在票务系统的专用全电动票证中，虽然需求来源是票务系统对接的全电子发票。
但是，从项目一开始，我们就跳出了被动等待，从系统的升级点主动解读对接系统的需求，作为票务系统和前端系统之间的桥梁，提前列出了业务中可能发生的各种场景，并推导了每个系统中业务流程的步骤和数据需求， 从而主动演绎出各前端系统需要配合改造的内容，对各前端系统的改造进行公开和快速迭代改造。
特别是由于缺乏成熟的经验，我们主动要求票务系统尝试反向场景，并在已经开过全电发票的客户之间分享推论，以便提前做好我们的反向场景流程。
同时，在项目实施过程中，积极监控和推进票务系统及各类前端系统进度，确保项目进度和质量。 在较短的时间内，我们协调各方联合测试，快速发现问题，高效解决问题，监控转化回归测试进度，实现高效高质量完成联合调试测试，并预估、挖掘和解决问题。
附件：用户测试问题跟踪。
总结：跳出你预设角色的局限，将传统的执行者、合作者、响应者的角色转变为创造者、领导者、推动者，从各个方面考虑，努力推动项目的完成，从而成为产品和项目的所有者。
拥抱变化，专注于数据分析
继续思考优化
传统的项目管理是分阶段的，对时间敏感，但随着时间的流逝，用户的需求在不断变化，所以我们也需要在“满足用户需求”中做一个持续的过程。 即使客户没有提出要求，我们也在不断思考优化和迭代，以提高产品质量，从而不断满足用户的潜在需求。 同时，通过对数据的分析，根据数据带给我们的反馈，我们进行不断的优化迭代，敢于坚持对错。
在组织架构调整专项中，根据年初客户群销售的产品划分，原系统方案是通过前端系统1的LTC流程采购解决方案产品，采购后级工具产品遵循自研前端系统2的LTC流程。
但是，我很快发现，实际业务无法将产品划分得如此清晰，解决方案产品在销售时可能与工具产品一起销售，在销售位置级产品时也可能进行推广，以扩大市场。
因此，我们的系统方案也应该更加灵活，在与营销服务数字化部门协商后，尽快优化方案，取消原方案中对产品发放的限制，并在前端系统中增加产品信息不健全的预警功能，以便快速支持原方案的迭代，适应业务可变性的需求。
同时，我们分析了重复的手动操作，并试图统一和自动化流程。
以单据转账为例，我发现基本上从2月底到3月一个半月的时间里，我都厌倦了处理可能每天上报的客户分配和历史单据转账的需求，在系统中手动分配，数据统计手动分配的单据数量超过1个文件数量的5w;
此外，一些文档分配是直接从前端发起的，没有通知给后端系统，导致数据不一致、接口错误等问题。
我总结了ERP单据转移涉及的单据范围和对应的调整字段，可以使用标准功能进行操作，需要在后台执行，以及如何保存日志，并主动与解决方案系统部门讨论自动转账的可行性，优化了现有的人员交接功能和界面。
并将优化体验延伸到仓位级LTC流程，优化性能拆分功能。 最后，后端系统可以支持跨客户群、跨客户群内跨分支、跨分支机构内部的文档自动分配。
附件：手动文档传输到自动传输。
总结：拥抱变化并应对变化，而不是遵循计划; 利用数据对结果进行观察和分析，思考如何在原有函数上以最小的成本完成求解，实现快速迭代。
尊重多个系统的复杂性
与外围系统高效对接
在现代企业应用中，多个系统往往是组合在一起的，多个系统之间的协同工作组成为一个真正的业务系统，每个产品系统都不是孤立存在的，而是整个业务流中的一个环节。 因此，我们需要在项目过程中进行全局思维，而不是基于功能点的工具思维。
1）从产品和系统集成的角度思考技术方案，避免碎片化
负责解决方案的实施和交付通常会导致我过多地关注技术细节而忽视整体。
要思考需求给用户带来什么样的价值，帮助用户解决在什么场景中遇到的问题，同时保证多系统对接的稳定性和最低的改造成本。
比如我踩过这样的坑，只考虑集团产品层面的标准化和统一化，为业务分析的标准化提供产品数据依据，认为ERP的材料是所有前端系统的产品源头，前端系统应该按照ERP的梳理进行统一和标准化， 忽略了前端系统在产品层面也会有自己的逻辑控制，导致前端系统的产品选型、统计分析等问题。
2）合理**，保留扩展性：
在制定需求的过程中，最难受的就是需求的不确定性和灵活性，既要有规则，又要允许在特殊场景下跳过规则，所以在设计系统解决方案、业务模型和数据模型时，要适当考虑未来业务是否有变化的可能，提前预留方便后期变化的部分。
例如，ERP套件软件在灵活性方面不强，通过配置表或配置项可能发生变化的内容，用于减少辛苦工作，实现功能切换; 连接外围系统时预留扩展字段和方法，将一些验证规则或计算规则放入更灵活、可配置的中间件或前端系统中进行处理。
总结：从多系统的全局视角出发，协调各系统之间的约束和关联，实现1+1>2的有机结合。
更广阔的设计思维和产品视角
将解决方案的标准版本商业化
资源总是有限的，但用户的需求是无限的，所以在坚持迭代路径和产品目标的同时，要考虑系统方案是否可以进一步标准化，从而以最少的时间和精力达到最大的效果。
例如，在ERP系统中，通用函数作为不同模块调用的功能组; 在集成方面，将单个功能点集成到一个统一的接口中，用于外围系统调用。
此外，还需要充分挖掘需求的共性，平衡“需求”和“成本”，提供场景特定的标准化能力，并将其抽象为最小可用的产品模块。
例如，在不破坏业务闭环的情况下，尽可能删除业务流程的路径; 通过合并同类项目来合并场景。
在此基础上，“通用需求解耦，通用能力平台化”将通用部件与主产品解耦，通过平台搭建块，实现业务灵活选型。
结论：
在数字时代，产品和项目的交集只会增加。
一切都是产品，一切都可以通过项目管理进行管理。
在传统的项目管理中，引入产品思维，运用用户思维和数据思维，主动分析问题，思考和挖掘用户的真正目的和价值; 充分发挥解决问题的主人翁意识，不断迭代优化，通过标准化的方法将解决方案产品化，解决问题。