Pollyanna Pixton谈敏捷领导力

个人简介 Pollyanna 致力于研究协作式的领导力模型（models for Collaboration and Collaborative Leadership）的开发已超过35年。她曾主要负责领导过瑞士电子证券交易系统的开发，还负责过过发电厂控制系统的开发，以及大型金融机构间的技术和数据系统合并。

Agile 2008是一个国际性的敏捷大会。

   

1. 我是Deborah Hartman，正在敏捷2008大会现场，和我一起的是Pollyana Pixton。早上好，Pollyana，能不能跟我们分享一下你的职场经历以及你现在主要做些什么？

我也是从软件开发那块起步的，就像大家一样，一开始我是个程序员，拿到了一些计算机科学方面的硕士学位，也研究过一段时间的理论物理学。在石油领域工作了一段时间，开发了控制半潜式近海钻井平台的系统，用来保证它们的安全，这也是我参与开发出的第一个计算机系统。随后我去了瑞士的ABB，主要为发电厂开发控制系统，在瑞士也生活了一段时间。后来又回来了，为瑞士银行成功开发了电子证券交易系统，在我去之前，这个项目已经失败2次了，现在它还一直正常运行。

   

2. 那是什么时候的事情？那时你就用敏捷吗？

1996年。是的，那时候我就在用了。但我们不叫它敏捷，因为那时还没有名字。

   

3. 所以可以说你是个敏捷先行者咯？

是的。这也是我在这里要谈到的一个话题：当敏捷到来的时候，你怎么样创造一种环境。因为敏捷已经来了。

   

4. 你指在敏捷大会上？太棒了，我很期待。你参加这个敏捷大会已经很久了吧？你看着它从一开始就百十来个人发展到现在。跟我们说说吧。

事实上，一开始也就是在犹他州当地的一个大学里面举行的，一天时间而已。我和Jim Highsmith, Alistair Cockburn，我们的两位主要发言人，一起参与了组建委员会以及安排休息时段。6年前的第一届敏捷大会，大约有300人参加，而现在已经发展到超过1500人了。

   

5. 昨天在主题演讲的时候，看到齐集一堂的景象，真的很让人难忘呀。

是的，很高兴能看到这种令人振奋的场面，还有来自世界各地的人。当你乘坐电梯的时候，你能听到所有不同的语言，看到所有人都带着徽章，太棒了，真的太有意思了。

   

6. 我昨天跟6位来自InfoQ日本的代表们一起共进早餐。能把他们请到这里来做客真是不错。你是APLN——敏捷项目领导力网络（Agile Project Leadership Network）的共同创始人之一。跟我谈谈APLN吧？

APLN这个组织把所有的项目领导者们聚在一起，主要的想法就是探索一种能够帮助他们的途径，给他们建立一个人际网络以便他们寻求项目上的帮助。因为我们大家都已经发现：项目是不可预期的，会有很多有趣的事情发生，有好有坏，所以我们希望能提供一种平台让大家来交流经验。就这样，我们建立了这个组织。大家都可以来加入我们，我们在各地都有分会，我估计现在大概有56个了，这数字也在不断变大，6月份就会有另外8个分会启动。非常美妙，今年我们在达拉斯和西雅图还召开了领导力峰会，下一站是今年9月在亚特兰大，我们也会在奥兰多召开一个关于敏捷开发实践的大会。大会面向不同的人，所以我们也正在关注不同层面的领导力。亚特兰大的那次将面向一线的项目负责人，而奥兰多那次会针对高级负责人，更多关注高管层面。

   

7. 太棒了。你召开的那些大会规模有多大呢？

每次大概在100到1500人左右不等，我们往往让会议保持紧凑，就开一整天。有的会议有多个主题，比如2个，5个等等，不同的观点，不同的演讲者。这是一个有趣的形式，演讲者是没有酬劳的，但我们会报销他们的差旅开支。所以来参加的人们都是真心实意的。尽管如此，还是有很多杰出人士前来演讲。感觉棒极了！

   

8. 我注意到你那个关系网络的名字是敏捷项目领导力，而不是敏捷项目管理。你能否告诉我为什么用这些词，它们又意味着什么？

好的，我就拿我自己作为例子。我认为管理是指管理任务、组织任务并且确保那些任务能够循序完成。领导力则关注如何掌控愿景，让团队不要偏离方向，而该做什么、何时去做，则让团队自己去决定。领导者并不去管理那些任务，相反，领导者们会帮助团队保持正确的方向，适时提问，并确保团队有获得成功所需的工具，来使团队能够顺利地把事情搞定。

   

