中国零售业博览会2019 观后感

背景 中国零售业博览会(CHINASHOP)由中国连锁经营协会(CCFA)、北京智合联创展览有限公司共同主办,北京智合联创展览有限公司承办。自1999年创办以来,展会经历了20年发展,现已成为零售业一年一度的专业展会。 2019年11月7日-9日,CHINASHOP将在山东青岛世界博览城召开。青岛市地处东亚中部,拥有良好的零售市场环境和一大批优秀零售设备、技术企业。届时,CHINASHOP将邀请中国零售连锁百强企业、国内外优秀设施设备、IT技术龙头企业、国内外知名快消品企业、自有品牌生产代加工企业、海外商品、以及地方特色商品等厂商共同参展。以及全球范围的零售企业采购部门参观。 中国零售业博览会更代表了零售行业的前瞻性和创新性。Hi-shop专区展现未来零售缩影。行业前沿的5G应用,商业设计,物流供应链也将作为专门展示类别。 展商本次會展規模較大,因為時間原因只參觀了「国际智能信息技术展」的少部分展館。 ERP 集成商同質化严重,但也跟随时代和概念,大多可集成結構化后的客戶畫像输入并进行一些分析; 部分与阿里等大数据厂家合作,将商圈数据分析产品作为可选件,但集成商提供这个服务相信可以一定程度分摊成本; CMCC也推出了自己的大數據服務,由成都研究院開發,目前還在內部測試,已有DEMO; 平行论坛8 微信支付专场:行业化后支付时代 微信正在重点推广刷脸支付。通过自助收银、双屏POS、青蛙等设备为终端收银提供更丰富的体验; 基于卡券延展出的流量运营场景,满足零售商对转化率、成本平衡的需求; 微信基于消费触点打造的连接闭环: 潜在顾客——附近发券、朋友圈广告; 到店——进店有礼、支付立减; 支付——支付后领券。 更积极的利用支付后流量(跟随支付宝): 可向商家提供客户授权后的交易数据,但授权过程还是比支付宝要谨慎得多。; 可交易后开通会员卡; 可交易后发券; 微信正在从以下几个方面赋能零售商/服务商: 为刷脸设备提供补贴; 提供微信交易配朋友圈广告资源。 平行论坛14 百货和购物中心该经营什么?人,货,还是场? 购物中心从前是经营场,现在正在向经营人转变。 场的位置、设计固然重要,但在商场密度和同质化成都越来越高的情况,用户心智运营成为大家探索的焦点; 东百集团案例: 在百货业态下行的过程,明确顾客时代已经到来,反思自身过往对顾客洞察内功的缺失; 重新梳理营销活动逻辑:减档、减活动期,找准活动定位,沉淀SOP(Standard Operation Procedure,标准作业流程),实现活动产品化; 推动以顾客为中心的指标体系建设(纳新数、NPS(Net Promoter Score,Look at: Zhihu.com)值); 强化运营节点,并通过数据实时调整纠正; 建立收益坪效和流量坪效综合模型。 想法 热点 各大零售集团争相建立了自己的数据中台、分析体系及上层应用,大有不谈中台、不谈客流就落伍的势头; 「私域流量」成为零售行业热门词,但线下搅动这些私域流量的方法完全不同线上,不仅识别困难,触达困难,而且运营难度更大、成本更高。目前阿里、腾讯均在这块推出了类似支付数据共享、虚拟会员卡、卡券等产品; 以往的数据运营产品更适合品牌、百货、超市等业态,而阿里、腾讯针对购物中心、街区业态推出了适应性更强的产品。 误区 为了计算提袋率而去定制一个判断用户是否手提购物袋的算法。 精准客流 精准客流方案使得停留在书本上的用户画像、流量、品牌关联等概念得以数字化,是值得肯定的趋势; 精准客流方案目前均基于计算机视觉,而目前大场所的动线跟踪目前工程化程度似乎尚不理想。主要表现在为了达到精度而需要付出的成本问题; 除了基于原始理论的量化之后,对于精准客流产生的海量数据怎么利用,似乎并没有特别本质的创新; 众多表示已经实现精准客流的场所,数据生产的方式都比较值得推敲。 作为MAll品牌商,智慧商业是必须投入的: 软硬装容易过时、疲惫; 主动线设计好了,主力店的布局也不是一沉不变的; […]

