惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

P
Palo Alto Networks Blog
S
Security Affairs
T
Tor Project blog
T
Threatpost
Hacker News - Newest:
Hacker News - Newest: "LLM"
C
Cyber Attacks, Cyber Crime and Cyber Security
The Hacker News
The Hacker News
A
Arctic Wolf
K
Kaspersky official blog
O
OpenAI News
Spread Privacy
Spread Privacy
人人都是产品经理
人人都是产品经理
爱范儿
爱范儿
Simon Willison's Weblog
Simon Willison's Weblog
雷峰网
雷峰网
P
Privacy & Cybersecurity Law Blog
Know Your Adversary
Know Your Adversary
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Last Week in AI
Last Week in AI
Martin Fowler
Martin Fowler
量子位
博客园_首页
Cyberwarzone
Cyberwarzone
博客园 - 三生石上(FineUI控件)
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
IT之家
IT之家
N
News and Events Feed by Topic
博客园 - 司徒正美
V2EX - 技术
V2EX - 技术
S
Schneier on Security
博客园 - 叶小钗
Attack and Defense Labs
Attack and Defense Labs
AI
AI
Application and Cybersecurity Blog
Application and Cybersecurity Blog
博客园 - 【当耐特】
Jina AI
Jina AI
C
CXSECURITY Database RSS Feed - CXSecurity.com
C
Cybersecurity and Infrastructure Security Agency CISA
D
Darknet – Hacking Tools, Hacker News & Cyber Security
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
大猫的无限游戏
大猫的无限游戏
Cloudbric
Cloudbric
H
Hacker News: Front Page
The Last Watchdog
The Last Watchdog
V
V2EX
S
SegmentFault 最新的问题
V
Visual Studio Blog
PCI Perspectives
PCI Perspectives
Microsoft Security Blog
Microsoft Security Blog

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
比从0到1更难的,是把起家打天下的产品重构一次
慕斯姑娘 · 2022-07-18 · via 人人都是产品经理

编辑导语:对于产品经理来说,很多人都会经历从0到1的过程,而比这个过程更难的,是把起家打天下的产品重构一次。本文作者分享了一个已经运转了七年的系统的重构过程,一起来看一下吧。

对于产品经理而言,很多人会经历从0到1的过程,尤其是在创业公司,如果是初创期,业务形态还很迷茫,需要从0到1;或者是新开启一条业务线或产品线,同样需要从0到1。

于我而言,从0到1的过程并不陌生,甚至积攒了一些经验。但今天想和大家分享的,是在从0到1之后,甚至这个起家打天下的产品已经发展了七八年的基础上,去重构,去给它赋予新的生命。

一、为什么要重构

要重构的这个产品表现出来的是PC客户端的形式,当然与此配套的还有两个不同角色的App端。同一个业务在不同的客户端给用户提供服务,这很常见,比如微信和微信电脑版,钉钉和钉钉电脑版。

不同于钉钉和微信在一推出就同时配备了不同端的服务,要重构的这个PC客户端其实属于公司里起家的一个产品,早年刚刚开始创业时,公司里的技术合伙人用C++的技术写出了这套系统,也正是这套系统,让它赢得了大量用户,巩固了发展的根基。

但是随着业务的发展,当前的PC客户端已经越来越不能满足更新迭代的需要,就类似于我们所说的“现阶段的主要矛盾是人民日益增长的物质文化需要同落后的社会生产之间的矛盾”。

虽然是起家的产品,但之前逻辑和技术写成的系统已经远远落后于App端的更新迭代,再加上早期开发这个平台的技术人员有的已经离开,仍还在的技术合伙人目前的精力更多在于对外联络,业务繁忙,很难抽出身来再改代码。

那放弃PC端,主营App端行不行呢,也不行。目前PC端的主要用户群体都是一些VIP级别的,占比很大。用App的可能是个人,用PC的更多是组织,日常办公中使用PC的情况更多,而且从数据来看,PC端在某些方面的人均数据是App端的几倍。

既不能舍弃,也无法继续延展,同时又有不断更新迭代的需求和紧迫感,那么唯一的方式就是重构。用新的技术框架重构现有的这套系统,让其具有很强的延展性,不论从性能还是后期更新来说,都可以有很强的全新生命力。

二、漫长的重构路