9. 所以你组织了一系列的会议，你鼓励人们建立分会从而使大家能定期聚在一起互相交流。我也听说你很关注认证方面的事情。人们能够得到关于管理任务的认证，这我可以理解，但是你怎么去认证对愿景的领导力呢？

我们不这么做。因为有一些人提出想要能力考试或者能力认证，所以组织内部曾经就此有过争论。最后董事会决定：“不，我们不这么做。我们的成员并不想要它。”所以现在我们是这么做的，我们组织了一个有六七十人的委员会，通过Yahoo邮件组来讨论这个话题。大家的想法是去关注基于经验的认可。我们准备就这么称呼它，而不是认证。你写一份有关于你经历的材料，随后让至少3个人审阅，如果通过，那么可以认为你被认可了。这种情况下，不管项目的结果是成功还是失败，这个项目仍然可以被称为成功的项目。

   

10. 有意思。失败的项目仍然可以看成成功，能解释一下吗？

使用敏捷的优势在于：可以发现我们能否带来足够的商业市场价值。所以我们只会关注那些有用而且经常被用到的功能，约占36%，而不会去做另外64%的、那些根本没人用或者很少用到的功能。所以领导者们能够尽早发现他们是否已经向产品中注入了足够的商业价值，使其可以投入市场，而不是等到项目结束阶段才知道。他们能看清这一切，并且有把握地说：“我们完工了，我们会中止这个项目，不需要继续做下去了。”所以根本不需要等到花了1200万美元以后才发现没有价值，他们可以投入很小的一部分钱，比如200万，就能知道不应该继续做下去。市场状况瞬息万变，你可能花了很多钱做了一个不想要的东西，所以能够及时中止对你非常有利，而且这仍然是一个成功的敏捷项目。

   

11. 就是说项目启动了，只是没有给公司带来收益。那你现在在做什么呢？

我在和3个伙伴一起为Addison Wesley写一本书，应该在明年的早些时候，我们就能完成初稿了。这可是一个艰巨的任务。书名叫做《Stand back and deliver》，是关于领导力工具的，面向的对象就是那些领导者们，告诉他们如何帮助团队、如何领导愿景、保持愿景、帮助团队保持愿景、还要让他们认识到愿景，让团队明白策略、项目背景、复杂度和不确定性，帮助团队如何在这样的状况下协作，帮助团队怎么去关注商业价值。我们一直在做跟这本书相关的工作。我在很多大会上都有过很多发言，也很乐意这么做。我喜欢帮助指导别人，我喜欢讨论会，喜欢授课，所以我每个月都要讲一次课。我还和客户一起合作，深入他们公司内部，帮助他们去发现在公司里怎么样去提高生产率，怎么样使公司提升一个层次。

   

12. 你在敏捷2008大会上也要做了关于如何营造互信文化的发言，是吗？

是的，这个主题很受欢迎。《Better Software》要我给他们杂志写一篇文章，我就写了这个，随后我就在这里做了这次演讲。大家对这个话题很感兴趣，虽然我认为这是“常识”，每个人都知道怎么去做。但我猜也不完全是这样，因为大家很积极地来听这个演讲，他们很想聊聊这个话题。

   

13. 关于营造互信的文化，人们一般会问你什么样的问题呢？或者人们遇到了什么样的问题，通过互相信任可以解决？

人们开始渐渐明白，在一个互相信任的文化背景下，领导者们可以退到后面，如果你不这么做，那么你就阻碍和限制了团队的生产力、创造力和革新能力。所以如果想有个工作效率很高的团队，你就必须信任他们。而且团队中的成员应该可以互相信任。虽然你不能强迫他们信任彼此，但作为领导者，你可以营造一种文化，孕育信任，鼓励人们信任彼此，让他们有足够的安全感。

   

14. 营造互相信任的文化需要哪些环境要素呢？

