专注要事、把手弄脏、高效优雅是对抗规模化焦虑的好办法--读Getting Real(达成现实)和 Rework(重塑工作)

飞机上读完了来自著名敏捷产品开发小公司–37signals的两本书,Getting Real《达成现实》和 Rework 《重塑工作》,后一本是前一半的升级版。作者是大名鼎鼎的Jason Fried / David Heinemeier Hansson / Matthew Linderman。讲述在VUCA(乌卡)互联网时代,用聪明、快速、容易的方式构建一个成功的产品。

最能够引起共鸣的,第一个是专注,专注于问题的关键,专注于客户价值,专注于要事,分清轻重缓急,敢于说“不”。第二个是“动手,别吵吵”,把手弄脏同时拥抱变化,迅速决定下一个小目标,然后完成它,从成功的成就感和经验中迭代前行。第三个是高效的适量工作远好于过量的低效工作,轻松优雅地平衡好生活与工作,在路上要不时地抬头望望天。

正巧在看到一篇文章,关于今日头条旗下悟空问答高薪挖角快手和知乎社区大V(即头部作者和活跃答主)。这些有价值的知识内容是日积月累,彼此启发而慢慢产生的。“但对于估值已经超过200亿美元的今日头条,规模化焦虑正变得越来越强烈,以至于它根本没有耐心花数年时间去经营一个可以源源不断长出优质内容的社区或者生态。他需要所有能让用户沉迷的东西,而不是真正有价值的东西,在尽可能短的时间内聚集到自家平台上来。在别人建造的森林里,寻找最粗最壮的大树,砍倒,拖走,插到自家的花园里,然后就可以骄傲地宣称:我们拥有一片最牛逼的森林,这里没有树苗,没有小树,甚至没有生长过程,每一棵树生来就是最牛逼的参天大树。”

这像极了现在火爆的敏捷培训和咨询市场,特别传统大型咨询公司,也想来分一杯羹,试图快速复制一套商业模式结合手上的客户资源,来帮助那些同样传统的大型公司来进行组织规模化敏捷转型,甚至所谓创新。可行吗?不知道,反正已经有一头大象失败了,但是还有更多的大象会想试试,我们冷眼旁观,继续做好自己的事情就好了。

回到这两本书,不论是思维还是实践,都和我们现在这个打造中的小而美的“海豹突击队”很像,也坚定了继续前行的决心,不管是领导力和敏捷教练、精益创新产品咨询、Scrum认证培训、Design Thinking等等。我们这个团队不会拒绝长大,但绝不会急于拔苗助长。踏实地开创一项生意,而不是一个臃肿复杂的怪物。多少初创团队急于扩展规模、接受投资,只会沦为傀儡,忘了初心。

读书笔记

继续阅读 More

你的Scrum迭代够精益吗?看完就全明白了

Scrum与产品创新

VUCA时代的产品

产品(Product)是用来满足人们需求和欲望的物体或无形的载体(服务)。虚拟产品和服务将会越来越多占据人们的时间。然而产品研发中,需求文档永远没法完全被理解,实际用户在看到实物之后可能都不知道自己要什么,充满交互的系统(软件系统,以及近在眼前的AI人工智能、VR虚拟现实)永远无法被精确定义和测试。产品及产品研发从来都是创新,没有哪个产品会和昨天完全一样,那样的话只要复制就行了。既然难以复制,所以如果太过关注于效率,就很难有好的效果。在充满变化和不确定性的情况下,产品研发工作会迅速地进入Cynefin框架中的复杂和混沌领域并不断进化。

enter image description here

VUCA和互联网时代,问题、方案、人员、环境很多都越来越难以琢磨,昨天的成功不可重复,甚至昨天的经验可能是明天的阻碍。所谓不确定性,其实是没有加上时间维度。学会做时间的朋友,从不确定中找到确定性,一切就容易多了。在物理学中,单独测量一个光子的偏振方向,每次得到的结果都是随机的,但是结合时间维度长期来看,测量结果是有规律的、符合概率的,于是人类就可以“控制”量子了,从不确定中获取确定的收益了。大家也可以看看《反脆弱》这本书,期权投资获利也都是这个道理。

“尊重人”与“持续改进”

30年前,流水线制造是工业社会主流,成本效率优先。两位学者Takeuchi和Nonaka于1986年在“哈佛商业评论”发表论文《新的新产品开发游戏》(用了game一词,现在的Scrum实践也称为Game Rule,这不是巧合)。开篇提到“在当今快节奏,激烈竞争的商业新产品开发世界中,速度和灵活性至关重要。 公司越来越意识到,开发新产品用旧式、顺序的(比如Waterfall/PMP/CMMI或任何预先计划的方法论)方法根本无法完成工作。需要一种整体类似英式橄榄球(Rugby)打法,球队作为一个整体,不断传球的方式。”

继续阅读 More

国际Scrum Alliance首位CTC认证者和你聊聊什么是敏捷教练

敏捷已成行业潮流,看到许多有着强烈转型意愿的组织,慢慢开始意识到敏捷教练的重要性了,但招一个也不容易,自己培养更不容易。笔者所在的敏捷教练团队,除了提供服务直接地催化客户组织的蜕变发生,另一个愿景就是:培养更多的本土敏捷教练。本文分别阐述是什么是敏捷、教练、敏捷教练,并对发展和培养给出一些建议。

(本文约5000字,阅读需要15分钟)

(原文发布于http://gitbook.cn/m/mazi/article/58c36775b7cea5d11d422f19?isLogArticle=no&readArticle=yes&from=groupmessage&isappinstalled=0)

继续阅读 More

Spotify的敏捷工程文化

Spotify是继Pandora之后,国外第二大音乐媒体网站。上一篇
Spotify的新型敏捷矩阵组织:部落、分队、分会和协会出了以后,很多人对Spotify的敏捷组织形式非常感兴趣。这里@申导 抢鲜给大家带来第二部分,关于Spotify的敏捷工程文化

第一部分主要提到基于敏捷原则,将人按照小分队Squad的方式来组织,松耦合但紧密联盟(Align)。通过内部代码开源,鼓励“异花传粉”。通过架构解耦、特性开关等手段来做到频密的小规模发布。借助自助的发布和部署服务,减少人们之间的任务交接。所有一切都关于“人”,因此组织更加要关注激励、信任与社区文化,而非等级结构或控制。

第二部分讲的是关于失败,用Spotify的创始人Daniel的话说就是,“我们要比其它人更快地犯错误”。因为失败意味着学习,因此更快地失败就意味着更快地学习,更快地改进。

继续阅读 More

精益软件度量

(题图感谢@杜伟忠)
该书由Thoughtworks的张松编著,试图回答敏捷转型中常被问到的”度量“问题。该问题常常隐藏着高级管理层的期待,但也包含敏捷怀疑者的抵触。作者从敏捷实践、团队成长、项目质量与价值等角度列出了一些手段,有一些大家都耳熟能详了,比如代码质量或故事点等。
然而,某些问题并不是那么容易回答的,或者只能用定性而非定量手段;或者反馈速度较慢。还有些问题,例如资源利用率(或人天成本等),作者恐怕也难以给出通用的答案。

此外,度量要耗费工作量,却并不产生价值;而且容易因为绩效考核的原因而走样,所以选择度量手段也需要斟酌。

继续阅读 More