产品从0到1去做其实不难,无非是前期的方向和探索路径需要把控。而如今要重构一个7年的业务系统,就算照葫芦画瓢,也难以面面俱到。经过7年的发展,表面上看起来平平无奇的系统,其实里面包含着无数的业务逻辑和需求点。

听说在我之前有好几位产品人员接手这项工作,但重构都没做起来,我不知道这条路是否能在我这走通,但当时觉得既然这是一项必须要做的事情,一直前进就好。不求有功但求无过,没那么想赢,只是不想输。

如今回想这个过程,我觉得下面这些阶段共同构成了期间的坎坷和波折。好在一直坚持没放弃,圆满完成重构,并实现了旧版用户升级新版的更新换代,解决了这个存在许久的难题,于我自己而言也很欣慰。因此将一路走来的感触和思考分享给大家。

1. 业务庞大复杂,难以一次穷尽

前面也说过,已经运转了7年的系统,里面的业务逻辑千丝万缕。不论是刚入公司的我,还是已经加入有一些年头的其他同事,从技术到产品再到运营,都不了解其中的业务全貌。

刚接手时,领导跟我说是之前的页面样式搞得不太满意,需要重做一套,其他内容都是完备的。于是我用2天的时间比对现有旧版系统,把全部的页面原型都画了出来,至于其中的逻辑和需求点,有一位业务同事和我配合,我们一起完善。

2. 历史遗留填坑,逐条复核完善

页面有了之后,我们开始填补业务规则,找到了之前产品人员遗留下来的文档内容,最开始以为可以直接用,但仔细看过后,觉得里面的内容能用的很少。一方面是很多地方缺乏对应规则,另一方面有内容的地方也描述不畅,难以理解。

我和搭配的业务同事开玩笑说,我俩是填坑爬坡小姐妹。因为历史遗留下来的坑太大了,之前有内容但不适用的地方我们还可以调整优化,但前提是真正明白其中的逻辑,你懂了才能清晰的阐述出来,然后给研发和测试同学讲解。

还有一些是之前内容缺失,我们非常茫然。很多时候只能用App端一个个去试去看,然后反推当前的逻辑。App有两个角色版本,PC则涵盖两者角色更为综合。而且这些年App端一直在更新迭代,PC已经停滞很久,如今想一步赶上,难度可想而知。

3. 雏形查漏补缺,注释规则纠结

经过了令人头秃的逐条复核及填坑,我们认为一个雏形已经出来了,因此想和研发测试同学讲解一下,这个过程也是查漏补缺的一环。因为有的研发测试进入公司时间比较久,对于其中的一些内容逻辑可能了解多一点。

这个过程中,每个人的性格就凸显出来了。负责此事的技术负责人一直以来态度都还比较好,在我刚接手这个事情的时候,他还跟我说之前的产品人员弄得乱七八糟而且讲不清楚,导致重构进行不下去。同时也说深知此事复杂,不要太担心,慢慢来。

在第一次的讲解开会中,登录页面两个框就被一位测试同学纠结了两小时。我以为这是最简单的模块,因为一般登录注册这种已经很成熟的功能基本都不会有太多问题,但在这里是完完全全的从0到1。

当天晚上我的领导喊我一起下班,路上还安慰我很多,同时表示不必对此太在意。其实于我而言还好,因为我知道这件事情不会因为个别人的原因就中断,遇山开路,遇水搭桥,总之就是要把事情做成。

4. 确定进入研发,漫长跟进答疑

按照流程,需求讲完之后大家都没有问题,那就可以进入UI页面的设计了,当UI同学设计完全套页面后,排期进入研发。原以为进入研发后可以松一口气,但我们还是高兴得太早了。

一方面是业务规则内容太多,讲解的时候大家理解不透彻,在做的时候才发现疑问。另一方面可能当时确实存在一些地方的疏漏或者跟App不一致的地方,于是在研发和测试的过程中,疑问此起彼伏,进入漫长跟进答疑期。

其实这也是好事,相当于又查漏补缺了一遍,使其更全面更严谨。毕竟参与其中的每个人之前都没经历过,也不知道原来是怎样,所以有疑问一起沟通。遇见问题解决问题,事情才能继续推进。

5. 问题层出不穷,细节点滴更新