安全感总是很大的一个要素。相信别人可以说到做到，人们说“我会去做这个”，你也知道他们真的可以完成。这是非常重要的。我们得消除恐惧，尽可能多地去削弱它。有时候，我发现一些组织的领导者在管理冲突或者管理大家的行为举止方面（如果你也称呼它为管理行为举止的话）非常随意。那些领导者观察他们的员工，觉得他们工作效率太差，领导就会不分青红皂白地申斥员工，于是恐惧就这么产生了。在为客户提供咨询服务的时候，如果想跟一个团队顺畅沟通，团队也需要时间适应，一般要花上一整天的时间，他们才会开始谈论关于恐惧的事情，你必须要通过交谈来建立信任，直到最终他们告诉你真相。事情的发生是很突然的，就如开关一样，只要他们开始谈论恐惧了，信任就建立起来了。我曾经在一家公司工作，在那里，有些人滥用互联网，结果所有人都不允许使用互联网来协助工作。

团队问起我的看法，他们认为我对此也有所畏惧，认为我在这件事情上不值得信任，他们很不爽。我对他们说：“其实白痴才会颁布这种规定。”他们很奇怪：“你站在我们这边？”我说：“是的，公司的做法是对我们的不信任。”第二天，他们收到了一封来自公司高层的邮件，说“我们已经开放互联网给大家使用。”就这样，团队又有了外网。他们的这些信息、领导们所做的事情和发送的消息，这就是大家传递的关于信任的信息。所以大家明白，如果你得不到正为你干活的那帮兄弟们的信任，那么也就不会有高的生产力。

大家也不会继续为你卖命。如果你想要高效率的团队，不是说光布置些有意思的工作给他们就可以了，你还得让他们做决定，让他们来选择怎么去完成自己的任务，你得信任他们能够成功交付，因为你不能整天去管头管脚。一旦你开始管得过死了，那么生产力将开始下降。我曾经遇到过一个公司，他们的工作效率低到只有20%，那里的员工做得都很郁闷。

   

15. 微观管理是个恶性循环。我把你管得太死，你也就慢慢习惯了，开始整天等着我来管手管脚。那你怎么帮助人们走出这个循环呢？

教那些领导者们问问题，而不是告诉别人怎么做。当有人来问你：“你想让我做些什么呢？是不是应该这样做？这里是不是有问题？”你可以回答说：“你怎么看？你想怎么解决这些问题？你对于这个想做些什么？”他们也会来问我：“Pollyana，你想让我怎么来实现这个？”我回答说：“你自己又想怎么来实现呢？”我聘请你，是看中你的专业经验、你的才干以及解决问题的能力，那么就请自己去解决这些问题吧。

   

16. 这种转变多快呢？

我见过最快的只要3周，整个组织都变了，是在犹他州的盐湖城图书馆发生的，那是个非常大的图书馆。领导层大概有25个人，花了3周就完成了这个转变，我也感叹：“天呢，太快了！”所以说，这种转变是会发生的，但必须让领导者们坚持下去，因为大家都想看看领导层是不是真的准备这么做。

如果你一旦让步了，帮他们解围（我们的说法是把他们“拯救”了），为他们解决了问题，那你完了，他们会一直认为你会这么做下去。有时候，一些领导者对我说：“如果我不帮他们搞定，或者不告诉他们怎么做，那我干什么去呢？”如果是一个副总裁这么说，我会答复：“你是一个价值10亿美元的公司的副总裁，我想你应该去看看外面市场里面正在发生什么，看看你们怎么能跑在前面。”于是他们说：“哦，好吧。”我很惊奇，有那么多商业前瞻性的工作，公司等着那些领导们去做，因为他们知道愿景，还负责为公司把控愿景，他们需要去开拓市场，开拓销售途径、市场途径。难以置信的是他们居然花时间去审查会计文件，并且说：“这里有个错误。”我无语：“饶了我吧！”

   

17. 但我们都还是看到很多这种微观管理。

当然，80%的领导者们还是那种“命令与控制”式的管理风格。我现在所做的工作非常有趣，因为很多人来问我，包括那些大公司高级管理层的，副总裁级别的，他们想知道：么样才能让他们的领导者们从“命令与控制”风格变成那种更加接近参与性质的风格，或者更加协作的风格，或者以敏捷的方式来领导。这也是我现在的工作。过一段时间会有更多关于这个话题的优秀文章发表，因为一个超级大公司很想尝试一下，想看看我们说的是不是有用。他们愿意摆脱以往的风格，做出改变。

   

18. 我对你用的那个短语“把控愿景”很感兴趣。能告诉我是什么意思吗？怎么理解呢？

愿景是组合体，由项目目的、交付物——也就是我们想要的结果、以及要去尽力实现的最大商业价值这些合并而成。因此，领导者们所做的就是过滤掉不符合愿景的，并且阐明：项目的目的就是要让我们在市场上能够与众不同，或者达到跟别人同等的位置，这就是目的。

