本期分享嘉宾为一位15年开始远程工作的资深产品经理，拥有丰富的产品经理和项目管理经验
项目周期：4.1 - 5.3
产品周期：
1.0版本时间：4.1 - 4.4
1.6版本时间：4.20 - 4.27
项目背景：
客户公司是一家做生物科技行业的，主要进行基因测序等相关产品的业务。
本项目主要是为了快速获取客户样本数据，方便后期业务的扩展，借助线下活动载体。通过小程序进行前期的试运营，小程序更多的加入游戏性质，朋友PK，增强互动和扩展速度
项目概况
4月1号项目正式开始产品阶段，需求方给出的要求是4月13号有一个颁奖典礼。最好能在这个时间节点之前上线小程序。在活动现场推广一波。
于是，根据需求方给出的需求，4月2号整理出了产品的第一版原型。由于第一版的需求相对比较简单。在4月3号的沟通上也没有什么大的改动，比较顺畅。本身需求方表示能理解在这么短的时间要做好上线有些压力。所以，再初稿原型确定没有什么大问题的情况下，需求方强烈建议，在目前的产品原型基础上先开始做UI（UI是需求方自己来处理），细节调整在UI阶段进行。
贸然推进UI会带来的风险也是显而易见的，但是考虑到开发时间紧迫，同时也是希望能在颁奖典礼之前完成小程序的上线，在告知了需求方这样操作带来的风险，以及活动前上线的目标不一定能达成的客观情况，最终和客户约定好按照先先推进UI的方案进行。并且强调了，UI需要完成的时间节点。
下一步就是推进UI的工作，这也就是后面问题的根源所在。
在UI出图的过程中，需求方把他们的运营人员拉入开发小组，运营从实际线下场景提出了相当一部分的修改意见，这时候，UI已经进行了一部分。导致UI的调整陷入了被动。后端和接口的开发也在这个过程中不断的调整。风险急剧上升，产品的改动，带来的需求的增加以及开发人员的工作量的增加。
该项目的管理工作也是由我这边处理。经过和客户的协商，新增内容暂时不做量化处理，等1.0版本上线之后，统一按照最终的上线产品进行最后的评估，避免在中途开发阶段不断进行新增功能的评估，导致产品上线时间受到影响。此处的风险暂时得以化解。
中途UI由于运营调整的缘故，最终再deadline前两天才把最后一组UI稿给到。此时离上线只有两天时间。
1.0版本，在运营，UI和开发的协同配合下。得以顺利完成。这里要对该项的前端开发和后端开发给予肯定，值得推荐，前期的沟通过程中，多次强调项目的时间紧迫以及质量要求较高。开发人员也在积极配合，包括最后的联调阶段，前后端一起熬了个通宵。最终在13号完成了开发。并进行了小程序的代码审核提交。
本以为，项目到此已经顺利结束，就等待小程序发布。但是头疼恶心的问题又来了。需求方的产品业务，没有被审核通过，小程序的审核被驳回。原因这里就不细说。原本以为顺利上线的产品，最终卡在了审核这块。
14号之后的一段时间都在进行审核上架的处理。
至此，1.0版本的产品告一段段落。
针对1.0版本产品阶段，总结一下几点：
1、个人觉得产品的设计，不仅仅是根据客户的需求进行一个简单的功能堆砌或者是需求的梳理。需要去了解需求发的行业类型，产品核心。必要的情况下和需求方的运营，市场等其他团队成员做一些深入的沟通，更好的理解产品。
2、在产品没有规划好的情况下，尽量避免贸然推荐后续阶段的任务。哪怕是着急上线。也不能将风险转移到后续阶段，该项目的实际情况，反应了后续阶段的风险，远远高于前期的时间付出。
3、产品的设计要考虑载体的可控性。小程序类型的产品，涉及到行业审核，内容审核。这里在前期设计的时候，就需要去了解不同的载体的使用规则，避免后期影响推进。
在1.0审核被驳回的情况下，需求方的颁奖典礼计划没有赶上，这时候，需要完善1.0遗留下来的需求（1.0为了尽快上线，规划的内容保留了一部分在后续的版本中）。
此时的产品架构虽然是1.0版本规划好了的，单运营在1.0提出的部分修改内容，影响了整体产品架构。整体往下推进已经增加了相当一部分工作量。
在和客户协商之后，产品架构决定重新调整，为了方便扩展后续的活动，同时也为了后续产品的迭代成本较小，最终和开发协商，重构1.0架构。该阶段同时加大了和需求方的运营团队的沟通。进过短期的梳理。新版需求的产品比较顺利的完成了原型的制作。开发这边在1.0 的时候，已经将可能发生的变更内容告知。所以后端开发的调整也比较顺利。
4月底，产品新版的开发已经完成，同时小程序的审核问题也已经解决（在新版开发的过程中花了相当一部分精力去处理）
五月初，产品正式上线。需求方开发批量使用。在这过程中，运营还是七七八八提出了一些修改建议。开发这边配合度还是蛮高的。基本都能及时处理并提交审核进行版本的更新。
最终，上线版本1.6。
针对1.6版本产品阶段，总结一下几点：
1、产品设计原型出来之后，需要做好原型测试。目前个人觉得大部分原型设计出来之后，缺少原型测试阶段，导致在后面的开发过程中，出现不少的细节调整。原型测试可以帮助解决不少的细节问题。
2、产品设计的过程中，最好是能和开发做一些必要的沟通。原型出来之后，产品经理需要将可预见的内容，或者产品版本迭代的方向告知开发。这样不管在开发还是在后期的修改过程中出现意外情况，可以做好准备工作，降低风险。
3、不能为了项目的工期，压缩了产品阶段的时间。这点很重要，压缩时间如果把控不好，后期的风险更高。为了不给开发兄弟留坑，同时也是为产品，为客户负责。在产品阶段，还是需要投入必要的工作时间。
该项目原型分为两个阶段，1.0和1.6版本
1.0阶段
整个1.0的沟通有三次，两次和需求方BOSS沟通，一次和需求方BOSS以及运营小姐姐一起沟通。第一次沟通详细的了解了活动的内容，活动流程，以及需求方提到的细节点。第一次的沟通还算比较全面。所以用了1天的时间完成了原型。第二次沟通直接就是确认原型内容。确认之后，进行了细节点修改。准备交付进行下一个阶段，这时候，运营这边提出了一些新的想法和思路，由于运营提出的内容，整体工作量比较大。加之时间紧，最终没有在这一阶段进行增加。直接建议放到下一个版本。至此。1.0版本原型告一段落
1.6阶段
上面提到，由于审核阶段出现了不大不小的问题，导致1.0版本没有顺利上线，产品的迭代没有停下来，趁这个时间，拉上运营小姐姐和需求方一起把之前提出的需求和流程进行的新的规划，这时候又出现了一些问题，运营这边已经脱离了1.0的主流程，提出了一个新的流程。
该阶段的第一次沟通，就出现了比较大的改动，没有办法直接进行新版本的迭代更新。考虑到目前1.0版本还没有正式上线，只是内测。于是和开发小哥哥同步了消息，开发给出的答复是：可以改，之前的数据结构兼顾到了新流程。马上联系运营和客户进行了第二次会议。会议中确认了一下几点：
1、新流程的方案需明确（之前沟通也只是大致说了下方向），量化到功能点
2、相关第三方对接的资料和接口文档要提前给出
3、新版的计划上线时间要确定
本次沟通之后，根据会议记录，整理出了最新的功能说明文档。当天会议结束之后就和需求方进行了确认。
原型的设计，由于1.0的UI相对比较完善，加之流程上的改动，对UI的影响不是很大。所以就直接在UI的基础上进行了新版原型的设计。时间推进也是比较顺利。基本上也是1天的时间进行了完善。准备进行原型的交付
BUT，进行到此时，第三方检测机构突然提出了新的说明，导致原有的流程中，一步完成的操作，要拆分成两步才能完成。整个流程又进入了修改状态。为了确保后期不遗漏线下场景中的实际新需求。迅速的组织需求方的会议。并且邀请了三方机构的负责人，运营，市场部等多位人员参与进行讨论。此次会议的成果比较明显，最终各方都确认了整体流程的完整性。
终于，用1天时间进行了整体的修复完善。最终确认了整体1.6版本，之所以版本号定在1.6，是因为在这过程中有多次的小幅度的改动，每次的改动开发这边的速度又比较快。小版本号的改动，需求方经常忽略。所以中间进行了几次大的版本号的修改，最终版本才出现了1.6
该项目过程中的产品原型设计总结：
1、做好每一次的会议记录，会后整理完善的会议文档，同步给需求方和项目经理进行进度的同步。
2、涉及到多方合作的产品设计，最好及早的了解各个部门或者合作方，在产品中的角色，已经具体的工作内容。便于产品完整性的提升。
3、遇到问题，最重要的是想办法解决问题，而不是带着情绪去解释客观原因。问题是可以通过沟通去解决。
以上观点内容，仅作为个人再项目过程中的一些反思。希望能给大家带来一些帮助
喜欢的可以点击阅读全文查看产品经理主页！
网友评论