之前就是因为做的时候没有任何文档资料留存,导致我们在重构时两眼一抹黑,于是这次非常重视资料留存,每一个小变动确定后都会同步更新在原型需求文档中。由于测试同学可能早就写好了测试用例,因此在需求的开头也要有明确的变更记录,日期及内容等。

那个阶段我感觉自己就像一台答疑的机器,坐在工位上,每天都有研发测试同学过来问,有时候还会排队,我拿不准的就要钉钉业务同学,也就是当时的一起填坑小姐妹,我们共同给研发答疑解惑,然后把最新的内容记录留存,wiki有时候一天更新好多遍。

在最后测试阶段,大家每天都一起开会过不确定的问题,测试日日发问题,细节点滴有时长达几十个,我们第二天商议后给出答案,滚动式前进,一位产品经理,一位业务同学和二十多个研发测试,团队的力量是无穷的。

6. 新版初次试水,收集试用反馈

当新版开发完成,经历了测试验收之后,我们觉得终于可以让用户试用的时候,小范围线下找了一些用户进行试用,以便收集使用反馈。

和老版本相比,新版本优化了一些样式,很多用户反馈白色太刺眼,字号小看不清等。是我们低估了习惯的力量,老版本再陈旧,用户已经用好几年了,早已习惯了其中的风格样式,虽然我们在重构中也一直遵循原来的基调,只是稍微优化了一些样式而已。

7. 继续优化调整,惨遭更新滑坡

当时重构完的版本号是5000,由于试用的用户反馈比较普遍,以防开启升级后引发更多用户反馈,因此我们进行了优化后,让这些用户试用5001版本,之后暂无反馈。

原以为解决了上述试用反馈后,已经可以了,但事实证明,我们还是想得太过简单了,当5001的升级灰度开启后,客服那里收到了大量用户电话,因此不得不关闭升级。此次反馈的问题集中在两方面:显示问题和系统问题。显示问题相对好解决一些,但系统问题有可能和用户自己的电脑有关。

8. 派出研发亲临,现场解决问题

由于PC端的用户都是一些VIP级别,因此这次情况出现后,大家商议远程解决不了的,可以让研发同学去到用户那里进行现场支持一下,帮他们顺利升级,同时也可以亲临了解一下用户的使用情况,收集一些使用问题,放在后续版本优化更新。

9. 新版功能迭代,版本逐渐累积

与此同时新的业务叠加,虽然App和PC分属于不同的端,但一些影响较大的方面还是要保持一致。自从重构完成之后,每次新的需求,PC 和App终于可以同步了,我们相继做了后续的版本。

但是由于首次升级问题一直没解决,所以版本出现了累积叠加。虽然用户没有使用感知到,但另一条线的更新迭代一直没停,从最开始的5000走到了5010、5020。

10. 技术聚焦修复,测试没有资源

技术同学用全新的技术重构,外加繁杂的业务逻辑,有时会引起卡顿,用户反馈比较普遍,因此也一直在全力解决问题。当技术优化好之前的问题,我们以为让测试简单看下就可以继续升级了,但事情远远没有结束。

新的问题就像打地鼠一样层出不穷,无意中发现了软件崩溃,让这个系统不得不再进行一遍深度的测试,而与此同时,测试人员又因为其他紧急事项的穿插分配不出资源。最快的抽出时间也得2-3周以后,因此这段时间只能等待,技术也有了一点空档期继续钻研。

11. 漫长等待过后,新版终于下水

当测试人员终于抽出身来并且验证没问题后,新版终于可以再次下水了。在此之前我们做了很多准备,结果都遭受打击,因此这一次也依旧保持谨慎,并不可预知结果,也对最坏的结果做好了准备。

12. 疑难杂症迸发,技术加班专攻

这次的升级由于有了前车之鉴,因此十分谨慎。本来想再找一些用户试用,但由于之前的不良体验,不好找到试点用户,所以只是小小地灰度开启一下升级。开启之后出现了一个比较突出的问题,所以及时关闭了。

技术同学对这个问题集中攻破,当时询问进展时,我问今天能搞好吗,他说看情况吧,也许就在一瞬间,也许明天加个大班,说实话技术同学确实辛苦,幸亏一直都在顶住。第二天下午,收到了技术反馈的已解决,同时更新替换了新包。

13. 新版更新稳定,计划老版升新

