产品小白常见七大项目管理问题

是阿妹呀 2023-08-08 14:38:36

进入职场后，笔者才深刻感受到，需求调研，需求分析，画原型等只是产品经理工作的一小部分内容。项目管理也是产品是否能成功上线的关键。部分组织结构比较细分的公司会将产品经理和项目经理两个职位划清界限，但是笔者了解到的大多数企业都要求产品经理拥有项目管理的能力。

毕业后笔者的第一份工作的岗位名称叫“需求分析工程师”，归为项目部，平常对外对接工作时统一作为项目经理的身份，但我们实际的工作内容却涵盖了产品经理+项目经理的所有职责。因此除了学到如何更好地设计系统产品之外，我也在项目管理的过程中一步步升级打怪，逐步成长起来。

接下来笔者将从一个产品小白的视角讲述在项目管理过程中遇到的七大问题，并结合工作经验及阅读的相关书籍以及pmp备考过程中学到的知识对这七大问题进行解读并给出建议。

其中主要涉及到的书籍除了《PMBOK》外还有「IT项目管理案例解析」《知易行难：58个IT项目管理案例解析》。如果有时间的话大家可以看看刘羚的《知易行难：58个IT项目管理案例解析》，书中的每个案例均由“案例故事”、“案例分析”、“小结”三部分组成。案例类型丰富，从单项目到多项目、从乙方项目到甲方项目、从个人到组织，全方位、多角度地揭示了项目成败的原因。

下文案例提到的相关角色统一用“项目经理”，但这些同样可能是产品经理会遇到的问题。

其中包括：应该遵循何种工作逻辑、如何接手新/半截项目、不懂技术怎么办、如何搞清需求、进度落后怎么办、客户需求频繁变更怎么办、客户要求压缩进度怎么办。

一、应该遵循何种工作逻辑

项目中出现的所有问题项目经理都有责任解决。但同一个问题交给不同的项目经理处理很可能出现截然不同的结果。造成这个现象的因素有很多，其中包括项目经理的项目管理经验、沟通协调能力、资源分配能力、遵循的工作逻辑等等。而对于小白来说，经验及能力需要通过时间及项目的沉淀才能获取，而能较为快速学习到的就是正确的工作逻辑（顶层工作逻辑）。

工作逻辑分为底层工作逻辑和顶层工作逻辑。

什么是底层工作逻辑？

就是项目经理在面对各种项目管理的相关问题时，会主要从项目的视角出发，为满足项目足额回款、高质量交付、客户满意等关键指标，在项目实施交付过程中的一系列管理计划与监控控制。

什么是顶层工作逻辑？

就是项目经理在面对各种项目管理的相关问题时，会主要从公司战略的视角出发，识别项目的核心目标（利润/客情/经验/人才/试点/其他战略目标）,深刻理解本项目对公司的核心价值是什么，再从对应角度寻找合适的解决办法。而不仅仅只是为满足项目足额回款、高质量交付、客户满意等关键指标来进行决策。

笔者接下来将用自身的经历来展示遵循不同工作逻辑的人会分别如何处理工作中的问题。

1. 案例背景

笔者的公司为一家专门为政府提供IT服务的企业，2022年8月与政府签订了某项目合同，负责一个市级系统的建设工作，预计2022.11月上线。而在9月中下旬，客户突然提出变更需求，原因是省级系统已经先一步建设完成，为防止重复建设，市政府要求停下所有开发工作，让公司派人重新进行调研新需求，代替原本合同里规定的模块。但此时公司对于原项目的开发进度已经接近70%，若按照客户的意思，此项目将带来巨大亏损。

突如其来的变动让公司的人都措手不及。为使得项目不亏损，公司的市场人员多次与客户协商，希望其能继续开发，重复建设的系统可用来做数据回流，方便本地管理数据，但客户对此建议并不满意。但政府对于此项目的拨款已申请下来，若要再缩减预算流程也及其复杂繁琐，所以客户希望公司再次进入政府其他部门进行调研，设计一些新的系统代替原拟定的功能系统。为满足项目足额回款，似乎只能这么做，但是这将花费更多的人力资源及时间，总的来看还是亏损的。两边僵持不下，项目眼看就要烂尾。

2. 解决方案

在将此事上报给领导后，领导带着我一起拜访了客户方项目的决策者。在长达两个小时的交谈后，客户满意地将我们送出门，并表示希望了解更多公司的项目，以后可以多加合作。

那这两个小时里到底发生了什么致使客户的态度发生这么大的变化，又是什么让本来大概率会烂尾的项目成了公司未来获取更多业务机会的基础呢？

