作者列举了35岁的年龄已经不适合继续做程序员的种种原因，试图说服在这个年龄段的程序员做出改变，初一看，我自己也觉得很有道理，于是，毫不犹豫地将帖子转发至朋友圈，没过多久，一位敏捷圈内的朋友回复我了，他给的答复让我感觉有些意外：他说他会一直编程下去。我不禁好奇，为什么会有这种答复？
其实这位朋友已经不是程序员了，对他来说编程并不是工作，So，他是认真的吗？
于是我又把这个贴子转发至不同的群，想验证一下，看看究竟有多少人想一直编程。这些群里有程序员，也有从事管理的人员，有经历过Scrum转型的研发团队成员，也有传统公司的非敏捷研发团队成员，结果发现：敏捷团队的很多研发人员都反馈，他们愿意一直从事编程，与之相反的，那些非敏捷团队的研发人员没有任何反馈。
甚至，一位接触过敏捷的程序员直接在我贴子的楼上转发了另一份贴子，这个贴子的名字叫做“84岁的老程序员告诉你：年纪大的程序员去哪里了？”。
这份贴子就在我的楼上，显得那么格格不入，贴子的内容主要是Gerald Weinberg已经84岁了，与他同时期入行的程序员几乎都已经死了，他自己已经慢慢地在停止为了工资写代码，转而去教年轻人如何成为杰出的专业程序员，不过他依然会为了快乐而写很多代码。
02
那么，这些人为什么会做出一直编程的选择呢？
在哈佛大学心理学硕士、哲学和组织行为学博士Tal Ben-Shahar的研究中，他发现工作一般有3个定位：
*一部分人把工作当为差事——工作是一件没啥意思，但又不得不做的事情，每天最期待就是下班；
*一部分人把工作当为事业——工作是一个可以提升自己的平台，每天我可以从工作中学习很多新知，我期待依赖这种新知取得进步，升职以及加薪；
*一部分人他们会把工作当作使命——他们热爱工作，为能够工作感到兴奋，因为他们发现自己在改变人、环境甚至世界。
不同的工作定位，就会让工作者拥有不同的工作态度，把工作当作使命的人，相信领导一定都很喜欢，因为他们会表现得更加开心，更加积极，从而提高自身的工作动力、创造力和效率，他们从事这份工作的时间也更长，即使本职工作已经发生了变化，他也会坚持去做，不忘初心。这正如艾米和达顿（哈佛商学院教授）说的：即使在最有限、最常规的工作中，员工也能对他们的工作产生本质的影响。
03
像上文提到的那些愿意一直编程下去的人们，他们一定把工作定位为人生的使命，但可惜的是，大部分员工并不会在刚踏入职场时，就把工作定位为使命，那么我们需要用某种方式，帮助员工改变自己的工作定位，怎么做呢？有这样一则故事：
在美国有这样的工种，类似我们国内的电话营销人员，他们每天会致电给大学的校友，让他们捐款给某个助学基金。这种工作带给员工的幸福感是很低的。电话另一头的听众如果很有耐心，便会委婉地拒绝；如果不耐烦，甚至会直接破口大骂，所以这类工作的人员流失率是很高的。
当时有一位老师介入到这个公司，他的目标就是改善员工的幸福感，降低流失率。他只做了一件事情：他把这个公司的某个10人团队，与他们的目标客户聚集在一起交流，而这个客户正是曾经接收了他们的助学金，从而顺利地从大学毕业的毕业生。在短短的15分钟沟通中，那位客户真情流露，他说如果没有这笔钱，他不可能从大学毕业，他也不可能找到如此好的工作，他感谢帮他圆梦的所有团队成员。
沟通结束后，团队成员回到了自己的工作岗位，而那位老师持续收集后续一个月的产出数据，他发现这个团队比其他团队的产出多出了400%。
这是为什么呢？
其实很简单，因为这个团队成员将自己与工作的意义连接在了一起，改变了工作对于自己的定位，而那些愿意一辈子编程的人们，也一定是找到了工作的意义，因此要改变工作的定位，首先就要找到工作的意义，那么如何找到自身工作的意义呢？
方法也很简单，就是与因你工作而获益的人接触，大家可以通过以下自检表来识别自己是否接触过工作的真实意义？
这样的实例相信很多团队深有感触，当我们在赋予一件任务非常意义的时候，团队成员在完成任务过程中的投入度与专注度有明显提升，同样，当敏捷实践作用于团队时，我们通过敏捷团队研发人员与非敏捷团队研发人员的反馈不难发现，敏捷团队对待开发工作更加积极，更有创造力，工作定位更偏向“使命”，这主要由于以下两个原因：
敏捷团队相比非敏捷团队，研发人员有更多机会与用户直接接触；
敏捷团队相比非敏捷团队，用户有更多表达认可研发人员的成果和付出的机会，研发人员因此能获得更多真实的、正向的反馈；
再说一则故事：
我曾经访谈过某公司的项目成员，他在一个传统的项目组从事项目开发工作，他作为这个项目元老级程序员，看着项目从无到有的成长，并努力维系了两年，看着研发团队从6人，最后只剩他1人，现在由于工作繁重，公司终于给这个项目组配置了两个刚应聘入职的程序员。
在访谈中他说，他每天上班的第一件事情就是：打开电脑，查看项目经理发过来的需求文档。需求文档中总有做不完的需求，而且他认为两个刚入职的程序员并不能分担他的工作，项目经理只会按照规定里程碑来催促他，他也无法从项目经理获得更多的资源和协作，与客户讨论最多的是需求细节，但无法收集到对自己工作的任何正向认可，他感觉自己生活在“孤岛”上，没有安全感，很无助，他告诉我说他想离职。
后来公司开始进行敏捷转型，我有幸指导了这名程序员所在的团队，在Scrum模型的有效运行下，我看到了团队沟通更加紧密，不但团队中两名新入职的研发人员快速成长，那名程序员也变得更加积极，他与项目经理、客户有更多的互动，甚至经常相互开玩笑，那段时间程序员经常告诉我说：他很开心，工作也很有目标感，他已经通过了PMP考试，他想下次计划会议承担更多管理任务，比如帮团队拆分任务。
我想他一定找到了工作的意义。但不幸的是，由于各种原因，这个团队只进行了8个迭代，团队中两名研发人员被打散到其他项目组中，这个团队又只剩他一个研发，一切又回到了从前，不久后，他正式提出了离职。
04
在互联网公司中，获益人群往往是用户，而创造用户价值的一线劳动者则是研发团队，在传统瀑布模型下，需求从用户提出直到下发至研发团队，需要经过多个阶段多个角色的转换，而且需求至上线的周期很长，往往只有最后上线前，才能获得与用户接触的机会。这种“闭合机制”,研发人员在整个过程中，极少有机会与客户直接接触，几乎不能直接获得用户的反馈，一旦获得，如果又都是消极的反馈信息，这会极大打击研发人员的积极性与参与度；
敏捷团队有更多的机会与用户接触，在Scrum模型中，用户可以参加展示会，在展示会中，研发团队会直接向用户展示近一个迭代的产出，用户会直接给出自己的反馈，另外只要条件允许，用户甚至可以参加Scrum其他会议，例如：回顾会、站会以及计划会议。这种做法，会使研发团队逐步成为一个开放的系统，而开放的研发团队比封闭的研发团队有更多的几率获得客户群体的正向反馈，团队成员也更愿意、主动从事与自身工作意义相连接的任务。
值得一提的是，在Scrum模型中，大部分的团队会邀请用户参加展示会议，这种做法很好，毕竟可以增加研发团队与用户接触机会，但是收到正向反馈的信息可能较少，因为会议大部分时间用户都在校验当前迭代的产出，挖掘改进点。我的做法，也就是在条件允许的情况下，尝试让用户参加回顾会议，通过我的观察绝大部分用户在正确的回顾会议议题驱使下，一定会在提出改进建议前，提出正向认可的信息，这些认可很可能会给研发团队莫大的鼓励。
总结
作为敏捷的推动者，我们需要面对不同的人，不同的阻碍，如果我们没有找到这份工作的意义，也很容易失去对这份工作的兴趣。有机会可以回访自己曾经指导过的团队领导，最好该团队的敏捷转型是成功落地了，那么你会发现：你改变的不仅是团队，不仅是传统，可能你正在改变世界。任何工作都是如此。