2017-02-09

引入服务测试: 你提供的是服务, 但却只测试产品

缺位的服务测试 微博, 朋友圈, 各种论坛, 经常有对不同商家的吐槽, 投诉; 仔细看一下, 发现共同的模式都是 先碰到一个问题, 然后打客服电话请求解决, 没解决, 长时间没解决, 最后只好公开指责. 长时间无法为用户解决问题, 意味着商家的服务, 商家的业务流程出了 Bug. 难道不测试吗? 我们有产品测试, 但很少有人谈论服务测试. 先举一个例子澄清下这里说的”产品”和”服务”分别指代什么. 12306. 12306刚出来的时候, 其用户体验之差掀起了网络上为12306重新设计架构的热潮. 那么12306的体验到底是好是坏? 作为一个产品(网站/应用), 12306的用户体验是差的, 最初上线后并发量太大导致服务不可用, 界面半天没反应. 作为一个服务, 12306的用户体验是好的, 不用冒着寒风大半夜在马路上排队了, 可以在家里热乎乎的以各种姿势来买票. 这就是这里说的”产品”跟”服务”的区别: 产品通常是某个软件, 或系统, 而服务指的是购票服务, 上网服务, 出行服务的服务(不是端茶倒水, 迎来送往, 微笑服务的服务, 也不是客服呼叫中心等提供的服务, 这个太狭义), 也就是端到端的业务流程. 拿电信服务来说, 常见的一个投诉是未上网产生费用, 莫名其妙的被扣走高额流量费. 如果运营商在接到投诉后不能尽快查明事实, 甚至在事实清楚的情况下不能为用户追回损失, 都是服务的 Bug. 产品发布前, 都会对产品进行测试, 单元测试, 集成测试, […]

Read More

2016-10-07

会议之例会

目的 例会主要目的是合作方互相拉平认知. 会议目的通常有: 广播信息, 答疑解惑, 寻求帮助, 探讨方案, 做出决策等. 例会, 作为一种定期发生的常规的会议, 一般用于交流信息互通有无, 而不是深入探讨具体方案, 更不需做出重大决策. 其信息也更偏重重要而不紧急的信息. 因此例会主要目的是前三种, 合起来叫”拉平认知”. 每种目的的详细解释, 参见附录. 例会不讨论方案. 例会更看重广度而不是深度, 围绕着某个点的深入讨论要自行组织会议解决, 不要期望或等待例会讨论. 但例会可以公布方案. 例会不做需要深入讨论的决策, 理由同上. 但例会可以公布决策. 例会不是上下级汇报. 重点事项单独约领导汇报, 长期项目约领导周期性汇报, 例会上只是广播结论. 周例会更多是平级合作方的会. 例会不讨论紧急话题. 对于紧急的话题, 无需等到例会, 而是即时召集会议讨论. 基于例会”拉平认知”的目的, 例会成功的验收条件是: 会议结束的时候, 每个人都获得了他想要了解的信息, 想收集的反馈. (而不是 sell 了他的想法) 会议结束的时候, 每个人都表达了他的诉求, 并得到了回应: 要么被否定, 要么被接受, 要么找到了接口人会后继续沟通. 内容 认知包含: 组织决策; 业务健康状况, 风险; 项目目标和进展, […]

Read More

2016-10-05

精益创业: 如何衡量进展?

很多人可能在不恰当的实践精益创业. 下面是一组诊断题, 可以快速的验证一下你对精益创业的理解. 你汇报进展的时候, 主要是功能进展, 上线多少, 还剩多少, 什么时候上线. 你做 MVP 的时候, 抱着”先做出来看看”的想法, 并没有明确的目标. 你经常会因为开发成本的原因, 拒绝做实验; 与此同时, 很少有功能上线后会下掉. 你认为精益创业, 对创业公司才有用, 或者从头做一个产品才有用. 如果你的回答大都是”是”, 那么需要进一步理解精益创业最基本的概念.

