——读《终身成长》(mindset )有感
原文发表在 个人博客
结合 卡罗尔·德韦克 的《终身成长》谈谈工作中如何应用成长型思维把控工时预估。
- 固定型思维：认为才能和水平是固定的。
- 成长性思维：认为才能和水平是变化的。 二者区别的关键，把一个事物看成固定不变的还是发展变化的。
📺 情景设定
老大交给你一个任务，你估工时后答复说3天做完，+1天给测试同学。做到第二天的时候，觉得好像三天做不完，于是第二天加班搞，第三天你很累，白天的工作效率降低了。第4天下午终于提测。从第二天开始，你精神一直绷着，还搞了个通宵，难免有些心力交瘁。
代码交付测试你想喘口气，测试同学发现一些问题，你要尽快修复。他提出一个你改一个，问题并不不难解，数量却不少，在不断的 fix 中，进度又拖后了半天。你有点懊恼：明明自己能力是足够的，只要认真点就能避免的，当时到底是怎么了会犯这样的错误。你说下次要加倍努力，让自己进步。同事喊你出去划水，你欣然答应，好像刚才懊恼的人并不是你。
过了一周，老大又交给你一个类似的任务，而你，又上演了类似的表现，唯一的不同是，这并不是第一次。
📡 说说这里面的问题吧
首先，你认为的三天能做完，是在什么样的假设下呢？你看了这次的需求，将几个字段在客户端前台输入，然后后台存起来。下一次访问页面的时候，要把之前存的内容展示出来。这是你熟悉的功能，上一次你只用了一天就做完了，这一次加一天仔仔细细的自测，再花点时间思考代码可复用性，甚至你还能预留一天时间划水，是否帅气的在提测邮件里加上一句“提前一天提测”完全取决于自己的心情了。Perfect !
典型的人月神话问题。
工时估计不准确，并不是问题。你的脑袋随时会像一团棉花一样变的混乱，临时会有打断你的事，会发现项目功能潜藏的判断逻辑，等等，都是你预料外的变量。此时怎么能咬定说计划3天一定能完成呢？几乎所有事情都在变化。
我们的工作环境里充斥着这种“说到就一定能做到”的暗示。你的老大可能分享过一个故事：他做一个项目，答应客户一个月交工，中途同事离开，项目进度延误。在仅剩的最后一周里，他连续加班，力挽狂澜，如期交付，还得到了客户和领导的一致好评。除了热血沸腾的个人英雄主义，这个故事有没有给我们传递什么不对劲的逻辑？有。
你做到了，是因为你努力，如果你没能做到，那就是你不够努力。换句话说，努力是你“做到”的重要要素，我同意这个说法。但这个说法会有副作用，它在传播的过程中，会演变成“努力是唯一要素’。毕竟人脑记不住那么多细节，你只被强调了这一个词语，当你回想起如何才能加快项目进度时，你只想起来这一个词，那它就变成了唯一。
我觉得上班时间本本分分写代码，适当的劳逸结合，不偷懒划水，可以算作努力。那种加班透支体力的，本应叫玩命。在这群努力的工程师队伍里，很多人还是保证不了项目进度啊，这和开发过程中的变量事件紧密关联，唯一确定的是一直不确定。所以我的结论是，
😎工时估计不准确，并不是个问题，而是个事实。认为一个变化的事情是不变的，才是问题。
再说第二个问题吧。错误的将进度与工作量混淆。你是个人，并非机器，加班意味着效率变低，所以并不是通宵加班一晚就可以完成1个工作日的工作。类似的，并不是加上10个人，就可以把项目耗时缩短十分之一，人多了，沟通成本陡然上升，情况并没那么乐观。所以，
😎认为工程师的生产力一直能线性输出，才是问题。
接下来，测试同学提出一个问题你改一个，如此被动的工作方式，一定存在某个问题。你懒，懒的天性？有没有人给你分析过，你为什么懒？如果你觉得完成工作是一种“finish”，那你的代码版本就成了“final”。代码提测的时候，你认为它结束了。既然能跑通了，再做改动意味着测试同学要重新覆盖case，你也可能引入新的bug，所以权衡利弊之后，把代码搁置一边是正确的做法。除非程序跑不通，不然就不改这种省时省力的想法，把你的懒惰伪装成“精明务实”。
听起来没错，不妨听听另一种工作方式。你暂时把代码交给测试了，提测邮件里你提到了“手机号号段近期可能增加，该功能的手机号判断的正则表达式需要搜集资料加以完善，会继续完善，辛苦测试同学持续关注”，虽然代码提交了，但你继续 review 自己的代码，知道再也找不出问题，你才放心的把手挪开键盘，此时测试同学告诉你，测试过程中问题很少，可以上线了。你心想，不是问题少，而是她测试的这段时间，我默默修复了自己的尚未被发现的 bug。你清楚的践行着，没有完美的代码这句箴言。
两种方式的分叉点在哪里呢？在于你“提测”的一瞬间，是否觉得代码完全完成了。通常我们说提测或上线就算完成了，但你的代码总归还有机会被优化的，所以严格的说并没有结束。套用之前的话，懒只是个现象，
😎觉得任务完成了就是结束了，才是问题。
PS：两种思维模式还带来了不同的工作反馈，前者觉得做完了让人兴奋，后者觉得不断优化让人兴奋，高下立判。实际工作中，KPI、目标导向实际上培养了更多前者。
下一个问题是，你认为自己能力足够，却总是犯错，所以感到懊恼。这反映出你是典型的固定型思维模式。你觉得当下你的能力是固定在一个level的，低于这个level的任务，都该被你完成，如果完不成，你就归结为自己不够努力。世上那么多事情不能被人控制，除了你自己，但现在你连自己也控制不了，所以你懊恼😡。持这种思维模式的人在成长上会固步自封。一旦项目上线，他们觉得木已成舟，值得自己付出精力的最近一次，是下一次开发的时候，而不是现在。所以他们忙着休息，却没有及时反思自己的工作方式。如你所见，下一次机会来临，他还是会陷入到捉急的泥沼。
拥有成长型思维的人则不同，因为坚信能力是不停发展变化的，所以他们更能在任务更替的间隙里，回头看哪些地方做的不够好。大部分成长，发生在不工作的时候。当你有适当的空闲时间并且合理利用的时候，才是成长发生的时候。所以回顾下这里的问题，
😎任务告一段落后，不知道及时总结提高，才是问题。
🦆 总结下刚才的核心思想
你能否按时交付足够质量的代码，取决于你是否用发展变化的眼光看待开发过程中的所有要素：你的能力本身，你的身体和大脑状态，需求随时可能变化，你的同事也许正准备请教你问题等等。如果你天真的觉得其中一个是恒定不变的，那你的工时估计就是有相当风险的。
PS：别觉得不懂技术的项目经理就不能很好地管理项目以及管理你，单纯的技术能力对项目进度的影响，没那么大。
扩展阅读
-
《终身成长》——卡罗尔·德韦克
-
《人月神话》——布鲁克斯