功夫不负有心人,这一次新版用户升级新版本没有太多反馈,在新版升级完成并运行稳定一周多之后,我们计划开启老版本升级。

其实很早之前大家就一起确定过整体升级计划,一致的意见都是新版运行无问题后再开启对老版本升级新版本的操作。此外,旧版本的升级需要根据配置情况有节奏的逐步放量。

14. 连续八次放量,次次如履薄冰

老版本系统由于使用年头已久,用户对于电脑也没有太多要求,基本能正常使用即可。而此次新版本产品能否在配置低的电脑上顺利运行,技术人员心里也摸不准,因此计划先取个中间点,放入50人定向升级,没问题后再对中间点以上逐步升级。

这个过程我们自身的感受就是在危险的边缘疯狂(惊心)试探,每一次都如履薄冰,不知道这一批放量的用户中是否会出现那个不可能的点。除了早已明确的XP系统不能运行新版本外,win7,win8,win10以及对应的4G、2G、1.5G内存都成为了反复斟酌的界限。

15. 每日统计数据,时刻观察进展

这个过程中基本的节奏就是先试探性放入一批用户进行定向升级,然后过几小时、半天、一天等看这一批里已经升上去的人数,如果人数过半并且无大规模反馈,那悬着的心基本可以稍稍放下。

我们的应对措施是如果出现大规模用户反馈,那就要停止升级,然后针对性解决问题。旧升新的这个过程从头到尾进行了8个批次,人数从30、50、100、200不等,如果中间点的用户已经全部升级没问题,那么中间点之上的基本可以稍微大胆一点多放些人数。

16. 客服前线坚守,技术远程支持

研发同学根据条件删选出用户放入定向升级后,如果用户有使用问题,就会给客服打电话。我们既定的流程是,客服接到用户反馈时除了提供录屏,还要留存其QQ号,然后技术同学远程进行支持。

这其中有80%的问题通过远程都得到了解决,很多用户对于自己使用的电脑不了解,安装很多莫名其妙的软件,然后在新版本安装后遇到各种问题。15%的问题确实存在优化空间,技术同学针对性优化后,反馈日益减少。

还有剩下的5%,大概十余个用户比较顽固,就喜欢用老版本,即便客服告知老版本以后不会再继续更新,新版本的使用问题可以反馈出来,但用户依然坚持用回老版本,无奈之下只能将其从定向升级名单中删除,好在和总人数相比,这一部分人数微乎其微。

17. 最后一波放完,此事终于完满

经过之前发生过的用户集中反馈问题,后面每次放完之后,如果没有动静,内心都会有点忐忑,最开始是负责开发及远程支持的同学询问看看数据升上去多少了。我开玩笑说“看不到反馈心发慌啊,拿捏一下暴风雨是这波没有,还是正在来的路上”,他说“啥也逃不过你的火眼金睛”。

到后面,我们每次商议完这一批选的人数,都像接力棒一样大家各自站好位置。因为人数很多,每次不能太多也不能太少,如果触及到了一个新的临界点,那么通常会很小心翼翼。当还剩最后几十人的时候,感觉终于能看见曙光了。

当最后一波放完之后,对于升级的操作已全部完成了,接下来如果再有用户反馈,那就技术远程支持,好在接下来的几天,也没有太多用户反馈,只有零星的出现。这里面还有另一条线就是负责开发和远程支持的这位同学再过几天就要离职,这属于最后一班岗。

虽然即便他离开之后也会有其他同学接手此项工作,但从最开始的重构开始,他一直是主力人员,他开玩笑地说我们要榨干他最后的价值,我们说把PC扶上马之后你也就圆满离开而无憾了。

三、新生命新思路

当重构这件事完成之后,原有的PC系统终于具备了全新的生命力,作为起家打天下的产品,终于不用再落后于App端,而是可以延展出无限可能。前期重构的忙碌也在无形中拼凑出它原有的业务全貌,这个过程也让我逐步加深了对它的了解以及对业务的思考。

其实做产品到一定阶段后,就会知道表层具象的产品只是躯壳,内在的业务逻辑和商业模式才是一款产品得以发展和延续的根本和源泉,甚至是一家公司得以立足于市场并持续发展的根基。如何能在更深的层面撬动甚至联动,要持续进行观察分析和思考。

四、经历后的感悟

