在任何时间与场景下，实现产品的快速交付与变现都是企业的终极目标，那么如何高质量快速交付产品？本文结合相关项目，进行复盘，希望对你有所启发。
【资料图】
本次以某两地项目售前到项目验收回款入账为时间节点，来复盘整如何快速交付产品。本复盘中不涉及与客户的商务关系的影响产品交付的因素。
在任何时间、任何场景下，实现产品快速交付变现产生价值都是公司的终极目标，不多赘述。
警院项目是我司战略规划的一个重要里程碑节点。对外打造智慧实战警院工作部署，帮助警察院校加大公安科技信息化与实战化成长。旨在通过培养学生使用习惯，获取院校师生的心智，从而长远奠定我司在公安行业内的影响力；对内则开辟警院产品新类业务线试点。
正逢我司有两个警院项目同时开展，借此以最小的代价，同时交付两个项目产品，简称两个项目为S与H项目。
基于以上背景，结合客户需求，我们团队提供了以下平台类解决方案。
平台类标准化产品：[S]分析研判、数据建模、数据资源中心；[H] 分析研判、数据资源中心
平台类项目定制化开发：[S]基于研判路径所需的教学管理系统；[H] 虚拟仿真、教学管理系统
在此期间，由于客观环境、资源频繁变动、资源异地办公、资源不足、工期短而导致产品求速而不求质、等等问题，对产品迅速交付变现带来了很多负面影响。
由于项目处于口罩期间，客户又在异地，会随机出现封控现象，导致需要出差的事项不能及时响应，进而影响项目验收。 存在项目团队成员不稳定的情况，团队开发人员流动性特别大，导致看上去该项目有很多人参与过，其实固定成员就三四位，以至于需求反复宣讲，且开发需要熟悉代码耗时又效果不好。过多开发人员短暂参与，相互之间且未统一代码标准，同时引发代码质量无法保障，影响团队士气，进而影响产品的质量保障。 同时，团队有成员在异地办公，虚拟团队沟通却不畅。 有团队进行工作量评估，但得出不确定情况。 研发项目期间，研发人员无法转移开发代码一直被打扰，影响开发进度。 定期风险排查缺失与信息同步不够，必然会导致沟通的有效性低迷。 对部分产品测试结果把控力度不够与测试场景精细度的缺失，导致交付后质量难以满足客户期望。 产品历史遗留问题，短时间内无法快速解决。 项目时间周期时间短、资源紧张，导致文档维护缺失。1、对外通过构建“教学-服务-培训”一体化的平台，提高警察院校教育水平。
2、对内快速实现项标准化产品变现，以及部分定制开发以达到项目验收回款，从而实现双赢局面。
3、为定制化开发内容提炼成标准化产品
4、基于公司战略规划，对未来潜在客户市场品塑造优秀品牌形象
交付时间：[H]项目计划时间内成功交付；[S]项目已验收。
交付结果：目前 [S]、[H] 项目已成功验收并回款，投入教学使用中，其中 [S] 项目已投入正常教学使用中，处于系统维护中；[H] 项目即将投入教学使用，开始进行系统维护，且客户其他建设需求二期正在洽谈中。
产品交付的关键节点是：项目售前、项目启动、需求沟通、产品开发。
a、项目售前
从产品交付的角度来讲售前阶段，对产品规划与形式的认可，能够有效推动客户心理预期建设，那么交付产品时，就有利于减少客户的不同观点阻力。
一方面是要识别了正确关键的客户干系人，并做好的了客户关系。另一方面在前期向客户推销解决方案时，产品角色便要介入解决的方案的撰写上，不一定是产品角色去写，但产品角色一定能对外宣讲这个方案，熟悉并能快速搭建堆砌出解决方案上的产品交付内容，同时保持交付项目解决方案的简洁，尽可能减少不必要的工作。
b、项目启动
项目启动大会的召开是必要的，这不仅仅只是一种仪式，更多是在仪式下各方干系人（公司内、公司外）对项目承诺。
一方面有助于增强各方人员的信任感，一方面加强了团队归属的仪式感，潜意识影响了对项目信心与责任，那么必然会导致对交付产出物的重视，从而影响质量。进一步来讲，如何召开项目启动大会也是一门学问，有意思的是[S]与[H]项目都召开了启动大会，排除项目金额对启动大会的重视程度影响，两项目的启动大会一个是对内对外，一个是只对内，方式也有差异。在后期产品交付中也有着不同的影响，总之，结果显而易见表明，启动大会召开的质量也是重要影响启动大会有效性之一。
c、需求沟通
项目上沟通的方式，因项目经理而异。但，从产品的角度，我们应该鼓励与必须让产品角色去给客户演示汇报，收集客户反馈。项目经理更多应该服务沟通与项目进度汇报。
同时，产品需要采用原型方法与客户沟通需求，通过快速构建和演示核心功能的原型，以便客户提供即时反馈。原型法可以帮助识别和解决需求不明确或变化频繁的问题，减少重复工作和时间浪费。
d、产品开发
1）与客户合作确定系统建设内容的优先级。通过与客户协商，了解项目交付中产品的关键需求和核心功能，以及可暂时搁置的次要需求。将有限资源集中在关键和高优先级任务上。
2）采用敏捷开发方法，将系统开发过程分解成多个小周期，每个周期都集中在完成一些功能或模块。客户和项目团队可以在每个周期中进行反馈和调整，确保项目朝着正确的方向前进。不具备敏捷团队的特点，可以采用混合方法：预测型+敏捷型。
3）与客户和利益相关方保持沟通和透明度，共同管理期望。明确可交付产品建设的范围和可交付成果，确保各方对项目的目标和限制有一个共同的理解，避免额外的变更和需求蔓延。
产品来源于项目，支撑项目的快速交付又依托产品稳定的开发迭代。通常在项目交付上，我们都谈论是要产品的标准化，尽可能少开发，但是通常会出现标准的产品功能无法满足项目交付问题，而且当前所处行业的特性，又要求建设方案具备特色，这就意味着定制化开发是必然的。
那么，项目交付的速度需要「标准产品+定制化开发」的组合模式。
由此，在产品质量上，如果标准化产品质量越稳定，版本更新越快适应竞争市场，那么对交付产品的质量就会越高。标准产品如何稳定与快速迭代又是另一个大课题，在此不做赘述。
当[H]项目与[S]项目同时交付时，依然是用「标准产品+定制化开发」的组合模式。但是，基于定制化开发部分如何与客户沟通争取更多标准化内容建设是不足的。主要原因之一是在这两个项目开发中是统一位产品角色，但该角色未主动掌控客户沟通的主动权，更多的是项目上的两位项目经理各自引导客户汇报，导致无法从产品的统一化的角度更好引导客户，这是需要产品角色去主动定期整合引导去汇报的。
另一方面，完全标准化意味着失去特色，那么，在了解需求后是否可以把控「特色」的范围，把特色设置一定百分比范围内？比如，交付标准产品功能85%+特色15%呢？当特设建设的百分比超过15%时，是不是可以判断不接这个项目，或者特色建设超过了15%但对未来产品规划的方向相一致，可以把特色升级到标准产品中，这是需要对当下市场、未来市场、以及产品规划有着清晰规划的前提下才能决策的。
显而易见，规范的沟通流程是减少非必要沟通提升效率的有利途径之一，对提升信息同步有效性具有显著的影响。
所以，我们应该反思的是如何从已知的专业化标准化的沟通流程中，如何找到适合自己项目组的沟通方式才是最佳的流程。尽管对通用标准化的沟通规范是必要的，但是应该是基于当下的客观环境以及组员认可的支基础上。尤其是，当在外力条件下组员表动频繁，每新加的成员，得到他们的快速认可，同时给予他们参与权，更有利于团队的成熟，从而促使项目的快速交付。
回归到解决问题上，我们对问题场景进行了分析，对应到具体问题点可用以下方式解决，需要提醒的是问题解决方法并非唯一。
1. 团队行为规则达成一致，沟通方式达成一致，信息保持透明可以解决以下问题
由于项目处于口罩期间，客户又在异地，会随机出现封控现象，导致需要出差的事项不能及时响应，进而影响项目验收。 同时，团队有成员在异地办公，虚拟团队沟通却不畅。 定期风险排查缺失与信息同步不够，必然会导致沟通的有效性低迷。总结，接下来的行动优先级最高的是需要加强团队在项目交付上的敏捷培训。
本文由 @花间的花 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
标签：