在极端不确定的环境中, 你没办法用功能的完成情况来衡量进展, 因为很有可能你做出来的东西没人用. 此时就算你完成了全部功能, 也不能说大功告成. 那么问题来了, 在这种情况下, 我们该如何来衡量进展? 精益创业给出了答案, 就是知识, 经过验证的认知, Validated Learning. 换句话讲, 在极不确定的环境中, 真正对我们重要的, 不是完成了多少功能, 而是多少不确定的事情, 变成了确定的. 如果整个问题域有10件不确定的事情, 你已经知道了其中8件事情的答案, 那么你就可以说你的进展是80%. 因此汇报进展的时候, 应该汇报你学到了多少新知识, 而不是完成了多少功能. 如果你做了很多事, 但都还没上线, 没有获得任何新知识, 那么此时的进展就是0, 没有任何进展. 如果以”认知”为视角来审视我们日常的其它一些实践, 有助于我们获得更深入的理解: […]

Read More

2016-10-05

当谈论Feature Team时我们在谈些什么

“对手刚出了个新功能, 这个功能咱们之前也讨论过, 这次要做起来, 要快, 大约什么时候能上线?” “得去找个人做需求和设计, 还要约运营聊一下具体需求; 现在产品经理手头都有别的事, 要等; 需求出来后评审, 评审完开发, 单开发工作量, 目测三天差不多, 但得找研发负责人要资源, 现在不一定有, 要等另外几个功能做完之后, 现在每个人手头都好几件事. 这个功能同时涉及新的计费模式和账号体系, 这两个模块是另外一个部门在维护, 得出人对接, 最终也要等他们的工作量预估和排期.” 什么是特性团队? 特性团队是跨专业的, 面向最终用户交付完整价值的团队. 其核心思想, 是确保团队可独立完成手头的任务, 减少对外部的依赖. 为了能够高效的完成工作, 团队成员通常在一起面对面办公, 紧密合作, 专注的一起完成当前任务. 为了能够高效的完成工作, 团队通常有一定的授权, 能自组织的做出决策, 并对结果负责. 可能的话, 他们会保持稳定, 长期专注于相同领域的不同任务. 特性团队是新事物吗? 不是, 特性团队早就出现在社会的各个角落, 只不过有不同的名字. 第一个名字是公司. 是的, 几乎所有公司都经历了特性团队的形式, 这就是每个公司的初创阶段. 在这个阶段, 公司作为一个整体, 几乎满足特性团队的每一个特点: 跨专业, 面向最终用户交付完整价值, 在一起面对面, 专注, 拥有全部的决策权, 及承担全部后果. […]

Read More

2016-03-07

当谈论工程师文化时我们在谈些什么

“工程师文化不是谈论出来的…” “事实胜于雄辩. 但什么是事实, 则需要雄辩一番. “ 综下所述, 工程师文化是一种能力型文化, 关注可能性, 理性决策. 打造工程师文化有这么几件事可以做, 当然不限于这么几件事: 关注领导力, 选拨或招聘文化契合的工程师做Leader, 并授权 围绕着 Leader 工程师建立全功能团队, 进行课题攻坚. 打造工程师所需要的基础设施(也可以看做课题之一). 考核机制下游考核上游, 以促进专业技能提升. 建立各类工程师社区, 传播知识, 激发创新, 减少重复犯错. 招聘高素质工程师, 全栈工程师 学徒制, 设定严格职级晋升标准 网络上有很多关于工程师文化的讨论, 看这里, 这里, 还有这里. 几个频繁出现的关键词包括创造, 质量, 基础设施, 团队自治, 招聘, 全栈等. 是否有更一般性的描述? 工程师文化包含两个词, 工程师和文化. 可以搞清楚这两个词分别意味着什么, 再组合起来看看意味着什么. 先看一下”文化”. 文化四象限, A Culture Language 目前最权威的企业文化分类, 是The Reengineering Alternative中提出的模型. 在这个模型中, 作者从多种企业属性中抽取了最关键的两个维度作为企业文化的核心因素: […]

Read More

2016-02-28

学习的逻辑 3:三人行必有我徒