在这两个小时里，前面大概有一半的时间领导都在和客户聊天，当然不是普通的唠家常，更多的是跟客户了解其内部有哪些业务处理起来不够高效，急需通过系统线上化的需求。在了解他们痛点的同时，再介绍我们公司涵盖的产品线有哪些是可以解决这些问题的。

当时公司的研发部正在研发一套人工智能的新技术，研发已经步入最后阶段，但是由于暂时没有客户，所以技术可能存在部分未察觉的漏洞，急需进行试点进而优化产品，而这项新技术正好能解决客户部分监管的需求。领导表示可以免费为客户提供此试点服务，并且可以再额外帮客户新增功能模块解决新需求，这些新的内容无需变更到合同里，都是免费为客户做的。但是原合同里的建设内容也希望继续按流程走下去，最后的验收也按照原来的计划进行。

客户听了很是心动，同时也问道：“这样你们不是亏了吗？”领导笑笑说这都是应该的。客户很是满意，同时主动要求我后面整理一份详细介绍公司现有项目的文档发给他们，表示后续有很多其他业务需求想和我们沟通。

3. 结果

之后项目便依据此次交谈的结果有条不紊地进行着。最后项目成功验收、公司的新产品得到试点反馈、公司得到了客户的高度评价。

如果仅仅从项目成本及回款来看，此项目是亏损的。但真的是亏损的吗？

在了解了工作的顶层逻辑后，我们很容易看出领导此次交谈主要从公司战略的视角出发，将项目的核心目标定为客情和试点，最大程度地让客户满意，减少对利润的关注。在了解客户需求的前提下，推荐公司对应试点产品。这一举无疑是成功的。

也是因为这件事，我更加深刻地明白了评判一个项目的成功与否不仅仅可以从利润的角度，主要看工作的指导核心是什么。例如：

A项目：最终项目盈利20%，客户满意度低，项目经验没有提升。

B项目：最终项目亏损20%，客户满意度高，项目做了新的试点创新。

如果以利润率为工作指导核心，A项目显然更成功；但如果以项目持续性发展的眼光来看，显然B项目更成功；

虽然关于公司项目的顶层战略主要是高层决定的，但项目经理和产品经理工作时也应了解不同项目的核心目标，用顶层工作逻辑看待问题，解决问题。

二、如何接手（新的/半截的）项目

新人在入职后，在了解公司业务之后必定就要开始接手项目了。那么只有两种结果，要么是独立负责一个0-1的全新业务，要么是半截接手一个项目。两者本质上是一样的，即都要面对一个全新的业务，一个全新的团队，这很考验项目/产品的能力。

那么职场新人很可能在接触新业务的时候面临头疼的问题，面对不同的问题，笔者给出了一些建议。

问题1：项目流程复杂，涉及到的人员居多，很难短时间搞清楚项目的逻辑细节

解决方案：

1）自上而下思考问题

接触一个新项目的初期很容易陷入细枝末节中，这时就需要及时抽离，做到自上而下思考问题。同时寻找各部门经理+各业务关键人物访谈就是一个好办法，能够很好地从宏观角度了解项目，发现问题，从而制定方案解决问题。

2）承认“术业有专攻”

有些项目经理，在技术这一环节上就会纠结半天，有的人不能容忍自己对项目的技术有不懂的地方，花很多的时间去攻坚，结果技术还没学会，项目失控了。所以，我们要明白懂技术是产品和项目的加分项而不是必须项，可以在业余时间花时间学习，但在项目管理过程中要发挥项目经理的职责而非开发人员的工作职责。

问题2：半截接手的项目很可能存在很多上一任项目经历留下的隐患，如何识别并解决呢？

解决方案：

1）全面了解项目的情况，将项目当前的状况、存在的问题，以及可能出现的风险，向相关领导写个详细的报告。

2）后续的项目过程中格外注意和领导、客户的及时沟通，一方面这是项目的管理需要；另一方面也是让领导知晓项目状态，日后可减轻些自己的压力。

3）沟通要有闭环。很多项目对程序bug的管理比较散漫，在沟通方面极易产生严重漏洞。一个问题从提出到记录到分析到解决，一般会涉及至少3个人及环节，所以问题登记一定要规范才行。为了避免推诿扯皮，环式沟通是最合适的，如图1所示。而很多项目中采用如图2所示的链式沟通是不合适的。

产品经理，产品经理网站

图1 环式沟通

产品经理，产品经理网站

图2 链式沟通

三、不懂技术怎么办

