关于"脚手架"式的帮助

假装这里有一张图片

"脚手架"式的帮助指的是提供恰当的指引和辅助（不多不少刚刚好），让员工能优化解决问题的方法，最终依靠自己的力量达成更高的目标，在这过程中获得能力的提升

具体如何落地，可以参考一套在培训界很经典的四句口诀

来举一个例子

产品经理计划设计一个新功能，但需要一些用户数据分析来更准确地把握用户目前的使用方式，你打算让团队新成员小王来完成这个任务

先看"我说你听"

这个步骤的目的是将任务本身，以及两个重要信息传达到位，第一是任务对公司的意义，第二是对个人的意义

"小王啊，产品经理计划做一个新功能，但他需要了解目前用户是如何使用我们系统的，通过数据来帮助他做决策（对公司的意义），相信你经过前段时间的学习，对我们系统已经比较熟悉了，正好趁此机会练练手，也好更加深入的了解我们的用户（对个人的意义）"

仅仅"我说你听"往往是不够的，信息在传导的时候是有损耗的，你表达出来的和你想的已经有偏差，听众理解到的内容更是打了折扣

接下来要进入"你说我听"的步骤

这一步的目的是确保信息完整的被理解了，当然我们不必机械的让对方把信息复述一遍，而是可以结合着实际的场景，例如

"小王，根据我刚才的描述，你觉得我们应该怎么样开始这个任务呢？有哪些问题需要去解决？"

通过小王的回答，你可以大体判断出他对于这个任务的理解是否到位，其中如果有遗漏的部分你应当及时的指出来

理想很丰满，现实却很骨感。我们的任务常常是在做的过程当中去解决没有预料到的问题，但这同时也是员工获得成长的很大机会，所以我们要进入"我做你看"和"你做我看"的步骤，这两步通常是交织在一起的

Tips: 领导还是要尽量抽时间深入到任务的具体细节中去，一来是保持对业务和技术的敏感性，二来也可以根据场景给出具体的建议

在技术工作中经常会提到review的概念，常见的有代码review和技术方案review，通常是由职能领导或者团队中的资深成员来评审，给出相应的建议

此外也存在同级之间的评审，但总体看下来效果不是很好，我个人也不是很推荐，毕竟还是向更有经验的人学习效果会更好

一个更加极致的方式是“结对编程”，即“两个程序员在一个计算机上共同工作。一个人输入代码，而另一个人审查他输入的每一行代码”，关于这个我也只是在大神的传说中听到过，目前的职业生涯还没能有幸体会，看起来对开发水平的要求应该是极高的，才能达到理想的效果

总结一下，领导对员工的培训四个步骤