Brenda的敏捷沉思录

      实施Scrum这么久，大多数时间花在帮助团队更高效的产出上。最近参加了一些Conference，和一些身边的人聊了一下之后，发现“明确要做什么”也许是比高效产出更重要的东西。或者说，如果能明确需要做什么，也许高效的产出也就自然而然了。

      有一个很简单的问题：“每天你花费多少时间在搞清楚要做什么事上面？”其中包括理解需求、理解需求背后的出发点、理解需求的细节、验证需求理解的正确性、反攻那些理解错的需求等等。我问过很多开发人员这个问题，很多人的回答是：一半！这是一个很惊人的数字，如果能更好地沟通清楚要做什么，是否我们就能瞬间提高许多生产力？

      我们先撇开敏捷或者Scrum不谈，软件开发无非就是先知道要做什么，然后做出来，两个环节缺一不可。但是目前许多软件公司的管理思路都重于后者，开发经理和开发流程的存在都是为了保证可以按时把东西做出来。回想一下软件开发的过程，开发人员都会有这样的共鸣：“如果真的知道要做什么地话，做出来总归应该是没问题的，最怕就是做着做着，老板们的思路又变了。”这一方面说明软件开发变化是本性，另一方面来说，澄清需求本身可能是比交付软件更困难的事情。

      Scrum中的需求管理也就是一份Product Backlog，优先级排序的需求列表。至于这份列表是如何得出的，并没有定义，或者故意不定义。对于刚刚转型做Scrum的公司来说，新的PO要定义清楚这份Backlog简直难于登天。为什么难？因为PO不非常明确产品的大背景和具体的需求细节，也就是PO也不清楚产品要具体做成什么样的。那为什么不找个合适的PO？找不到真的懂产品而且还能和团队天天在一起的。这是许多公司的现状！所以需求没法澄清怎么办？得找到各种各样的老板一起决定要做什么？决定错了怎么办？再找到各种各样的老板觉得怎么改。下面的团队于是就天天跟着团团转！如果这种现状不改变，用不用Scrum，有没有PO都没有多大分别。即使强行用了Scrum，PO也是个伪PO，后面许多人“垂帘听政”。

      产生这种情况的根本原因是整个部门或整个组织对所缺乏对所做产品的整体理解。再问几个简单的问题“你所做软件的最终用户是谁？”“他们为什么要用你做的软件？”“你现在所开发的功能能带给用户什么好处？”有多少人（包括开发人员和经理们）能够信心满满地回答出上述三个简单问题？我所见到的很少。大多人在讨论的是几月几号有deadline，而很少讨论所开发的东西。这点很悲哀，我们在不断被逼着交付着我们也不知道为什么要交付的东西。那如何能敏捷？如何能高效？

      要改变这个现状，很简单，就是让开发人员了解自己的产品。最直接的就是使用自己的产品，这点对互联网公司可能比较容易，但是大型设备公司，如电信产品就会比较困难。做不到的话，用视频或者lab实验的方式也未尝不可。另外，要把产品的长期规划和短期规划公开出来，显性地让所有开发人员都知道，这样大家才能有共同的目标。在大多数公司中，这些信息都隐藏在少数人手里，管理层认为没有公开的必要性。如果能做到这两点，接下来应该让团队知道当前的交付版本对产品对客户会有什么增值，为什么我们在某个日期需要交付这样的功能。特别是在交付压力很大的时候，更要让团队知道此次交付的价值或者重要性。如果这三点都做到了，再来讨论团队工作的效率和积极性也不迟。

      总结来说，让开发人员知道他在开发什么是软件行业中生产力的前提。可惜现在许多公司忽视了这一点。如果公司想做敏捷转型，想要高效，那就先要把产品带入人心。如果每个人都为他开发的产品感到自豪的话，团队不高效也很难！

      敏捷开发中的管理者和传统开发模式中的管理者有很大不同，不是指挥控制型的自上而下的管理，而是支持型的自下而上的管理。对于管理者在敏捷开发中转型的话题，也一直是社区讨论的热点。信任、授权、扩大团队的责任范围，都是普遍认同的观点。

      春节期间，闲来看了一本《西方管理学摘要》，惊奇地发现，我们现在讨论的东西，早在半个世纪前，已经有许多先人研究过了，并产留有许多著作。其中两篇文章另我印象深刻，第一篇是：The Human Side of Enterprise（Douglas M. McGregor）。 里面总结了传统的管理方式：基于人本性是懒惰的，需要指挥和控制才会工作。并从马斯洛的需求层次理论出发，分析了传统管理方式的错误假设。马斯洛的理论提出：人有不同层次的需求。自底向上包括：生存的需求，安全的需求，社交的需求，尊重的需求和自我实现的需求。基于这些需求的层次，马斯洛提出了两大假设：

