我已经在ThoughtWorks工作了12年。是不是有点不可思议？回首我的职业生涯，我想写一写我在这些年中经历的困难，以及总结得到的12个非常重要的经验教训。虽然我只选择了12个，但其实远远不止这个数字，但是我觉得12年12个经验教训更有韵味。
1.工具不能代替思考 在我多年的咨询工作和与许多组织和管理者的共事中，我发现了修复问题的共同套路，那就是管理人员相信工具可以“解决”给出的问题。当问题域被理解透彻，并且不可能有很多例外，以及每个人的行为方式相同的时候，这样的做法很管用。不幸的是，很多现实问题并非如此。 太多次我目睹管理者使用组织范围的工具锁定到特定的工作方式。自然，该工具未能解决问题，并且阻塞了工作的真正完成。工具应该是用来提供帮助的，用来帮助防止已知错误的，并帮助我们记住重复的任务，而不是取代思考。 2.除非管理小组能够真正懂得敏捷“转变”的价值，否则它就不能发挥作用 许多管理者都犯过这样的错误，那就是认为组织的其他部分在做出改变的同时，只有那些参与工作的人才需要“接受敏捷”。在企业中做这样的统筹需要花费大量的时间和技能，因为你要关注于同步组织在不同水平的变化。 那些想要组织的一部分接受敏捷的组织面临着真正的威胁。正如有句话所说，“要么改变组织，要么改变组织的方式。” 3.学习需要一个安全的环境 学习的必要经过是犯错误。在德雷福斯模型中，这意味着，特别是位于高级初级阶段，人需要通过犯错误来学习。但是，当人们觉得犯错会对工作造成坏的影响，会失去同事的尊重或在过程中会伤害到其他人时，那么他们就不会冒犯错的风险。 因为我热衷于教和学，所以我想办法创造了一个安全的失败空间，在这里失败的话，可以通过犯一些基本的错误来学习。 4.每个人都可以成为领导者 我以前写过这个话题的内容，因为这是一个非常重要的观察结果。我看到的一个常见的思维模式陷阱是，人们觉得为了像一个领导，你需要去担任领导的职位。但其实人们可以展示他们的领导力而不论其头衔如何，并且可以通过很多不同的方式做到这一点，只需在没有明确期望或要求的事情上采取行动。 5.架构师去写代码往往能作出最佳决策 在我运行的Tech Lead courses中，我提倡技术领导者至少将他们30％的时间用来写代码。花时间于编码上有助于建立信任，尊重和理解当前的系统。在做架构决策时，不考虑到当前系统的约束条件往往会造成错误的决定。 6.改变需要勇气 我记得曾有人谈论过XP values，其中有一点就是勇气。勇气是领导时所必须的，因为你要冒失败的风险，以及尝试一些新事物的风险/回报。没有风险，往往就不会有很大的回报。 7.建立信任的关键是言行一致 有这么一条古老的箴言，“依其言而行事，勿观其行而仿之。”在现实中，不管你说什么，人们首要的是会记住你是如何行动的。你得始终记得要言行一致。不一致的言行会损害相互之间的信任。说“no”或“现在不行”比答应做一件事却没有办到要好得多。 8.成功的结对编程与良好的协作相关 虽然不是所有的结对编程环境都是健康的，但是我相信，当结对编程有效工作的时候，团队往往具备一种更好的协作文化。许多开发人员更喜欢（长期）branch-based development的反模式，因为它推迟了反馈和潜在的冲突来源。 我把（可导航的）冲突当作协作团队的一个健康标志。推迟反馈，例如长期分支代码审查的情况往往会导致更多的不满，因为它交付得这么晚。 9.多模式思维促进更强大的结果 我在大学中最喜欢的科目之一是哲学概论，在那个学期中我们每周都会研究不同的哲学家。在我职业生涯的过程中，我渐渐体悟到多样性的价值，并且开始通过多个角度来看问题。系统思想还认识到，事实可以用不同的方式来解释，从而促进产生新的想法或解决方案。 10.认识到每个人都有不同的优势 每个人都是独一无二的，每个人都有自己的长处和短处。虽然我们倾向于寻找志同道合的人，但是拥有广泛优势的团队才能走得更好。这一区域中的优势可能会成为某个上下文中的弱势，所以当团队成员拥有更广泛的优势时，团队会变得更强大。虽然优势的差异可能会导致冲突，但健康的团队会接受彼此之间的差异，而不是憎恶差异。 11.终身制学习 世界在不断的变化，我们总有机会去学习一些新的技能、技术和工具。我们甚至可以去学习如何善于学习，有很多书籍，例如《Apprenticeship Patterns》和《The First 20 Hours》可以教你怎么做好这些。 12.积极的影响迸发幸福感 《Drive》，一本脍炙人口的书，谈论了人们如何通过朝某一目标前进而生出幸福感。根据我的经验，帮助别人找到解决方法，对他们产生积极的影响，才是幸福的源泉。 结论 以上这十二个要点并非我在ThoughtWorks的12年时间里所学到的全部经验教训，但它们确确实实是帮助我为客户服务的比较重要的经验教训。 原文：nvie.com 翻译：码农网 – 小峰 |
