你是否遇到过这样的情况？
销售向客户BD时，承诺给到李若彤版小龙女，原型设计变成了刘亦菲版小龙女，虽然跟客户要求有差距，但总体还在可接受范围内；然而，在开发过程中，由于种种困难，变成了陈妍希版小龙女，这还不是最糟糕的……到了最终验收，交付了小肉包，最后不得持续增删改、打补丁，造成需求蔓延。
以上情况屡见不鲜，客户怨声载道、乙方头痛不已，为什么会发生这种事呢？大概率是以下原因导致的：
-
客户预期管理不当
这通常是销售过度承诺、客户过于乐观、项目执行中沟通不及时等导致的。完整的预期循环包括三部分，分别是“现状”、“预测”和“社会行为”，而预期管理就是对这三部分中的一个或多个部分进行引导，达到管理预期的目的。如果对现状预估不足、对未来过于乐观/悲观，或者受群体行为影响改变原有预期，都可能导致交付无法满足客户需求。
-
需求沟通有问题
乔布斯曾说过“消费者永远不知道自己想要什么”。客户提出的需求并不完全等于客户的预期，受限于表达能力，需求描述可能不完整、不深刻，甚至不能表明需求背后的需求。工作中，我们也常发现，很多客户提的需求甚至是自己的解决方案。一旦缺乏深入沟通和交流，团队就无法了解客户真实诉求，执行方向往往被带偏。当然，这也可能是因为信任度不够、信息涉密，或者客户在隐藏对你不利的东西，造成的需求传递不清晰、不精确。
-
无法识别重要客户/相关利益者
客户多人参与该项目，每个人都有不同的意见和需求，需求繁杂甚至互相冲突，分不清谁是实际决策人，或者“名义Owner”没有决策权。比如，K12教育面向的用户是学生，但付费的却是家长，如果只顾教学而不解决家长的购买诉求，订单就无法成交。
-
需求要素没界定，多项目并行、临时变更、资源冲突，质量难保障
时间、资源、质量是项目管理中的不可能三角。多项目并行推进，资源也时常有冲突与分配不合理的情况，团队面对繁杂的工作很难保质保量，跨项目资源协调成为管理层的核心工作，项目过程中可能横插各种非必要需求，导致团队被迫赶工、匆忙测试，管理层每天当救火队员，根本没有时间思考部门建设、文化建设、未来发展的事，如果遇到经常有新项目插进来，资源就更紧张了，说好的资源又被截胡了……最终结果只能是项目进度延期、测试躲猫猫、售后哭爹喊娘。
-
项目执行中需求沟通不足
一些大型项目，牵涉部门多、涉及事项广，如果跨部门沟通不到位，很可能出现误解或者遗漏，各环节出现问题，小洞不补、大洞吃苦
-
中间关键环节缺乏留档、验收和评审
如果是复杂或大型项目，中间环节往往很多，如果全靠语言来传递，没有黑纸白字的留档和签字审核，不仅会造成最终交付效果离原本的需求相差甚远造成，还可能让团队建出现推诿、扯皮、甩锅的不良工作氛围。
-
关键岗位员工无法顺利产出合格的交付物
想必员工磨洋工、瞎捣鼓、使绊子、撂挑子的现象大家也不是头一次见了，有些知名公司绩优员工onboard之后交付一直有问题，有些员工为了自身利益甚至阻碍项目进行，这究竟是怎么回事？根据组织能力杨三角模型，企业成功 = 战略 x 组织能力，因此，除了员工会不会之外，我们还需要关注软性因素——员工愿不愿意、组织允不允许。首席组织官COOSTRATEGY认为，一项组织能力，是指一个组织以“为客户创造价值并超越竞争对手”为目的而创造的一套能力要素组合（如图），这些要素的缺失很可能造成企业发展困境。
根据德林法则，把难题清清楚楚地写出来，便已经解决了一半。针对以上问题的原因，我们基于业界标杆科技企业的成功经验，设计出以下解决之法。要彻底解决交付与需求原设不符、项目冲突等问题，还需要从以下几方面发力：
-
预期管理
前面提到销售为了成单容易过度承诺，类似的情况在实际情况中时有发生，这就需要项目经理在前期/需求分析和概念设计阶段着重管理客户预期，把客户的预期控制在一个合适的水平，并提前识别并消除风险。接手项目后，需要和客户进行解释，若有些承诺确实不便实现，或者较难实现，需要提前给客户打预防针，但是要特别注意沟通方式，以获得客户认同和理解，以免客户有情绪。后期出现问题时，要注重管理客户情绪，针对预期落差采取补救措施，避免影响到项目实施和客户关系。
-
需求管理
需求管理包括：需求挖掘、需求分类与排序、需求匹配、需求变更控制、需求跟踪等步骤。
常用的需求挖掘方法有如下几种：用户访谈/问卷调研、客诉/反馈、竞品分析、数据分析、头脑风暴等，可以根据具体项目的实际情况，灵活运用。
而需求分类与排序方面，可以运用的方法也很多，包括：四象限分析法、Kano模型、MoSCoW法、RICE分数模型等。
如果说，需求挖掘和分类排序解决的是确认需求的问题，需求匹配就是要解决要不要做、做到什么程度、什么时候做、做成什么形态的问题，主要从行业阶段和公司资源两大维度进行分析。
针对项目需求变更控制，我们不仅要明白它的由来，也需要学会如何应对。工作中需求变更通常由以下原因造成：市场调研、用户分析、需求验证不充分；需求评审、技术评估、工作量估算不到位；设计、研发对产品需求理解不到位，导致设计方案有缺陷、不够健壮，不能达到需求目标；新业务，市场、行业机会发生变化，产品目标改变……需求虽然是变化的，但在一段时间内产品目标和需求是相对稳定的，所以我们要应尽可能减小变更对需求落地的干扰。
具体可以通过以下方式：对需求变更的流程规范做出清晰的定义，制定需求变更标准流程和特殊流程；对变更的需求进行深度分析、评审，明确变更内容信息及需求落地计划；明确团队各成员职责，并指定一个人专门记录维护需求变更事宜；建立需求基准文档和需求变更控制文档，以便项目各方快速达成共识，避免需求管理因变更导致混乱等。
此外，在项目进行过程中，我们还需要做好需求跟踪，包括：基础文档维护、记录变更详细内容、需求进度与状态（待确定、未开始、开发中、变更、延期、取消、关闭、已完成等）跟踪等。此环节可以借助一些项目工具来完成，如：Excel、腾讯/飞书在线文档、Worktile、PingCode、Teambition、ONES、JIRA等。
-
相关利益者分析
利益相关者分析用于分析与客户利益相关的所有个人/组织，帮助客户在战略制定时分清重大利益相关者对于战略的影响。利益相关者分析也用于项目管理过程中——项目交付成果可能会影响某人/组织，同时这些人或组织会作出相应行动来阻碍项目的推进，利益相关者分析的目的就是找出这些人或组织，制定沟通策略，从而使其利于项目的推进。 -
明确项目五要素：范围、时间、成本、质量、人力资源
项目的范围、时间、成本、质量、人力资源这些要素经常与沟通、风险、采购及利益相关者管理等其他项目管理领域结合使用，形成了一个完整的项目管理体系。项目经理需要在所有这些领域内平衡资源和努力，以确保项目的成功。
范围管理指明确项目的目标、任务、交付成果以及必须完成的工作。这涉及到创建明确的项目范围说明书，定义项目目标，以及后续的范围验证和控制。时间管理要求项目经理制定项目时间表，包括确定项目活动、持续时间估算、活动顺序排列以及进度计划的制定和控制，确保项目按时完成。成本管理涉及项目成本估算、预算设定和成本控制，确保整个项目的财务状况保持在可控范围内。质量管理则是确定质量标准并确保项目成果符合这些标准。质量管理包括质量规划、质量保证和质量控制。除此之外，还需要进行人力资源管理，包括规划人力资源、招募合适的团队成员、发展团队和管理团队动态。
-
沟通管理
人与人之间的许多问题都是沟通不充分或沟通中的误解引起的。沟通管理指确保信息有效地在相关利益者之间传递，确保及时正确的产生、收集、发布、存储和最终利用项目信息。沟通可以分为许多不同的种类：正式沟通和非正式沟通，官方沟通和非官方沟通，内部沟通和外部沟通，纵向沟通和横向沟通，口头沟通和书面沟通等；无论是哪种形式的沟通，都需要遵循5C原则：目标明确、表达正确、表达简洁、逻辑连贯和思路掌控。
项目管理中跨部门、跨团队的沟通一定涉及开会。开会作为团队沟通与合作的一种重要形式，其影响深远，不容忽视。开会有利于信息共享与透明化、有利于集思广益与创新，同时定期会议还可以增强团队凝聚力。但是，并不是所有人都能“开好”会，无效会议可能导致时间浪费、也可能带来沟通障碍和决策迟缓。此时，团队成员可以通过：明确会议目标、选择合适的参会人员、提前发布会议通知、制定明确的决策机制和流程、利用恰当的会议管理工具，做到会前提前通知、会中做好记录、会后及时跟进等举措，来增加会议有效性。
-
项目流程、文档与管理看板
项目流程管理就是从项目目标出发、从满足业主需求出发，进行流程规划与建设，建立面向流程的管理部门，明确流程中管理责任，分析流程现状，并进行监控与评审，适时进行流程优化改进。
企业内部跨部门、跨专业、跨岗位之间的工作协调是经常遇到的棘手问题，对企业中的本位主义，运用流程管理是一个理想的解决方案；面对跨部门合作中需要请示的事项，提前确定项目审批的权限范围，明确审批的顺序和环节，提交必要的文件清单、设置审批标准和指标，在合理的时限内，进行审批，并做好记录和沟通，明确权责；同时，还可使用“看板”来解决工作协同问题，拉齐团队认知。
-
组织管理
完善企业的文化、制度，聘用合适的人才，并为他们提供工作所需的工具/设备，通过转换管理方式、赋能组织的方式，充分发挥团队成员潜在的组织协同能力，建立学习型组织，提升组织竞争力。
关注 收藏 点赞 获取更多优质内容
0 构建多项目决策管理机制，组建跨部门业务决策管理团队，这个团队需要涵盖产品开发相关的所有关键业务部门的领导，例如市场领导、财务领导、研发领导、采购领导、制造领导等，将产品开发立项的决定权全从单一部门、单一要素，上升到基于公司整体价值、整体利益决定是否启动某个项目，从市场、技术、竞争、财务、保障、生产、资源、风险等多维度来判断项目的可行性，从而在立项源头就将对公司整体价值不大的项目剔除，从而更加聚焦有价值的项目上，这就是第三代研发管理核心思想的商业决策管理，业界集成产品开发管理IPD的IPMT（Integrated Portfolio Management Team集成产品管理团队），商业决策点DCP（Decision Check Point）。
第二招：提高共享度，强化复用。大家是否发现一个特点，所有的成功商业都是最大程度实现了共享，当然共享涉及多个维度，例如市场客户共享，例如针对中国电信客户，华为可以卖有线通信设备、无线通信设备、数据通信设备、网络存储设备等等，这样就实现了维护客户关系成本的分摊，提升了商业价值。例如产品技术平台共享，例如苹果，基于底层操作系统IOS，基于app Store应用平台，全面支撑了苹果的全栈产品系列，从当年的IPod，到现在的IPad、IPhone……这样最大程度节约的产品研发成本。这就是第三代研发管理的异步开发模式，技术开发与产品开发有效分离，技术开发先行，形成货架技术模块CBB（Common Building Block），然后像搭积木一样，拼搭出各个产品，自然会降低每个产品的研发资源投入，有效减少资源冲突。
第三招：全面推行项目资源计划和资源管道管理，规范资源申请、资源审批、资源承诺、资源核算，彻底将资源在项目间的分配、使用情况借助IT方式全面透明起来，只要透明了，核心重要项目是否给予更多资源投入？资源是否存在摸鱼情况？分配给项目的资源是否真正有效使用了？到底哪些资源不足，而又有哪些资源无事可干，忙闲不均？资源管理和管道管理，大家听得很多，但更多停留在理念上，不知道如何操作，而下面我们重点借助一个案例，图文并茂地讲解如何将资源管理和管道管理真正落实下去，并彻底解决资源不透明，资源不足，跨项目资源冲突严重的问题。
资源计划、资源池、管道管理
这里要首先明确一下，基于项目进度计划WBS，估算每个任务的工作量，定义每个人员的参与比例，从而展现出未来资源冲突情况，只能对短期资源冲突有帮助，无法解决中长期资源冲突的问题。这是微软Project等常用项目计划管理工具的基本方法，而这种方法最多能解决2~4周的资源冲突的问题，针对中长期资源预测和冲突问题基本无效。
业界证明要想整体解决冲突问题，需要采用中长期资源计划管理（RRP resource requirement plan）、资源池（resource pool）、管道管理模式，以下大致介绍一下这种模式的几个关键步骤。
第一步：各个产品开发项目（也可以叫资源购买方）制定相应的资源计划，提出相应的资源申请，注意资源申请可以按天、按周、按月，具体要结合公司的产品研发模式、产品开发周期、公司对资源管理的精细化程度等情况而定，记得当年在华为，华为的资源计划是以月为单位，每月25日，所有项目必须提出未来3个月的资源申请，其中第1个月的资源申请要100%的准确，第2、3月的资源申请要80%准确，这样，部门管理者一下就可以知道未来3个月的资源供需情况，从而可以提前做好应对。一般企业我建议按周定义资源计划，可以每双周申请，同时申请未来4~8周的资源。本文案例公司中，因为短平快项目多、人员少、资源紧张度高，所以采用的是按天制定计划模式，每周五上午制定每个项目制定资源申请，申请未来2周的资源需求，要求第1周要100%准，第2周要尽量100%准，同时严格杜绝有资源空闲的情况，所有资源必须都要安排下去。
第二步：资源经理进入相应资源池，资源池会自动汇总各个项目对本资源池资源的使用申请信息，资源经理就可以很方便发现资源冲突的地方，资源分配明显不合理的情况，资源经理就可以基于公司决策层已经定义的不同项目优先等级次序等因素，与相应项目经理进行协调沟通，最终将资源在不同项目的投入比例给最终确定下来，形成达成一致的资源供给承诺，项目经理这时候就可以根据达成一致的资源供给承诺进行详细计划定义了，这样项目计划的资源会更有保证，同时项目计划的可执行性就会大幅度提升。如下是，案例公司某资源池的正式资源申请情况：
第三步：前面2步已经把资源计划搞定，从而有效协调了跨项目资源冲突问题，形成项目与职能部门之间的资源承诺。接下来基于员工实际资源投入的反馈，例如工作日志、工作周报、报工表模式，收集到人员在项目中的实际资源使用情况，这样我们就可以把资源计划与资源使用对比分析，这样持续资源申请-资源批准-资源使用汇总-对比分析-资源申请的循环，就可以不断提升整个组织的资源管理水平，彻底解决资源紧张和跨项目资源冲突问题，如下是案例公司的资源申请与使用的对比分析。
当然有人抬杠，即使这样资源计划、资源冲突管理、资源管理平衡、资源使用对比分析还是不能解决我们的问题，我们就是项目特别多，每个项目都重要，都非常有价值，我要恭喜你，你进入了一个非常有前途的企业，能发现这么多有价值的项目，实属当今商业的大幸。但往往实际情况是组织缺少项目判断能力、没有决断力、没有站在公司利益上判断项目、蚊子腿也是肉的观点在组织盛行。
暂无评论内容