• 人只有在较低层次需求被满足时，才会追求高层次的需求。
• 已经满足的需求，不再能够对人起到激励作用。

传统管理方法仍然试图以低层次的需求来管理员工，包括扣工资，辞职的威胁等惩罚措施。但在现代社会中，人的需求层次已经上升至高层的需求，底层的需求能达到的激励作用是有限的，甚至是负面的。只有使工作性质应对人的高层需求，才能真正地激励起员工。由此，文章中提出了新的管理方式：基于人的本性是愿意为自我实现而努力的，管理者的职责是引导员工，把公司目标和员工个人目标联系起来。要实现新的管理方式，需要对员工更多的授权，扩大员工的职责范围，对员工提供顾问型支持等等。为了防止贴标签，Douglas把传统的管理方式简称为X型，新型管理方式为Y型，XY型模式也被后人广泛引用。

      另一篇文章是：One More Time: How Do You Motivate Employees? (Frederick Herzberg)。文章提出，使员工满意的因素，和使员工不满意的因素是无关的。减少员工不满意的因素并不能提高员工的满意度。比如，监管制度是导致员工不满意的重要因素。但减少监管，只能使员工的不满意降低，而不能使员工更满意。这类因素，叫做保健因素，类似于马斯洛理论中的低层次需求。真正能提高员工满意度的因素，叫激励因素，类似于马斯洛理论中的高层次需求。其中包括，成就感，认同感，责任感，成长等等。文章中也以一个案例和相关数据与图表来说明，增强那些激励因素，在一定时间内，确实能够提高员工的效率。

      综上，自底向上的管理并不是一个新的概念。但这个概念的实施却在当今社会仍然不够普遍，以至于人们继续在讨论它。究其原因，在于观念的改变需要很长很长的时间。好比中央集权要分散权力，绝不是一件容易的事情，无论是从集权方，还是授权方。敏捷社区对管理理念的关注，可能只是整个社会观念改变的一个缩影。当前，需要更多的成功案例来给整个行业更多的实践指导，也需要一批开明的管理者引导整个行业的改变。

　　乔布斯说: 对一千件事情说不。“我对做过的事情感到自豪，但对决定不做的事情同样感到自豪。”乔布斯专注于打造设计简洁的产品。从iPod到iPad的设计，从苹果产品的包装到网站功能，在苹果的世界中，创新意味着消除多余元素，凸显必要元素。对一千件事说不，才能对一件事情真正说是，把事做大。

　　看完这句话，我首先想到PO对Backlog的排序问题。很多人在听到Backlog中没有两项东西优先级相同时，都会犯迷糊，对全部需求的排序更是无从着手。我觉得“学会说不”是一项很好的技能。在排序的时候，先不要想我要让团队做什么，而是想我不要让团队做什么。敏捷原则中也有一条这么说：

　　也就是说，要最大化不做的东西，而专注在少部分真正需要做的东西上。

　　对比苹果产品的设计，国内的软件设计可谓“很不简单”。至少随便登陆几个著名的网站，就会发现信息像蚂蚁一样扑面而来，用户完全不知该如何下手。那为何会产生这种情况，又如何来解决这个情况？

　　最近朋友推荐了一本书《About Face 3.0》，是一本专门介绍用户交互设计的书。里面说到很少有数码产品关注用户真正需要的东西。比如你用一个编辑器编辑文字，如果你想要改变当前文件的名字，你只有两个选择。第一，选择另存为另外的名字，然后删除老的文件。第二，保存当前文件，关闭当前文件，回到文件夹中重命名。这两种选择相对于用户改变文件名字的需求来说，都太复杂了！

　　究其原因，首先是对于用户行为理解的缺乏，其次是交付压力让人忘记了主要目的是满足客户需求。这两点，在大部分软件公司都成立。而且如果这两点仍然成立，那Scrum或者任何敏捷开发模式都给不了太大的帮助，充其量增进用户反馈而已。关键在于PO这个角色如何定义需求。如果真正能对一千件事情说不，把所有精力放在一件事情上，从学习了解用户的行为开始，把一件事情做到位，那就是一个好的开始。我很希望哪天看到腾讯或者新浪等热门网站的主页内容能缩减99%！

　　最近仔细研究了一下网上关于海底捞管理模式的文章，发现和敏捷精益的思想有很多相同之处，简直就是敏捷精益思想在饭店管理业的实践！当被视为高端的IT业还在讨论自组织团队是否可行的时候，海底捞已经用事实证明了未受过高等教育的劳动力，授权后后被激发起来的创造力也是无穷的！

