网站内容管理系统后台 设计(4.原型设计与评审新系统的原型需要花费来完成)

　　网站内容管理系统后台 设计(4.原型设计与评审新系统的原型需要花费来完成)

　　经过上述的日常问题采集和核心用户访谈，你基本可以了解重构中需要改变的地方。

　　在这种情况下，我采集的问卷中 80% 的回复都是预期的，但我仍然建议您执行此步骤，原因有以下三个：

　　最快的获取全信息的方式，方便查漏补缺。用户可以增强他们的参与感。也可以采纳自己的意见，让用户提前知道，以便后期更好地推动用户普及。

　　问卷作为一种高效的信息采集渠道，可以在短时间内获取所有用户对新系统的所有期望，从而可以根据相同问题的出现频率确定新需求开发的优先级，例如因为高频率的问题可以优先解决。

　　同时，用户也可以有一种心理预期，即在不久的将来会使用新系统。这就像是提前打了个招呼，以后用户会更有动力去尝试新系统。

　　3. 原型设计和审查

　　新系统的原型需要很长时间才能完成。建议在开始绘制原型之前，可以先用流程图梳理一下逻辑，防止出现偏差，或者沉迷于细节耽误进度，这样才能保证思路的连续性，这样效率才会更高。.

　　此外，建议更认真对待原型的第一个版本。页面布局、颜色、交互路径等，都能解释清楚，就不提了。因为大多数情况下，在正式开发之前，都会召开一次大型的评审会，邀请双方的领导和用户代表一起参加。

　　建议在复习的时候，除了拿出设计方案和样机图，还要提前准备Q&A，也就是针对观众最关心的地方，提前写好问题和解决方案，力求做到为自己争取更多主动权。让对方对你感到舒服。

　　4. 首版上线前后

　　1）发射前

　　专家原型评审后，可进行后续正常开发评审。

　　前期尽量和你的研发团队沟通你对业务的看法，设计的初衷是什么，希望解决什么问题，让研发在开发中更加了解业务处理并减少因理解偏差而导致的错误。

　　整个开发过程一般需要一个多月的时间。这段时间，产品经理要做好项目进度管理，至少每周统计一次进度，召开进度会议。

　　如果这个项目的高层领导比较关心，应该定期给高层发邮件，同步进度。

　　2）上线后

　　这里的上线可以分为两种：内测版上线和对外正式版上线。

　　内测版上线后，可以邀请多位*敏*感*词*用户体验新系统。用户验证核心进程运行正常后，即可对外公布正式版。

　　正式上线后是1-2个月的试用期。在此期间，需要让更多用户试用新系统，及时暴露各种突发问题，快速迭代修复。

　　不过，此时用户还习惯于使用旧系统，如何让大家多尝试新系统呢？这里我使用了三个小技巧：

　　提供更快的访问方式（如：免权限申请） 提供用户关心的试用福利（我这里是为了给用户提供一定程度的测试） 小窗口邀请用户（我已经私聊了80多个用户，邀请体验新系统，并附上系统手册）

　　当然，在这段时间里，你需要在规划后续任务的同时关注用户反馈，随时掌握时间和进度。

　　5. 如何选择函数迭代

　　可能大家都希望新系统完成旧系统的所有功能，然后开始添加用户提出的新功能。

　　起初我也是这么想的，但发现如果你想吸引用户的注意力，新功能效果最好。每个人都很好奇。如果你发现自己有了与以前不同的新事物，你会想更多地去体验和尝试。

　　这也是我和领导沟通后被要求的。

　　最好的方法是平衡旧功能和新功能的开发进度。前提是要保证新特性的出现不会和不在线的老特性依次嵌套。

　　比如我这次重构的时候，考虑到我的用户群是各个地区的多个风控团队，大家一般都是分组联系客户。旧系统任务申请只能属于一个人，团队成员不能合作。

　　在新系统中，我在第一版上线后的第二个月增加了“群组管理”的功能。群组中的成员可以看到彼此的任务并分享自己的工单数量。内部任务灵活流转，组长可以统计和控制团队成员的工作量和工作内容。

　　该功能本身与旧功能有不必要的嵌套逻辑，在线用户的反馈非常好，验证了之前的预期。这种新旧功能交替开发的思路，大家可以多想想。

　　6. 过程中出现问题怎么办

　　一般来说，重构后的系统上线后，会收到更好的用户反馈。毕竟旧系统年久失修，新系统会让人眼前一亮。这时候，产品经理很容易沉浸在新系统完美的幻想中，希望新系统的口碑永远完美，不允许有瑕疵。

　　但是，您无法避免问题。

　　新系统上线后的时期确实是系统最不稳定的时期，问题需要不断的发现和纠正。

　　作为产品经理，我们要学会理解新事物的发展规律，把解决问题和如何避免后续问题放在首位。

　　以下三点是我走了一些弯路才明白的：

　　包容问题（有问题不重要，重要的是如何解决和避免问题） 对开发有信心（和你的开发站在同一个位置上，如果有线上的bug，先信任解决问题）对用户请耐心等待（请第一时间安抚用户，诚挚道歉并说明解决时间）

　　记得有位导演曾经说过：如果这部电影成功，那一定是大家的功劳；如果失败了，那一定是我的责任。

　　产品经理不仅要负责产品设计，还要考虑团队合作、项目管理等需要考验自身软实力的领域。