在项目实施过程中，经常会出现一些技术和商务问题是项目经理不太懂、不了解的情况，这很正常。这时要树立威信的关键是项目经理要懂得尊重内行，充分挖掘员工的才能与潜力，而且能够安排信得过的技术人才做自己的左膀右臂，在技术专家的辅助下选择出最佳方案，这就可以赢得属下的认可。

项目经理不能仅限于自己日理万机、埋头苦干，必须花时间、花精力，通过项目例会、技术研讨会、项目评审等面对面的交流形式，以及各类项目技术文档、管理文档等方式和大家沟通交流。对于无法每周开例会的情况下，就要把精力集中在技术文档上，力求开发人员能通过文档全面透彻地了解需求。但不定时的反馈以及会议还是有必要的。

四、如何搞清需求

笔者上一个公司主要做电子政务项目，不同城市，甚至是同一个城市不同区的政府对于同一类业务的流程要求都是不一样的，因此项目一般都是定制化开发的系统。而定制化开发的应用系统，由于其需求的特殊性，个性化要求高，会受到使用者的思想、观念、期望和偏好的影响，以及领导风格的制约。其中具有相当部分的感性含量，很难进行量化描述，加大了需求获取与准确理解的难度。

因此在需求调研过程中可以注意以下几点：

1）搞清楚关键决策人是谁，特点是什么，到底要什么

如前面所述，电子政务项目个性化要求高，会受到使用者的思想、观念、期望和偏好的影响，以及领导风格的制约。很可能一把手的一句话就会影响到整个项目的方向，因此在需求调研之前需要先搞清楚关键决策人是谁，特点是什么，到底要什么。

2）制定沟通计划

为方便日后的工作高效进行，在正式开始需求调研之前可以先进行一些基于系统的培训，让参与调研的客户对系统有个大体印象，不能天马行空地去谈；对需求的管理也应该有一个知识的引导，让大家知道需求不是想什么就说什么，而是基于合同范围框架下的沟通，不能超出一定范围；或者将调研时需要提问的问题整理成问卷，提前下发；或者在现场根据问卷逐步进行引导。需求调研不能一上来就去找主要负责人，而是先在合同或技术协议范围内，自下而上，从粗到细，循序渐进地进行。

3）文档约束

要特别注意，对于在项目前期尚未确定，或存在一些日后极有可能变化的需求因素，要在用户需求说明书（或需求规格说明书）的“假设与前提”条款中明确做出描述；对于限制系统实现的外部环境，包括资金、人才、资源、条件、政策等约束条件，也应该进行必要的调查与分析；对于系统的外部接口、数据库、并行操作、通信协议等方面可以给出特定技术的限制。这些内容都是日后进行技术设计和系统测试验收时的重要评判依据。

4）了解项目的隐性需求信息

包括了解客户的组织结构和机制，了解客户当前存在的问题和改进的可能性，在调研需求前先搜集资料，做足功课，不能盲目把宝压在对方某个人身上，确保客户、最终用户和开发人员达成共识

5）了解清楚系统的性能指标

在进行应用系统建设的需求分析时，不能仅关注用户的功能需求，还要关注业务功能之外的如性能、安全、接口等其他方面的需求。这些方面用户往往在介绍业务需求时不会提到，一般人也意识不到，可以说它们是潜在的。只有在系统在联调和运行时，它们的影响才会暴露出来，而且很可能是引发系统故障甚至崩溃的关键因素

6）先演示后开发

在项目前期需求不能明确的情况下，建议开发商先不要急于开发正式的系统，而是采用快速构建原型系统的方法，将抽象的用户需求、操作界面和未来真实系统的运行情况，用原型系统和虚拟数据模拟表现出来，以此作为和用户进行沟通的有效媒介。

将抽象的概念变成看得见、摸得着的对象，让最终用户直观地看到系统的“模样”。这样可有效增加用户对日后产品的感性认识，引发他们提出更深层次的功能与性能要求。由于对原型系统的修改与调整比较方便、快捷，即使反复修改几次投入的资源也相对较少。在双方对需求达成共识后再以此为蓝本开发正式系统，可以有效降低项目风险和投入成本，避免返工，并加快项目整体的实施进度。

五、进度落后怎么办

项目管理过程中难免会遇到工作进度和当初的计划不一致的情况，无论是工作提前完成还是进度落后，一开始的进度计划都脱不了干系（工作提前完成并不代表项目没有问题，这反而说明项目一开始的进度计划是不科学的，安排的工作计划不饱和，浪费了人力）。而相对于工作提前完成，大家对于进度落后会更加有恐慌感，那么如果项目进度已经落后了，项目经理该怎么办呢？

1）调整自身心态，稳定团队情绪