如今回顾这个过程,不算是太艰难的爬坡,可能是已经走过,所以并非坚不可破。于我而言是一次全新的体验,这其中有边界的延展,有了解的加深,有焦头烂额的繁忙,亦有对此事报以必成的勇气和决心。不论从事还是从人的角度,都让我有一些新的体会和感悟。

1. 事

任何事情,规划起来可以很宏大很抽象,可以夸夸其谈赋予很多表层的东西,但真正要实现,需要的是脚踏实地勤勤恳恳的付出。如果没有亲身体验躬身向前,永远不会知道其中的千丝万缕,这也是干活的执行者和不干活的领导者之间经常会有的代沟。

就像我们常说世界上没有什么感同身受,你不是当事人不是掌舵者不是驾驶位置上的人,说什么都会很轻松,可唯有经历过才会懂。真要想把事情做成,唯有坚忍耐烦。当两个角色集于一身的时候,就是我常说的,需要你既能跳出来,又能扎进去。

事情在进行的过程中或者稍有困境,最不缺的就是悲观失望甚至看衰的声音出现,放弃容易,坚持才难。在这个过程中有时候可能你自己都不知道前景如何,但只要踏实认真努力前进,遇山开路遇水搭桥,必能柳暗花明又一村。坚持到最后,一览众山小。

2. 人

不得不说,人是做事成败的很重要一个因素。我们往往说天时地利人和,不论大事还是小事,其实都需要这三个因素。当大家都迷茫时,你能拎清主线规划一条路,当遇到困难时,各个角色的人首当其冲,有时候是你给他们信心,有时是他们给你信心。

那位升级后远程支持的同学,一直也是研发过程中的主力人员。他很早就计划年中离开北京回家乡了,但是升级开启后为了能及时支持,临走前连续两个周末都来公司加班。最后那次他说:还是不放心,过来看着点吧,这可能是我为公司加的最后一次班了。

团队的力量不可忽视,另外就是很多人没有绝对的性格,前面我说的那位测试同学最开始讲解时常常让会议进行不下去,当时大家心里都会有些想法。后面接触多一些可能觉得也释然了,很多时候他也有好的一面。事无绝对,人也是,始终相信人性本善。

3. 己

反思这个过程中的自己,其实成长也很多。从最开始的迷茫,到投入,到坚定,到坚守,再到最后的回望。这可能是我经历最长的一次产品周期,也是之前从未遇到的情况。看到重构后的产品能够开花结果走上正轨,我内心很欣慰。

从最开始只是单纯接到这项工作,并不知道里面的坑有多大,内容多复杂,那时候我的领导也不知道。可一旦接手做起来就是抱着把这件事做成的态度和决心,不论中间千难万险,都想办法去应对,遇到问题解决问题,也就这样走下来了。

在重构的产品开发过程中,常有人问我,如果新版做出来用户不用怎么办?其实那时候我也不知道怎么办,但唯一可以肯定的是,新版必定要取代老版,否则无法前进和迭代。这一预言在放量升级的过程中也出现了苗头。

刚开始有一部分用户反馈很大,强烈要求退回老版本,这也是前面所说的习惯的力量。虽然我们升级的原则是只要电脑配置支持新版本运行,就不建议退回老版,但依然有十余个用户是升级钉子户,不好沟通,那就只能退回老版。

这个现象我觉得像极了《跨越鸿沟》一书中所阐述的新技术采纳生命周期,当一项新技术出现时,有创新者,早期使用者,早期大众,晚期大众,同样也会有落后者。如今来看,我们的路径和这个曲线是如此吻合。

当监测旧升新的人数已经超过80%时,我就知道此事已经基本平稳,剩下的只是收尾。用户在逐渐接受采纳,我们跨越了鸿沟断层。最难的时刻过去了。

成事带来的满足和欣慰是精神之旅的纪念品,并不是非得需要外界有形的肯定和赞赏,那是你内心深处和自己的一个交代,事了拂衣去,深藏身与名,就是这种感觉。

未来的一切还要继续,希望自己可以更加淡定从容,面对未知的一切。

一起加油,共勉!

#专栏作家#

慕斯姑娘,微信号:musiguniang,公众号:产品那些年,人人都是产品经理专栏作家,《产品经理成长进阶指南》作者。从消费互联网入行,现在产业互联网领域从事产品工作,擅长产品规划和落地。

本文原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。