所以领导者得把控这些，你得留意外面的一切。如果市场发生了变化，或者突然间你的项目不再那么卓尔不群，而是被人赶上，你就得提醒团队，让他们也来关注这个问题，并且告诉他们：“竞争对手已经在市场上赶上我们了，现在我们站在同一起跑线上。我们最好把重点放在别人都已经有了的功能上，并且抓紧时间尽快推出。我们想要怎么样呢？我们又该怎么做呢？你又需要做些什么？”于是团队也会把重点放在提问题上，任何决策都要经受过滤，回答“这是不是会使商业价值最大化？这是不是会满足客户的需求？这是不是会我们的东西看起来不同一般？”类似问题。因此领导们构建过滤器，而且提出问题，让团队去回答。

   

19. 那领导者们又怎么将思想传达给下面的开发人员，而不仅仅包括管理层？

我是通过团队协作方式完成的。当你准备对功能列表进行排序的时候，市场人员也得在场，你的客户也得在场。你得指出商业价值何在，或是对于客户、对于市场人员的价值，还有对于组织的价值。这是你的家务事。

   

20. 开发团队也在场？

开发团队也在场。特别是测试人员。我认为测试人员是功能的最后一道防线。如果你没有测试用例，代码就不能构建，也就无法加入到以构建版本中去。所以，在我看来，任何没有对应测试用例的代码都应该被删掉。这也是我在那个证交所项目中所做的首要事情之一。我不知道当时为什么会这样，就像我说过的，我们每周迭代一次，3个月为一个发布周期，我们得在一周的迭代内就准备好所有代码供产品上市使用，这很有趣。我对他们说：“如果我发现你在每周的迭代过程中做了不该你做的功能，你就不再属于这个团队，你得走人。我说过，我会给足你要求的时间。我甚至不会坐下来跟你说‘你能给我个更加好的估算吗？’”

我们有8个成员来负责为20个人来做计划，包括制定backlog、修改backlog、对backlog中的小项重新排序，还会从backlog中挑出一部分放进每周的迭代计划中去。我总是告诉他们只需要做当前迭代的内容。有个团队开始工作后，我发现了点问题，询问道：“你们在那儿想什么呢？怎么了？”他们告诉我：“副总刚刚来过，他将负责系统将来的维护，而我们正在编写与维护相关的功能。他一直在指手画脚我们该做什么。”我说：“好吧，我会去处理这个问题。”后来他们跟副总说：“你可以告诉我们你想要的，我们回去实现它，但得按照流程，把想要的东西先放到backlog。不要总是来这里干扰我们。”

   

21. 所以你提过：在做功能计划的时候，你们通过面对面的交谈来交流愿景。

是的，所有人一起参与进来。如果没办法做到，你可以使用用户故事卡片，随后把商业价值和目的写在卡片上。组织内所有人都得明白：这会让我们在市场上与众不同，不然的话我们只能做到和别人同样的水平，这样就会让我们陷入麻烦中。但如果只是在为公司内部开发一个会计系统，那么只要能跟外面市场上一样就可以了。就不应该额外增加任何功能。我知道这很难，因为程序员可能会做一些计划外的功能。我们不去做那些没人用或者只有一个人想要用的功能，但程序员会认为：“当人们用过以后，他们就会喜欢上的，这是很棒的功能，我们只要现在把它做进去就可以了。”很快你就将遇到很多这样的代码，虽然这些功能根本没人用。而且最终真正有价值的代码却因此延迟了。人们忘记了敏捷需要很好的纪律性。

   

22. 我过去在很多地方反复看到这样的情况：项目一开始，人们把愿景树立起来了，但也就仅仅在项目开始之初，以后再也没有人去关心它。这跟你说的很不一样。计划无时无刻无处不在，不是吗？

是的，计划的确无处不在，这个世界充满着变化。敏捷拥抱变化，那为什么我们认为仅仅去拥抱需求上的变化呢？我们应该去拥抱市场上的变化，我们还要拥抱团队中的人员变化，因为总会有人员流动；我们要拥抱可能造成负面影响的风险的变化，我们还要去拥抱那些防止风险蔓延的策略变化。其实这跟处理商业价值的方法一样，在以前，我们会在项目早期就判定商业价值是什么，然后就弃之脑后。现在我可不会再去说类似的事情了。