今天谈学习中常见的两个观念上的障碍。 障碍一 在 Z记 做精益软件度量的培训时,有学员反馈,说老师你讲的不错,内容挺好,就是感觉你之前在这方面做的不多。 这类评价我是坦然接受的,除了对那个学员有点小担心,其实自己心里甚至还有点小得意:没经验的情况下还有人觉得讲的不错。你可能会说,靠,果然咨询师都是骗子。你要真这么认为我也没办法,但我对你也会有跟对那个学员同样的担心。下面我来解释一下。 我觉得从学员的角度来讲,讲师的背景和资历,甚至能力,是不需要关注的。你只应该关心课程内容对你有没有用,有没有帮助,有没有启发,有没有学到东西。你可以做出对讲师的判断,但不要让它影响你的学习。你甚至应该有意识的剥离讲师背景对你的影响,尤其是那些可能让你产生盲从心理的背景和资历。很多背景和资历,是特意强调的,目的是增加权威性,让学员更易于接受课程内容。你自己想想,难道你会因为一个人背景显赫就完全相信他的话吗? 如果不会,那么相应的,你会因为一个人背景不明就完全否定他的观点吗? 也不会。因而既不要轻信,也不要轻视。一句话,不要因人废言。 因人废言更常见的表现形式是你不喜欢一个人,讨厌一个人,因此他/她说的话你全部不屑一顾。。。这样损失的是你自己,对你讨厌的人来说,没有任何损伤。其实你更应该师夷长技以制夷,客观的吸收点别人的长处没什么坏处,知己知彼,是占便宜的事。 这是今天要谈的第一个障碍。为了更好的学习,请不要因人废言。一句话有没有道理,跟说话的人是否是专家,没有关系。跟你是否喜欢他/她,也没有关系。保持空杯,保持怀疑,关注自己的收获,关注自己的利益,思辨的接受。我以前写书评总是说作者怎样怎样,书怎样怎样,其实更应该写的,是从书中学到了什么,对你的影响是什么。 虽然教练不必是最好的球员,但作为讲师,应该尽可能传播经过自身验证的知识。这意味着讲师必须是所讲授内容的专家。讲解其它自身认可但没有充分验证的知识,是退而求其次的选择,此时讲师扮演的更多的是 google 的角色,告诉学员有这样一些知识,这样一些他人的经验,而无法进行更深入的讨论。收到学员对自身经验的反馈,要认真考虑如何更好的服务学员。 障碍二 第二个障碍跟第一个障碍一脉相承。易于因人废言的人,对自己也特别没信心,难以通过分享,辩论来检验自己的认知。障碍是这样子的: <<学习的逻辑:知识经济学>>中提到了要分享,可人家都是高手,我刚学到的知识,对周围的人来说都是小儿科,分享是浪费别人的时间,怎么破? 且不说反馈是学习的唯一途径,分享其实是为了获得反馈,是帮助自己而不是造福众生。就先当它是为众生福祉,你也无需担心其他人不需要。下面我来解释一下。 有句话叫三人行,必有我师。而这句话有一个完全等价的表述,就是三人行,必有我徒。因为师徒必然是同时出现,互为定义的。不存在没有徒弟的老师,也不存在没有师父的徒弟。因此,如果你认同三人行必有我师的话,自然也就明白三人行必有我徒,总会有人从你的分享中获得有价值的知识。分享带有分享者自己的经历和视角,没有两个人的视角会完全相同。只要周围不都是因人废言的人,总有人会结合你的视角得出新的洞见。 这是今天要谈的第二个障碍,为了更好的学习,不要有过多敬畏之心。三人行必有我师这句话几千年来不知道妨碍了多少真正的学习,真是贻害千年。与之相伴的另外一个常见的表达是互相学习。互相学习也是一个错误的表达,为了能够互相学习,我们必须互相传授。 有个古老的寓言说天堂和地狱各有一口大锅煮着美味的汤,众人围坐在锅边每人手持一把勺子,而勺柄太长超过胳膊的长度以至于无法喂到自己嘴边。地狱的人只能挨饿,天堂的人却在互相喂食而得以饱餐,而这种意识和行为上的差别也正是他们在地狱或天堂的原因。抛开其它意义不说,它宣扬的也是互相给予才是生存之道。 这个障碍其实可以很简单的破除,就是降低分享和传授的门槛。不要一提到分享和传授,就想到PPT,投影仪,济济一堂的听众。没那么复杂,分享就是聊天。当你有一个想法的时候,随机碰到谁,就跟他/她聊,听的懂正好可以给你反馈,听不懂正好逼迫你寻找一种更容易理解的表达。而且要不止一次的聊,不止一个人的聊,聊多几次,你会发现你的想法更完整了,一些新的点涌现了。一个副作用是,在周围人的眼中,你变成了一个健谈的人 🙂 Action 结合前面两个障碍,我们可以得出为了更好的学习,可以有以下Action: 不再评价别人,而是关注自己所学。在豆瓣上写书评时,也不再写作者写的怎么样,而是写书的内容对自己的影响。 庆祝失败,庆祝被反驳,被反馈,因为你终于知道了以前不知道的东西。 20岁时跟40岁时对同一个没有明确答案的问题持相同的看法,是很可悲的一件事情,意味着你在此事上没有成长。 互相传授,三人行,必有我徒。 前同事李小波现在所在的深圳湾,经常举办各种交流活动,有一次活动嘉宾演讲主题是”当了一辈子专业经理人也没创过业,怎么辅导年轻的创业团队”,可看做对今天所谈内容的注脚。