以人为本！敏捷和精益都强调以人为本，让人自组织，激发人的主观能动性。海底捞在这点上，已经做到了极致！

　　人是海底捞的生意基石。服务员都能“用心”是基本的经营理念。海底捞虽然是一家火锅店，它的核心业务却不是餐饮，而是服务。因此在将员工的主观能动性发挥到极致，才能更好地服务于客户。为了达到这一点，除了保证员工的生活无忧之外，“授权”是管理制胜的法宝。在海底捞，从管理层到普通员工，都拥有超乎一般餐饮店员工所能得到的权力：200万以下的开支，副总可以签字；100万以下的开支，大区经理可以审批；而30万元以下的开支，各个分店的店长就可以做主。就连普普通通的一线员工，都大权在握：他们可以赠送水果盘或者零食；如果客人提出不满，他们还可以直接打折，甚至免单！

系统思维。在一个复杂系统中，每一个现象都是由于许多原因导致的。真的要评价一件事情的好坏，只有自己看了才知道！

　　店长不对门店的营业额负责。没有人对营业额负责。因为营业额是许多事情决定的，比如如果店址选得不好，店长在努力，营业额也不会好。与业内通行的营业额与利润来考量店长不同，客户满意度和员工满意度决定了海底捞对一个店长的评价。即使这两项指标也没有标准和量化。那具体如何评价？“我到店里转10分钟基本上就会有个判断”。

自动化。软件行业中自动化的目的是让人可以解放出来做更多有价值的事情，在海底捞也一样！

　　海底捞也在门店配置了各种现代化设备，以最大程度减少员工的工作量。这些做法的目的只有一个，使员工能有更多的精力让客户满意

质量是根本。敏捷和精益都强调可持续发展，在发展的同时，质量是必须保证的。这点，海底捞做出了很好的榜样！

　　要提高服务质量，我们在利润上肯定会受到损失，但我们的服务让来过的客人以后常来，把等候的客人都留下来，翻台率不断提高。由于固定开销是不变的，翻台率越高，我们的利润率就越高，我们赚的就是翻台率。

　　当然，海底捞的成功不是一夜暴富，而是15年服务意识的积累。海底捞对扩张也极其慎重，不会因为想要快速扩张而丢失了企业精神。短期利益和长期利益之间如何把握？海底捞给了我们一个具体的实例。

　　说回到软件业。很多人知道质量的重要性，知道人的重要性，知道自动化的重要性，知道当前度量的不合理性，但就是无法摆脱当前的工作方式。根本原因就在于在短期利益的诱惑下，无法平衡长期利益。我们现在要交付，项目要结束，为此不惜一切代价。长期利益在交付日期前永远是低优先级的。如此，那些质量，人性之类的东西就被一次又一次地扔在一边了。这些东西一旦丢失掉，要找回来就很困难了。。。希望海底捞作为一个可持续发展的成功案例，对软件行业也有借鉴意义！

　　敏捷圈的人都知道，技术债务是不能欠的，利息比房贷还高很多。而且一旦开始欠，就会越欠越多。所以，敏捷的原则告诉我们要稳步前进，在保持当前功能交付的同时，还得保证不欠下技术债务。这就意味着，不能以牺牲质量为前提来赢取交付时间。不然，从长远来看，对产品的发展不利。

　　但是，如何把这个概念介绍给产品经理、销售、高层经理等与技术无关的人员呢？

　　最直接也是最有效的方法就是用数字说话！由于这次需要在这个时间点交付超过团队正常速率能交付的功能，首先，我们承担了交付延期的风险，这个风险的可能损失是多少钱。其次，我们如果在将来需要把这些债务补回来，需要额外投入多少开发成本。然后，如果债务没有及时偿还，我们的维护成本会因此增加多少。最后，由于我们潜在的质量问题，有可能损失多少客户。把所有的这些加起来，估计一个价钱，告诉相关人等，让他们做一个决定。

　　很多时候，业务人员和管理人员在push技术人员多做工作的时候，并没有意识到技术债务产生的额外成本。由于软件的复杂性和虚拟性，也很难让他们看到或者感受到技术债务是什么。这个时候，开发团队就有责任找到一种交流渠道，让他们知道技术债务的风险。钱，或者说数字，就是一种很好的方法。

　　世面上也已经有相关的工具评估技术债务，如Sonar：http://www.sonarsource.org/evaluate-your-technical-debt-with-sonar/。如果还没有方向如何评估技术债务的话，可以从这个工具开始得到一些数据。然后，慢慢把这个理念传播给更多的人。