1.不要为了发版本而发版本 版本解决了什么问题 对用户 对商家有什么帮助 这样的迭代才有价值.
App经过了这么久的演进 主要功能应该进入稳定下来的阶段 => 探索一下客户端的A/B Test.
举个例子 Instagram 版本不怎么有大变化 但一个新版本 一个小小的改动 好用 就能让用户记着
(如图下面的蓝点 之前一次发很多张会刷屏 新版本很简单的加入了一个横向滚动 很贴心的解决了这个问题)
WechatIMG8.jpeg
O2O不好做 App做为线上的入口 做到 实用贴心是我们的目标 谨慎变来变去 坑蒙拐骗 囧..
重点是线下服务的质量和用户满意度 & 带给商家的价值 这个是本质
2.去年一年客户端 服务端都很累 辛辛苦苦做出来的东西再推翻 试错成本有些高.
缺乏前期商业模型的推演 论证. 决断是快 但 也会南辕北辙.
3.产品经理不好做 在业务和技术中间前后沟通
信息从业务方传达到技术 再到成品 原始信息一路衰减&变化 最终成品不一定满足业务
怎么去做更紧凑的业务解决方案？
改善目前的产品流程(目前的流程 很标准 流水线式 从原始需求 到 最终成品 信息一路在丢失 导致最终成品并不满足原始需求)
简单的模型 :
1.原始业务需求 —> 产品/技术/设计做为整体 提供解决方案(服务设计的概念) 手绘的一起画的很乱的交互草稿(说明解决了问题 不怕乱) & 保证自己交付内容的质量 —> 通过灰度测试&测试团队 站在原始业务需求&User Trial的视角 验收项目 是否解决了问题 是否比之前版本好
2.少开会 随时随地的用Slack进行跨组 充分&高效的交流.
最后摘抄一段内容
对于某些开发每天都要声嘶力竭的说5次以上：“这个（需求）是要算（研发）成本的呀。”这样用力扣研发成本，尽量把价值低收益低的需求砍下去，把收益不明确的需求排到后面去，相当于在输出几乎不变的基础上，节约了2-3个开发工程师。这也是长期维持团队的诀窍，从源头上精简，而不是苛求超人般的程序员。
如何衡量效果，就是来判断这种需求是否是价值低收益低或不明确的项目，我们都想做有价值的东西，而不是随随便便随时准备砍掉的功能，希望产品经理敢想，而且加以思考！
不要借口说是老板需求 好的产品一定要偏执 只有有价值的需求(有利于用户or商户) 和 伪需求