快消数字化复盘：一个数字化产品在亚太区的应(2)

作者:网站采编
关键词:
摘要：核心是我们Salesforce PaaS平台来搭建新一代的数字化营销产品，实现更好的逻辑和代码的高复用，如下梳理和规划的重点内容。 数据对象及结构——定义通

核心是我们Salesforce PaaS平台来搭建新一代的数字化营销产品，实现更好的逻辑和代码的高复用，如下梳理和规划的重点内容。

• 数据对象及结构——定义通用数据和专有数据，数据规范等等等。核心数据对象的安全要求、变更流程等。
• 用户及权限——各种层级用户的设置、数据及功能权限的定义和设置。针对几万多层次多角色用户的初始化，及日常管理等
• 产品能力模型——区分通用产品能力，还是转悠产品能力。重点关注通用产品能力的建设。产品模型样例如下。

其次是周边应用，统一采用微服务方式进行传输和沟通，这里我们接入了核心的服务有路线优化服务、图像识别服务、大数据分析和展示服务等等。

2. 移动端应用

我们80%用户使用的移动端应用，我们需要兼顾成本、用户体验等。

因为需要跨不同手机平台，我们基本上已经放弃了Native。 重点考察了当时比较流行的跨平台移动框架——Xamarin、React-Native,、 Weex等。 我们当时选择了WeeX基于如下因素，3年前的Weex与目前Flutter的类似。虽然微信在国外有一些用户，目前也不是亚太地区的主流，更别提各国的政治因素了。

• Write one, run anywhere. 写一遍，任何地方都可以运行。写一次代码，可以应用到web，Android和iOS。 开发技术非常成熟，开发效率也很高。
• Weex还有一个比较方便的热部署，我觉得很有吸引力。服务器发布js文件后，客户端用户可无意识的更新，不需要开发者做大量的处理。
• 更好的用户体验，增加一些缓存策略。

站在巨人的肩膀，帮助我们尽快完成自己的小事情，除掉移动框架搭建的时间，第一个移动端MVP一个月就上线了，1月切换了1000人来使用这个新产品，更快的界面反应，更友好的用户体验，以及用户无感的热更新，无疑是一个成功的产品。

3. 应用集成

建立统一的接口标准，所有接口通过API进行交互。定义通用API和专用API，便于性能调优。

建立API Gateway方便各相关产品的交互和应用，便于集中管理和监控接口运行情况，统一的权限管理等等。

三、组织， 产品研发

1. 产品组织

产品团队的建设不是一蹴而就的，团队的建设和成长离不开持续的努力和学习。团队经历了大致3个阶段。

1）外部顾问为主导的模式，内部团队做相应的管理和支持

在资源少任务重的情况下，我们也不得不采用外包的模式。在不清楚各供应商能力的情况下，我们不得已下发不同的需求给不同的供应商。

任务最重的时候，同时有4个不同供应商同时做不同的产品能力，给产品的管理带来了极大的挑战，从需求的分解，产品任务下发，代码合并，到代码review，产品测试，部署都面临着前所未有的挑战，非常大的管理难度。

经过几次迭代之后，基于交付质量，管理能力，配合度等关键指标的评估下，我们基本上确定下来我们的核心合作伙伴。

2）内部团队产品设计为主，外部团队交付为主

随着产品的不断推进，发现供应商人员的变动，会带走我们的核心能力，我们需要不断去做重复知识转移。

我们为何不把这些核心能力建立在内部呢？ 我们首先把架构师资源建立了起来，UXD团队建立起来，通过内部团队的不断学习，有人成功的承担起了产品经理和产品负责人的职责。参与到日常产品研发和管理管理工作中。

第三方团队主要帮助我们完成产品交付的部分。各国家的推广和支持工作也逐渐由当地同事承担了下来。当然主要是指一线和部分二线支持，针对产品的支持还是会交给我们的产品团队来处理。

3）内部团队为主，外部团队为辅的模式

随着我们产品的进一步优化，在成本和反应速度的考量下，我们开始建立内部的交付团队，重点推进DevOps的搭建，自动化测试，自动化部署的建设。

2. 产品研发

最后我们建立了以内部资源为主，外包资源为辅的集中式产品管理团队，下面是一个示例图。

核心产品团队参与每周globa和各个国家的交流沟通会议。Scrum团队自己组织每天迭代会议，遇到的任何困难和问题可以在SoS会议中一起讨论和决策。

为了便于沟通和协作，我们定义了产品需求采集设计和交付的示例流程，各级别的业务需求可以直接联系我们我们集中产品团队，每周的SoS会议会review任何新的业务需求，之后会进行需求分析、产品设计，最后交付部署。

文章来源：《数字化用户》 网址: http://www.szhyhbjb.cn/zonghexinwen/2022/0504/2685.html

上一篇：《中国互联网家居家装发展白皮书2021》新鲜出炉
下一篇：满足各行业数字化需求 戴尔商用PC再革新