Read More

2015-12-29

如何不用识别 C 罩杯也能买到票

12306的体验到底是好是坏 作为一个服务, 12306的用户体验是好的, 不用冒着寒风大半夜在马路上排队了, 可以在家里热乎乎的以各种姿势来买票. 作为一个网站/应用, 12306的用户体验是差的, 前几年的并发秒杀导致服务不可用, 最近的验证码. 如何根治抢票软件和变态验证码 抢票软件和验证码背后的原因, 是古老的深入人心的业务规则, 你甚至都从来不曾察觉它. 12306 用户体验的症结在于其售票的业务逻辑, 即先到先得. 这条深入人心的规则, 使一切并发模式都变成了伪并发, 最后不得不老老实实排队, 无论是消息队列还是数据库悲观锁. 12306 要想抛却严格的并发控制来提高即时响应, 必须寻找除先到先得外, 另找一条法律允许的, 大众接受的购票规则. 先到先得其实并不像它字面意思那样公平, 没有12306之前受交通状况, 以及你家楼下有网点还是没有网点等因素影响; 有了12306大家就拼带宽, 谁带宽大谁占便宜, 以前只不过是肉身排队, 现在是发送了个 HTTP 请求替你排队, 这就是抢票软件的市场, 比谁的 HTTP 请求到达的快. 验证码是用来反制抢票软件的, 却大大降低了正常购票的体验, 即使算不上因噎废食, 也是杀敌一千自损八百. 那么可能的新规则会是什么呢? 一个选项是摇号, 当然它有它的问题, 但至少它可以使抢票软件失去市场, 只剩下规规矩矩的购票软件, 也不用复杂的验证码了, 反正你只是通过 HTTP 请求报个名, 攒够了报名人数, 或者到点再开奖. 比起拼带宽, 拼软件熟练程度, […]

Read More

2015-12-29

复杂系统 II: 给你1000辆车, 你能否改善北京交通?

注: 另请参阅<<复杂系统 I: 自组织和全局优化的代价>> 复杂系统 vs. 线性系统 一堆小石头一个个砸不死人,合成大石头则不然 北京的环路有很多入口. 一个现象是入口处, 主路上车速变慢, 过了入口, 车速逐渐恢复. 如果你觉得车多是拥堵的原因的话, 就很难解释这个现象. 因为入口之后的车是要比入口前的车多的, 因为有车进来了却没有车出去, 但入口之后的车速却是更快的. 入口处和入口过后, 其实是两个系统. 前者是复杂系统, 后者是线性系统. 人们期望路上有一万辆车和一辆车时享有同样的通行效率,这类系统称之为线性系统,车辆相互之间彼此独立,互不影响. 现在的城市道路及交通规则的基础假设是交通系统是线性系统, 因此道路以及交通规则并不会随车多车少而动态的变化. 然而这个假设是不成立的. 交通系统实际表现出来的特性是某个阈值过后, 路网性能急剧下降. 实际的结果是, 这种下降可以严重到让大批车辆速度接近于零. 这就是严重拥堵. 具有这类特点的系统, 是非线性系统. 这类系统产生的原因, 是系统内部每个个体之间存在着相互作用, 而这些作用可以指数传播, 相互增强. 一辆车运动轨迹的变化, 无论是刹车还是并线, 都会影响周边的车辆做出反应, 而这反应通常也是刹车降低速度或紧急并线, 于是引发连锁反应. 所谓解决拥堵问题, 就是尽量让交通系统保持线性, 其手段只能是减少车辆间的相互作用, 没有其它方式. 车多, 路窄, 当然是车辆间相互作用增多的原因. 那么减少车的数量, 增加路的宽度, 不就可以治堵了吗? 这也是政府采取的措施, 限号, 修路. […]