　　问题和矛盾的出现，会进一步放大你在这些情况下的心态和应对能力。收工时一定要有大局意识，承担项目负责人的责任，这样你的团队成员才会更信服你。

　　7. 数据同步和用户迁移

　　新系统的基本功能与旧系统一致。所有用户都可以直接切换到新系统吗？答案是否定的。

　　用户迁移到新系统时，绝对没有一刀切的方法，应该采用平滑过渡的方式逐步替代。

　　因为这段时间老系统的数据都在被用户使用，如果强制切换一个完全没有数据的新系统，用户不生气也就奇怪了。

　　此外，我们的项目分为两个阶段。第一阶段的目标是所有内部用户都已经过渡到新系统，而没有外部客户的感知。

　　您可能会问：外部和内部数据交换部分呢？如何保证之前在旧系统上运行的进程？

　　答案是——数据同步。

　　数据同步可以分为3个部分：

　　账户同步——内部账户和外部账户从旧系统同步到新系统账户关联——新系统内部账户与旧系统内部账户关联文件同步——新旧系统生成的文件彼此同步

　　第一步，账户信息同步

　　由于外部客户账户的创建来源来自上游CRM系统和旧系统的用户创建，考虑到外部客户的重构放在第二阶段，外部客户账户的创建来源保持不变在此期间的这个节点，只使用客户账户和内部账户。以及新系统的相关信息。

　　新系统增加了“客户账户/内部账户”模块，用于替换旧系统后台的用户列表。现有数据批量刷入，增量数据实时更新。

　　第二步，关联新旧系统的内部账户

　　由于用户是同一个人，注册新系统后，他将拥有新系统和旧系统两个账号。

　　因此，管理员应在新旧系统中将同一内部用户的两个账户关联映射，以保证下一步文件同步的平稳实施。

　　第三步，新旧系统的文件相互同步

　　为了实现内部用户迁移，无需外部客户感知，新旧系统之间的文件同步非常重要，也是保证无感知效果的关键。

　　首先确定同步范围，有一个最大化和最小化的原则。

　　以上三个步骤的完成，为后续的“用户迁移”奠定了基础。

　　最后，用户迁移

　　出于业务流程的原因，需要客户参与的任务将从 CRM 应用。因此，用户迁移的最后一步是结合CRM将上游任务从旧系统切换到新系统。因为之前已经进行了关联，所以在新系统的关联账户中可以看到来自CRM的任务。

　　这样，用户自然会主动迁移到新系统进行操作，同时最近产生的数据也可以在新系统中找到。

　　PS：正式切换前期，要考虑更多的异常情况和应对机制。比如：正式上线前，我们花了一段时间手动切换，确认没有问题后决定上线切换。又如：当出现异常情况时，可以手动将新系统的任务推回旧系统，以此类推。

　　8. 总结

　　以上就是计划一期改造涉及的所有关键节点。不同的系统、不同的业务可能会有差异，但核心思想是一致的。它们都遵循“平滑过渡”的原则，最大限度地降低用户的学习成本，降低用户操作门槛，优化业务流程，提升综合用户体验。

　　用户迁移到新系统后，不需要立即关闭旧系统。给内部用户一段时间的适应，也可以让内部用户完成之前同步到旧系统的任务，这会让用户对系统更有安全感。

　　四、分享与展望1. 印象最深的两件事

　　1）产品经理也可以看代码

　　当时我准备自动生成一份风控分析报告，里面涉及到风控领域的专业知识。旧系统没有此功能的文档。我和开发人员都不知道生成报告中的值和比率的逻辑是什么。

　　唯一的参考是旧系统中用python编写的几十页代码。由于需要结合业务知识和风控知识来理解，自己开发难度较大，所以选择自己爬代码。

　　我当时也想尝试一下，以防我能理解它。经过仔细的整理、推导和验证，花了两天时间终于弄明白了这里的逻辑，后面的开发讲解还是很有成就感的。

　　2）好喜欢

　　偶然发现我的一个wiki被点赞了很多次，包括两个部门的VP和一些我不认识的人。

　　本文档是我写的一款风控策略产品的业务逻辑的简要说明。它是一个负责其他部门的平台。因为我的系统即将访问策略产品界面，需要通过其他平台转接调用。R&D可以理解风控策略的商业原理，所以我写了一篇科普文档让他们看懂。没想到最后被这么多人看到，心里有些受宠若惊。

　　2. 未来要做的事情

　　现在重构过程的第一阶段即将结束，该项目已经完成了更复杂的内部用户迁移部分。阶段目标已经实现，即：内部用户的重构和内部用户的迁移。

　　在系统稳定运行3个月后，我们计划开始第二阶段的客户端用户重构和用户迁移。

　　与内部重构相比，外部重构的难度要小得多。因为外部客户的操作步骤比内部客户少很多，不涉及核心流程，并且已经搭建了新系统的框架，页面不需要重新设计，只需要部分功能更换。

　　后续考虑的重点将是“如何实现无感知或低感知用户切换”这一点。

　　二期工程完成后，我会再次与大家分享经验，敬请期待。

　　作者：Fancy Liu，*敏*感*词*融科技公司B端产品经理。

　　本文由@FancyLiu原创 发表于人人都是产品经理。未经许可禁止转载。

　　标题图片来自 Unsplash，基于 CC0 协议。