你得根据目标、条件、成本和利益来建立商业价值模型。建立好模型以后，在每个迭代结束的时候，你需要再重新检查一下输入条件，看看有没有什么发生了改变。市场时机可能改变了，因为某些原因你得晚点进入，也可能得早点，因为你听说了竞争对手的情况。你总得做好心理准备：市场部的同仁走出去了解了真实情况，回来跟你说：“我们必须改这些地方，因为竞争对手已经这么做了。”

那么信息怎么从这端传递到开发人员那端？这一切贯彻整个协作过程中，团队不断重新评估商业价值。所以在每个迭代的结束时，你根据新的模型来评估商业价值，而不是旧的。你用新模型重新过一遍backlog，重新排个优先级，这样你就不断地拥抱了商业价值的变化。

   

23. 你在很多地方接触过很多项目领导者。根据你看到的，你有什么建议给他们吗？

好吧，我觉得我的建议不仅仅是给项目领导者们的，但我们现在也可以不妨谈谈。这些建议适用项目领导者、中层管理者、也包括公司高层执行层面。就像我们正在写的书《Stand back and deliver》，你必须让你整个团队都变得有创造性，有革新能力。你必须放手让他们去做，让他们去选择他们的工作，去决定怎么来做。你得从根本上停止管得过死的状况。你不必再告诉人们需要做些什么，而是通过向他们提问来帮助他们前进时保持正确的方向。

   

24. 什么样的问题？

如果有人走到我的办公室对我说：“Pollyanna，我该怎么设计这个呢？你觉得我应该怎么去设计它？”这是我最喜欢的问题：“你觉得我应该怎么去设计它？？”我会看着他们然后说：“你又想怎么设计它呢？”要知道，这是你所热衷的项目中的一个任务，因为你选择了它，希望充满激情地去完成它，还有这方面的经验和知识，那你想怎么去做呢？曾经有个人连续3天、每天早上来我办公室问道：“Pollyanna，你觉得我应该怎么做这个？”我说：“我希望你用自己的经验、知识以及你想出来的方式去解决这个问题。”第二天，又来了，“你觉得我应该怎么做这个？”“我希望你自己去搞定。”

对于领导者，最难的部分是，他们不来办公室找你谈这些了，那么你就得信任他们能够交付成果。你不能去检查他们，然后问：“还好吧，需要帮助吗？”他们不需要任何帮助，不然他们会去你办公室告诉你“我需要别人帮忙”。当他们真得来寻求帮助的时候，你必须让他们从团队哪里寻求帮助，而不是指望你。为什么领导者认为自己应该全知全能，我现在还真不知道。

   

25. 这种问问题的领导力模式，组织高层又怎么运用？

一样的。他们也参与进来，他们一起协作，讨论什么是愿景，什么是愿景对应的目标和目的。这样，人们就有高层的目标，比如我们必须在这个领域赚很多钱。高层不需要紧跟团队。他们会和自己的上司们坐下来，同样向那些领导者们提问：“你想怎么做这个？你想我们如何达到那个目标？我们该做什么项目？那些东西又将带来什么价值？这将如何帮助我们达到目的和目标？”这是所有他们该问的。

   

26. 转换到这种新模式以后，他们感觉怎么样？

他们中的有些人觉得很不舒服，但是每个人都开始意识到，不采用这种方式，敏捷就不能发挥本该有的效果。很多领导者都告诉过我这点。在这次峰会上，他们都会发言，并且说道：“你要知道，我们要学的第一件事情就是新的领导方式。我们必须开始退到后面，我们必须把路让开。”真正的问题在于：领导者们需要帮助。他们认为他们需要去帮助别人。所以，过去的日子里，他们能发现红色预警，他们会站出来，帮助团队搞定。现在需要改变的就是，我们得关注这些红色预警，通过问问题来帮助团队保证方向正确。

但是我们不知道红色预警是什么。因为方式改变了，而且这个方式让每个人都不适应。所以很多领导者又走回了老路，那条他们熟悉而且适应的、“命令与控制”的老路。尤其对于中层管理者们来说，这是他们持续使用的方式，他们的成功、项目的成功对于他们的职业发展至关重要。他们很关注是否能让一个团队成功，但他们必须学会退到后面，学会通过提问来引导团队解决问题。我说过：控制的反面就是发现。所以如果你想让大家很快找到最好的方案，你必须让团队知道你信任他们，你相信他们能搞定。

   

27. 我们很期待明年能读到你的书，来帮助我们做到这一切。非常感谢。

不客气，也感谢的你访问。