项目经理是项目团队的核心，是灵魂人物。一旦调整进度不可更改必须执行的话，项目经理自己不能产生动摇，至少不能在团队成员面前表现出畏难情绪，最糟的就是和组员一起抱怨客户，抱怨公司。在调整好自身心态的同时，也要带领团队团结一致向目标努力。进度严重落后时项目组成员很可能要面临加班，那么对于他们可以做到以下几点：

强调项目完成对于公司的重大意义，激发组员的责任心和荣誉感。
鼓励大家超越自己，如项目正常完工，公司范围内进行宣传和表彰等。
调整计划时，特别注意发挥骨干的作用，让其感受重用和信任。
开展一些游戏类的比赛和集体聚会，建立团队中和谐温馨的人际关系。
技术层面，优化进度计划有很多方法，如识别活动之间的依赖关系、分析关键路径、优化资源组合等。

总之，项目经理要做的事情很多，首先自己要调整好心态，其次要做一些努力并鼓励团队成员一起为项目付出努力。

2）不能盲目增加人手

进度落后首先考虑到的应该是计划的制定，人员分工，项目例会几个部分有没有做好，并做相应的调整。若盲目增加人手，还会存在新人学习业务并上手的成本，并且如果此时整个项目的计划分工及跟进本来就存在问题，那么后面只会带来更多问题，使进度更加落后。

六、客户需求频繁变更怎么办

1）制定需求变更书面规范

首先，应要求针对所有的项目问题和需求，必须提供书面的登记。可以使用公司的问题登记系统，或者是Excle表，两者取其一（考虑有些项目现场上网不方便）。无论哪种方式，每个问题都必须有编号，且唯一。在登记过程中，几个关键字段是要写清楚的，如“问题序号”“问题提出人”“现场分析人及建议”“开发意见及回复”等。

2）客户需参与需求的第一轮分析

无论什么问题，项目经理必须组织客户参与第一轮分析，组织客户内部的定期问题归纳，评审；邀请客户的业务经理和提出问题的客户一起先内部评审，这一审不要紧，发现很多问题他们自己就“枪毙了”，也会让很多随便提问题的客户引以为戒。一定要引导客户审慎地考虑问题，提些有见解、有水平的问题。

3）内部评审

就问题和初步意见进行评审。项目经理、开发经理都必须在场，对问题汇总表中归纳的问题，无论大小都逐个过一遍，分清楚问题的类别、轻重缓急，然后形成会议纪要，签字确认，纳入开发计划。会议结论不能轻易更改，必须保证评审结论的严肃性。

4）优先级划分

很多不重要的问题，排到产品版本发布计划里，还有很多好的需求和共性需求，纳入标准产品研发计划，开发出来客户也满意；对于有些技术难度的，或者必须推迟的，往后放一放，大家彼此理解，不能眉毛胡子一把抓。

这几步下来，能够使双方的分歧都在会上充分交流，通过这种方式大大降低踢皮球现象及拖延推诿的现象。在过程中，项目总监应全程参与，保障会议的严肃性。

七、客户要求压缩进度怎么办

1）与客户沟通，告知最坏结果

如果客户突然提出压缩进度，例如5个月的项目周期要提前1个月，等于是提前了20%，假如原先的进度计划是合理的，这个进度压力就太大了。而公司又不能增加人手，那么，项目经理就应该主动找客户一起分析可能出现的各种后果，就像到医院做手术，病人家属都要签字说明自己了解手术的可能后果，然后由病人家属决定是否手术。

现实中，IT项目经理很难让客户签一个类似的“知情同意书”，那么这时候就要看项目经理的沟通表达能力了。笔者还原了下工作中遇到此问题的对话场景。

在告知客户公司资源不足，无法很好地压缩进度之后。

客户：“资源不足不是我的问题，你应该找你领导反馈。我这边的要求就是提前1个月完成，没有人你自己想办法。”

项目经理：“嗯我很能理解您的立场。是这样的，我们公司的资源都是根据业务线提前按照计划安排好的，我们也提前考虑到面对紧急情况该怎么应对，如果时间压缩的力度不大，相信我们，我们一定能很好地按照原来的风控计划处理好。但由于这次周期压缩了10％，比一般情况都要措手不及且棘手，当然我们也会最大程度地调用资源来尽量完成原目标，但以为咱们这个项目负责任的角度出发，我这边就是要提前告知您之后可能会出现的最坏的结果，您可以评估一下，您方也可以提前准备一些应对措施，这样咱们两边携手起来，项目肯定会往更好的方向发展的。”

这段话包含几个点，并且层层递进：