S1项目-经验教训B

最新推荐文章于 2025-05-17 12:09:16 发布

kyle_1111

最新推荐文章于 2025-05-17 12:09:16 发布

阅读量343

点赞数

CC 4.0 BY-SA版权

分类专栏： PM项目管理

本文链接：https://blog.csdn.net/kyle_1111/article/details/107049822

PM项目管理专栏收录该内容

56 篇文章

订阅专栏

本文分享了B端项目管理中的一些经验教训，包括项目经理更换规定、关键节点参与角色、人员要求与变更、决策分析、线上协作模式、接口沟通问题、SIT测试关注点以及业务理解和用户习惯。强调了沟通、决策效率、一线用户反馈和方案设计的重要性，并引用了业务变革的挑战和系统替换的难度。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

SOW中注明
1. 乙方不能擅自更换项目经理。但在项目过程中，如果甲方对项目经理的工作成果不满意时，有权要求乙方更换，安排资源进行面试。
2. 重要项目节点，如项目启动会、蓝图方案汇报签署、项目上线评审、上线运行报告等，应双方哪些角色保证在场。
3. 对于乙方项目成员的要求，需按照标书中提供的项目成员到场；进场需先经过甲方的人力资源面试，如果不通过，提供同等资质或以上的顾问；乙方项目过程中不可更改项目成员，如需变动需提前一个月告知甲方，以提前安排工作交接，安排同等资质以上的顾问进场；项目过程中，甲方对于乙方项目成员不满意，有权要求乙方更换，乙方安排资源进行面试。
业务人员没有变革意愿或意愿较低，认知度差，调研过程中会发现业务人员无法根据业务发展要求对变革项目提出诉求，对项目的认知停留在将现有业务流程搬到线上；公司中层及基层对变革要求宣贯不充分，对业务使命、变革动机、变革目标及变革路径认知不足；相关业务接口人时间投入不充分。
关于决策点的前置分析不足，导致在决策会议上出现需求反复、技术评估不充分、预增人天估计不准确等情况，会严重影响决策效率。
疫情期间，项目线上办公运作模式
1. 每日早会和晚会沟通任务进度。早例会面向规划，晚例会面向完成情况及问题/风险点识别
2. 任务和进度清单，具体到每个人；
3. 维护风险清单和决策清单
项目群会议要点
1. 各项目计划是否有调整？调整的内容及影响
2. 需要其它项目协作的任务、事项安排及进度报告
3. 问题点，风险点及严重delayed的任务（聚焦相互影响的事项，项目组内部的问题内部解决）
4. 任何需要帮助的地方
5. 原则：把控整体进度，不涉及细节问题的讨论，或方案的研讨。
系统接口开发，两边技术不提前沟通字段明细，而先调通。但测试时发现字段不一致，例如一边传名称，另一边传代code，导致字段类型要更改，无用的重复工作量。
接口也需用原型法，先把表单界面设计出来，交给对方确认，是否字段一致，要传值还是id？值集是后台手工配置，还是从系统某一处抓取？因沟通问题导致开发做重复工作，是产品经理不可原谅的过错！
SIT测试的关注点
1. 沟通方式、响应机制
2. 任务制具体到人
3. 缺陷管理工具
重要测试内容需要通过文档的方式进行交流，有效性面对面沟通＞视频＞语音＞IM。
乙方项目经理交接，需完整详细过一遍UAT清单，确保交接后对于问题描述、解决方案及承诺日期理解一致；同时让新项目经理现场与关键用户介绍方案及上线计划，检查交接交过。
持续维护系统接口清单，哪个环境对接了其他系统的哪个环境，地址、接口文档、对接人。
方案设计时，业务操作、场景的梳理，一定要找具体负责该操作的一线用户确认。即使是同一个部门或同一个小团队的业务人员，也会有理解错误的地方。只有一线当事人的反馈，才是“相对”最可靠的；而对于最终方案的确认，一定要找到业务领导。一线用户的想法，往往受局限，只考虑到单一场景。
类比侯世达定律：B端产品的替换成本极其大。用户习惯的力量，会超出你的预期，即使你已经考虑了这一点。业务觉得系统更复杂、更难用的判断依据是：这跟以前不一样了。
至理名言1：“我就没有听过用户说你们IT的哪个系统好用，只有用户去了别家公司，然后就会说，我们以前公司的系统都可以，为什么现在不行了”
至理名言2：“OA都可以做到啊，联系XX工半小时就改完了，新系统肯定更可以做到啊”
OA，将全部业务串在一个电子流上。切换为专业系统，划分各职能模块，靠业务操作流转，则认为是在重复创建单据，没以前好用。所有部门都以为自己是在追求规范和高效，同时满足业务实际需求，但对于系统来说则无法落地。堪比创新者的窘境，被利益链捆绑死，任何变动，都在影响用户的体验。
方案设计时，一定要拉通数据架构进行合理规划。否则就是在给自己挖坑。