在 Windows 实现 Android 一键截图

有时候工作会遇到需要频繁对手机截图,每次在手机截取后复制到电脑上并不太方便,所以打算写一个「一键截图」脚本:Windows 环境下使用批处理文件为 Android 系统截图,复制到本地,再删除手机中产生的那张截图。 这个 bat 文件首先使用 adb 连接到 Android 设备并截取屏幕,并且将图片复制 bat 文件所在的目录中,并以「screenshot_当前时间」命名(如:screenshot_2019_06_30_23_19_38),最后删除截图指令在设备端生成的那张图片。 稍微解释一下: %date:~-4%%date:~3,2%%date:~0,2%%time:~0,2%%time:~3,2%_%time:~6,2% 是用来获取时间戳并通过截取方式将其格式化。主要是利用了 %date% 及 %time%,分别获取到系统当前的时间和日期,再利用字符串截取的方式分别获取字符。 %~dp0 获取的是当前批处理文件所在目录的位置。

用户反馈在产品运营中的体现

产品设计过程的客户参与非常重要。本周将市面上面向非特定客户的产品经理(如toC产品、toB产品的主板本)的操作方式总结了一下。 当用户提交反馈时,他们想表达什么 – 仅接收反馈 大多数产品,都会给人非常强调客户反馈的重要性。但从企业角度来说,从众多的数据中提取有效信息已经非常困难,更何况还要对用户进行响应。越大规模的企业,边界越明确,让客户知道他反馈的意见被采纳是非常困难的。 比如我们在Windows、Google软件中使用的Feedback功能,通常都不会有反馈回来,至多是一封由系统自动发送的感谢信。 给予适当反馈 但在本人尝试下,发现Apple在开发者计划会和反馈者产生一些互动。比如在以下与Apple的沟通中,其告知之前反馈的一个服务端问题已经被修复,可以体验。整个反馈处理大约2天,值得称赞。但可能是根据反馈者的群体,或者针对产品阶段(比如测试阶段的产品就用户反馈方面就比较关注)来进行的,此时的反馈通道明显比正式发布后的产品要敏感,可见反馈几乎直达了设计研发部门。 Apple回复的邮件 由客户关系部门回复并跟进,运营参与 如阿里巴巴有集团级的客户关系体系。对于反馈的问题有客户关系起到上传下达的作用,同时设计有激励客户参与的运营体系。尝试反馈了一些体验问题,能从节点上看到经过了多人处理,后关闭工单。相信其也反馈到产品部门了,但是否特别重视就不得而知。 另外,看得出其有专门的反馈中台。举高德地图来讲,其意见反馈、交通事故反馈等,前端虽然不一致,但后台均通过一套中台进行流转。 高德地图的反馈及其热心客户展示 将内部信息完全展现给外部 对于很多开源社区,缺陷及意见的处理都非常及时的展现出来。而在商用软件领域,「禅道」(一款类似阿里云效的敏捷开发管理工具)曾经将其内部使用禅道的数据作为demo开放给外部用户体验。外部用户也可以直接通过查看该demo,了解自己反馈的问题在其内部的流转情况。 客户深度参与,粉丝式运营 由魅族、小米最先创建并应用,到现在蔚蓝等品牌也有借鉴的社群粉丝文化,其核心旨在让客户深度感受到其在产品的参与度。运营人员、产品经理甚至公司领导层与粉丝进行紧密沟通,降低高度,给客户机会走进研发,同时也鼓励用户之间的沟通,从而提高社群黏性并有利于发现共鸣问题。

