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