Read More

2015-08-01

学习的逻辑 2: 错误的起点

<<学习的逻辑: 知识经济学>>中介绍了基础的逻辑. 本文是其姊妹篇, 进一步从不同角度来阐述. 我该学什么? 这是一个错误的问题 这个问题可以有很多出发点. 今天讨论基于的假设是对工作方向的迷惘, 即不知道自己下一步努力的重点是什么, 但又不想时光虚度, 总觉得该学点什么, 又不知从何学起. 想学习是好的, 但考虑下面这种场景. 你走进领导的办公室说: “我要加薪, 因为我参加了两个培训, 看了三本书”. 你觉得领导会答应吗? 再考虑第二种场景. 你走进领导的办公室说: “我要加薪, 因为我搞定了两个项目, 解决了三个问题”. 显然第二个场景比第一个更可能一点. 因此我们应该关注的, 是我可以有什么样的贡献, 什么样的产出, 而不是我应该学习哪些知识. 你的身价是由你表现出来的知识决定的, 不是你掌握的知识决定的. 就算我们的目标是学习, 让自己更强大, 一条更具可操作性的途径是以终为始, 先设定自己想做成什么事, 再反推需要什么样的知识. 另外一个类似的思考角度是, 你希望别人怎么介绍你. 一种是这位是xxx, 他这一生看了很多书, 学富五车. 一种是这位是xxx, 他是 yyy 产品的设计者 / zzz 书的作者… 你更希望是哪一种? 你对世界的认识和世界对你的认识都只能通过你可观测的行为来进行. 你的老板, 你的同事, 他们不可能知道你都看了啥想了啥学到了啥, 他们只能看到你说了啥做了啥. 换句话说, […]

Read More

2015-07-14

极限会议: 原则与实践

极限会议是解决开会过多, 会议效率低下的一组原则和实践. 它基于两个简单的理念: 如果一个实践是有用的, 那么我们能不能把它做到极限? 如果每个人都尽自己极限努力推进会议进程, 那么会议定会卓有成效. 会议效率是产出和所花时间的比值. 我们的原则跟实践, 有的致力于提升高价值产出, 有的致力于缩短所需时间, 有的两者皆涉及. 比如说: 如果答疑对听众是有价值的, 那么我们能不能把它推到极致? 极致就是如果没有人有疑问, 就不要召集会议, 由有问题的人召集会议, 而不是有信息的人召集会议, 把推模式变成拉模式. 如果做结论是好的, 那么我们能不能从第一分钟起就开始做结论? 如果换位思考是好的, 那么我们能不能把它做到极致, 与会人员交换立场来发言? 这类实践会比较多, 本文主要介绍在其它类似主题的资料中少有涉及的几种实践. 更全面的实践敬请期待后续介绍. 会前实践 实践: 缺省是不参会 最节省时间的方式是减少参会的数量. 对于所有会议, 缺省是拒绝参加, 除非满足以下两点之一: 你有问题想当众获得答案 别人有问题想当众获得答案, 而你有其他人没有的信息或观点 总结一下就是, 如果你可以不发言, 就可以不去开会. 不发言意味着你对会议议程和结果不会产生影响, 同时你有很多其它途径可以获得会议内容及结论. 而一个等价的关于会前准备的规则是, 要么带着问题参会, 要么带着信息和观点参会. 如果你不确定自己有没有问题, 比如会不会讨论中触发你的疑问, 那你随便, 自己决定. 开场实践

实践: 一分钟结束会议 常识是会议结束时要有结论. […]

Read More