新经济商业模式中的产品

新经济的商业模式 大约八九年前,「线上零售会不会取代线下零售」的争论逐渐开始,到如今面对身边春笋般的新经济商业模式不再好奇,人们早已习惯为了体验一个服务下载一个APP、为了「薅羊毛」而注册一堆网站、为了体验某个设备或者品牌的新店而出现在人民广场的队伍中…… 什么叫 「新经济」?粗浅可以认为是 「利用信息技术手段和互联网思维参与业务模式塑造的业务模式」。 所以并不存在线上或线下零售是否要取代对方的问题,而是新经济的商业模式如何逐步改造、渗透传统经济的主战场。 回归到最本质的销售,新经济往往是围绕:模式、体验、价格、便利四个方向单点或多点突破。 模式创新不是单点创新 在社区电商、关系电商领域,线上和线下边界越来越模糊,客户无论从APP、微信、支付宝甚至直接到线下,都是掏出手机购买,而在线下提货或由配送商配送上门。单纯的APP或单纯的服务越来越少。比如强调前置仓的每日优鲜, 通过 House + Power + APP 将品牌与其客户连接在一起,形成线上、线下一体的服务及交流体系的 NIO 。 客户无论在哪里,和品牌产生互动,都可以获得一致且良好的体验,而完全是为了商业模式设计的系统,在使用体验方面自然非常舒适,甚至大量的 BtoBtoC 最终消费者并不直接与系统产生交互。 如何为了消费者、使用者设计产品,且这个产品仅仅以何时的方式出现在该出现的地方,而不是为了项目或流程设计产品,是值得思考的地方。 标准化流程下如何做到个性化 与 toC 将用户的个性需求标准化不同, 对 toB 产品的标准化抱有过多的期期待反而可能对业务产生阻力,但适度个性化也是必要的。 这个问题本质是产品设计及技术设计能力的问题。 个人认为这方面是把握项目化 – 产品化 – 服务化及系统化 – 数字化的产品演变思路,通过积木式设计、中台、微服务、微前端的技术沉淀,对架构演变的充分拥抱,外加充分的UC、技术方案、TC三大评审,编码、测试、代码Review,灰度、运维等开发管理流程的合理设计及贯彻实现。 在产品设计上,应当注意: 需求必有故事,需求落地到具体的场景; 对竞品有客观分析,勿盲目借鉴,不伪造故事; 找寻最小单元,逻辑并行而非串行,对多个并行逻辑有缺漏时候容错设计,找寻各业务场景下的逻辑堆叠关系。同时思考后续服务切割的边界。 在管理上,应当注意: 前期设计产品的时候未来可能的修改留有足够的储备; 开发、测试参与到用户交流、设计过程,充分理解设计思维; 开发、测试根据用户故事为本,反过头校验产品的设计是否有依据。

将Python打包成可执行文件

Python 是一门解释性语言,代码的执行需要依赖解释器,而部分操作系统暂未内置对Python的支持,所以当需要将 Python 发送给别人执行的时候,打包成 exe 是一个好选择。 Pyinstaller Pyinstaller 支持 Python 2/3 ,多平台,可打包可在相同平台分发的可执行文件(如在 Windows 系统上打包的文件可以在其它 Windows 上执行)。 安装 首先,安装 Pyinstaller 库: 安装完成后,就可以对项目文件进行打包了。 打包成一个文件 main.py 是必选参数,为待打包的 python 文件。 打包过程 Pyinstaller 会在项目文件夹生成一批文件: dist 中包括最终编译的结果; build 目录下是生成的一些过程文件。 等文件。 -F 意味着将所有文件打包成一个 *.exe 文件,dist 下只会有一个可执行文件;若不使用此参数,则会在 dist 目录下生成一个和 *.py 文件一致的文件夹,其内的文件就是生成的文件。 自定义图标 -i 可以指定可执行文件的图标。无论是否打包为一个文件,都均适用。 -w 可以隐藏执行时的命令提示窗口。 其它 使用 pyinstaller 过程中遇到的坑实在不少,总结了一些经验: 自定义图标后不生效,可能是尺寸问题,根据Windows的规则,根据缩放比例不同会使用不同的图标尺寸。所以建议设置多个图标分辨率一遍覆盖各个尺寸; 有时候生成的dist和build目录并不在项目目录,可以留意是不是命令提示符处于不同的目录导致的。比如在命令提示符处于 c:\user […]

团队文档管理工具

最近所在的组织在思考需求文档如何管理,趁这个机会将自己以往使用过的文档管理一并整理,供大家参考。 需求文档的核心目的在于快速、准确的向相关方传递产品设计理念和方案。易用、快速、可传承、安全与持续维护、成本是选择管理模式的主要维度。 管理目的 需求文档管理可能是产品设计环节产品经理最常进行的工作。我们需要综合考虑各项因素: 易用 快速访问 可传承 安全与持续维护 成本 易用与效率 一个交互体验良好、稳定的管理工具和方式,有助于让文档编写人员工作时可以保持一个良好的心态,而简洁的界面也可以让人员集中注意力编写文档。 我们还需要考虑行业和组织特性:若文档涉及大量计算推导,对数学公式的支持就会变得尤为重要。对于虚拟组织或有网上讨论问题的文化,在线讨论功能就很实用。 快速访问 可传承 基于 web 的产品基本避免了对客户端环境的依赖。 对于较为较为复杂的文档可采用 word 或 axure 等较为成熟的商用软件或者开源软件,有利于避免日后依赖的编辑软件不再维护的尴尬。 但对于很多开源软件,也意味着功能较为单一和文档不兼容,再日后迁移至其它平台(比如上云)或更换其它软件会带来另外的工作量。 安全与持续维护 除了大牌且持续维护的平台,尽可能的不要使用选择互联网管理产品,毕竟组织内文档往往是重要的资产,再谨慎也不为过。 一些大牌的平台往往将更灵活的安全选项设为收费项目,当发展到一定程度(如:出现了多个项目组、较复杂的层级、需要在该平台上管理多种类型的文档)时不妨考虑。 通常也不建议将自行构建或私有化部署的管理平台暴露到公网,通常这类软件在设计都不像那些面对客户的产品那样有完善的安全策略或有足够的运维资源支撑。 成本 尽量采用开源系统 常用工具及管理方式 SVN SVN是一种开源的版本控制方法,拥有版本和分支管理等特性。每个软件行业从业者应当对其都非常熟悉了。通常产品经理们只将其作为版本管理的工具。有如 TortoiseSVN(Win)、 Versions(MAC)等客户端。基本上是0成本的管理工具。 作为最入门的管理方式,可以使用文档编辑工具编写的文档以独立文件形式存在,以一个发布版本为一个文件夹组织,以文件名进行识别,定期(如:每日、归档时)将档案提交至SVN上,以让组织内部其他伙伴可以查看。 GitBook GitBook 是一款与 GitHub 同门产品。是一款专门定位于文档管理的工具。 通过 「编辑 – 检查 – 合并」的工作流程对文档进行迭代编辑,支持 markdown, 内建简单的API文档、Q&A模版。 在内容上支持网页插入图片、公式等。甚至对于接口文档都有内置的内容块,非常实用。 免费版的 GitBook 可以发布一个公开及一个私人空间,还可以指定一个自定义域名(CNAME),作为公开的说明书等公开文档来说非常专业实用。 考虑到软件的持续迭代,GitBook 自带了「 释出版本管理」的功能,方便对同一个产品的不同版本分别维护。当新增一个版本的时,将从标记为主板本的文档中拉出分支。 […]