背景
前段时间，项目上一大波新人袭来，恰巧前后两人需要入职我所在的团队，由于团队中已经存在比较系统的新人项目引导(on boarding)流程，其目标是指导新人自行完成项目引导，由于正值项目紧张的特殊时期，我只觉分身乏术，便和新同事讨论决定采用“自主学习，定期跟进”的方法，即，由新同事根据既有流程自主学习，我们每隔两天进行讨论回顾，发现和解决问题。然而，结果并不乐观，其中技术经验尚浅的同事在无人干预的情况下，几乎无法取得进展，而在和另一个有十余年工作经验的同事在讨论中发现他也不能完全掌握其中的知识点，且对其中几个部分有很多疑问。这不禁让我心生疑惑，究竟是新同事的能力问题还是这个新人项目引导教程存在缺陷呢？
问题
忙完紧张的项目之后，我随即将工作重心转移到了帮助新人项目引导和个人成长方面。俗话说，事非经过不知难，我决定自己走一遍现有的项目引导流程。
首先找到现有文档，它是一个看起来非常完备的文档，包罗万象，从业务知识、技术要点，到部署策略、安全开发，无不提及。其中，外链近百，链外加链，若是新人采用广度优先方式学习还好，若是深度优先，怕是爬进某个官方文档就难以爬出了。
再看项目代码的引导部分，切到作业练习分支后，发现这里的信息也很多，读完后对需要完成的任务不能清楚地理解。随即我试图通过阅读代码寻找到任务的蛛丝马迹，却依然雾里看花。最终不得不试图将网站运行起来，结合这些文档，理解究竟需要做些什么，然而首页是红通通的500错误码。而在任务过程中，当且仅当每一步都正确时，才能得到正确的结果。这期间没有明确的检验机制对任何一步进行验证，这使得任务难度大大增加，且与TDD实践和快速反馈相违背。
图1 新人面对繁杂的知识无所适从
此时，我几乎可以想象新人们内心的无助和惶恐，以及为解决这些困难所付出的努力。
与其这样，不如手把手地带两周，对新人来说，也许会有更好的体验。
不过既然已经发现了问题，我决定帮助团队对项目代码的引导部分进行改进，使其能够真正承担预期的职责。
指导原则
作为新人的项目引导，对新人来说是学习和信心建立的过程，对项目来说是分享和吸纳血液的过程。它们相互增益，互为助力，使新人为新项目做好准备，而项目则获得新的创造者。
它有别于项目其他工作，诸如调研新技术、帮助项目改进技术架构、寻找新的商业机会等工作需要对项目足够了解、对技术足够深入，从而跨越平庸，创造更大的价值。相比之下，新人的项目引导，其着眼点主要放在了解是什么、为什么、怎么开始。只要跨过这一步，就可以发挥其主观能动性，成为项目的独立贡献者。
因此，我希望引导教程能够在知识传递的同时不做太过深入的引导，并保持友好：
-
提供足够且刚好足够的知识，并学以致用
-
循序渐进，快速验证
对于第一点，抛弃大而全，采用小而精的方式，有针对性地对项目知识总结陈述，有层次地进行任务设计，将领域知识和技术难点融入任务，使每个任务重点突出，只有理解了这部分知识才能正确完成任务，而提供足够且刚好足够的知识，意味着知识域和问题域的闭合，即通过设计限制学习时间，避免发散和浪费，完成任务即学会知识点。
图2 足够且刚好足够的知识
第二点也很重要，它有助于提升用户体验，由浅入深，循序渐进，避免陡峭的学习曲线，这在入门时能有效建立信心，实现快速启动。
教程设计
目标
通过该新人引导教程，使新人能够在没有或尽可能少地提供帮助的条件下，在有限时间内自主学习，掌握项目背景知识，完成独立工作的技术和业务储备。
这个目标不能解决所有问题，仅用于解决新人不知道自己不知道什么，或面对一切未知无处下手的问题。它用于储备基础知识，从而能够在之后理解和参与团队讨论，阅读和理解既有代码，渐进地扩大自身知识领域。
层次
我和使用过现有引导教程的同事聊了聊，试图了解更多痛点，发现了以下几个问题。
-
对业务不熟悉，尽管有文档，但数量过多需要大量时间，短期内难以学习和掌握
-
项目代码库太大，不了解代码结构，阅读代码不知从何读起
-
第三方框架的文档不完备，仅靠文档无法学会使用方法
因此，在教程设计时，我打算增强代入感，分层进行任务设计，
-
首先，将新人从现实生活带入项目的业务领域。这个过程代入感十足，引导新人利用自己的生活经验以产品用户的视角审视业务领域，结合项目应用程序的使用，快速学习业务知识。
-
随后，通过其中某个业务场景，指引新人完成从视觉上看到的网页元素到理解和阅读代码层次的实现业务逻辑的完整流程。
-
最后，通过设计新的业务场景，指引新人利用此前学到的流程照猫画虎完成代码编写，同时引入代码规范，从第一行代码开始适应项目的编码习惯。
图3 教程的层次
至此，在领域知识方面，新人从自身经验出发，自主思考，理解和学习业务知识，并通过细致地讲解理解业务功能是如何通过代码实现，最终达成自己编写代码完成业务功能的成就。整个过程行云流水，符合我们的认知习惯，也建立了新人开始工作的信心。
分层容易，实现代入感却不容易。下面我以这个引导教程为例，说明如何构建代入感。
这个项目是一个航空公司的在线售票和服务网站，领域知识中的一个重要版图是机票的在线预订，于是我设计了这样一个任务：
假设你即将迎来假期，你决定去那个想去很久的地方（想想究竟是哪里），
于是来到这个网站预订去那里的机票，这是网站的地址：http://local.xxxx.com/booking.
*说明：在本地运行的网站里，所有的支付方式都并非真正发生，因此放心支付别害怕。
支付的各种账号信息见 - 这里(link).
一个人太孤单，你决定和一个朋友一起这段旅程，往返都有他/她的陪伴。
不过尽管假期时间已经确定，但万一什么重要的事情发生了，这次旅行还是可能取消的。
你喜欢带尽可能少的行李出门，而你的朋友希望旅途期间尽可能舒适，如果可以，他/她甚至愿意把床都带去。
你喜欢舒适的环境。在飞机上也不想座位太狭窄，连腿都伸不直。
酒店还没有定，你想选个好点的，不介意在哪里订。当地交通也是一样。
你有一只猫，温良可爱，如果可能，你想带它一起去。
此外，你不喜欢有额外收费的支付方式。如果不得不支付，你希望使用额外费用最少的那种。
最终，你会取得一个订单号，它将用于在未来找到你的这个订单。
记下订单号，并回答一下问题。
Q0. 你订的机票满足了你所有的期望吗？写下来未能满足的期望。
Q1. 列出预订期间观察到的所有该航空公司售卖的产品。
Q2. 回忆一下预定期间共经过多少页面，它们分别是什么。
Q3. 这和你之前的订票体验有什么不同，不同点是什么？
作为第一层任务，它不需要新人阅读任何专业文档，仅从一个旅行场景开始。这意味着门槛低，易于着手。
场景中设定了乘客的喜好，用于指引新人在订票过程中关注相关信息，潜移默化地聚焦那些可能被一扫而过但会被乘客真实使用的功能点。场景后列出的问题进一步确认这些功能点，并连接新人的个人生活经验，启发进一步的思考。同时，网站地址选用local，要求新人完成本地的程序运行，为此后的代码任务做好准备。
此后继续引入其他场景，最后列出术语表(Glossary)，扩大新人的知识范围。
第二层任务承接上层内容，选取一个功能点，从URL开始，逐步分解，每一步以行为所产生的结果为先，因为这是新人当下能够看到和理解的，随后进行内容讲解，说明产生这个效果的原因和流程，如有技术要点，也在此一一说明，附以相关文档外链，但需要注意的是，外链仅做深入学习所用，假设没有它们，该说明依然可以指导新人理解工作原理。
这就是之前所说的“提供足够且刚好足够的知识”。
此后，给出另一个相似功能点，要求利用例子中讲解的知识讲出其技术关键点和实现原理和流程。这一步是对知识的巩固。
有了第二层的知识储备，就可以着手练习了。第三层将实现从阅读到写作的跃进。如果说阅读是理解的过程，启发新人对知识进行梳理和归纳，那么动手写代码就是演绎的过程，启发新人运用掌握的知识，从一般推演个别，完成新功能的创造。
这一步很容易理解，其中的要义仅在于寻找一个合适的功能点，它的难度要适中，不可引入过多此前没有导入的领域知识，而项目中的技术关键点则需完全包含在内。
需要注意的是，本层的任务引导也应逐步进行。将功能点分解为若干步骤，在每一步中定义清晰的验收条件，同时列出将实践应用的技术要点。此外，可以进一步给出示例代码，展示项目中的架构设计和遵循的代码规范，从新人第一次动手编码开始，养成遵循代码约定的习惯。如实在需要引入未知的知识，这里不妨给出代码。
问题驱动
如上节的示例所示，在任务设计中，采用问题驱动。这在软件开发学习中并不常见。然而，在新人引导教程中却能达到超出预期的效果。其原因是聚焦，将问题域限制在有限范围内，从而快速掌握必备知识。
问题的设计需要有明确的目标，避免公式化的问题和答案，需要紧密结合任务，有针对性地提出。这样问题才能不是难题，而是引导，知识的获得变为水到渠成。
可验证
此前的用户访谈中提到一个问题是，任务结果难以验证，这和快速反馈背道而驰。为了克服这一点，在教程设计中做了下面几点：
-
代码完整可运行。保证代码业务知识的学习可以基于运行的应用程序进行验证。
-
分支代码库。保证代码的不变性，即使此后主干分支上功能点发生变化，并不影响教程的使用。
-
TDD。在代码实践部分引入并要求完成单元测试，确认代码实现能够包含需求中定义的场景。
-
细化步骤。每个任务尽可能分为小的步骤，每个步骤都有验证方法，确保新人不会在学习过程中走入岔路却不自知。
-
定义功能测试样例，当新人完成所有任务时，可以通过功能测试验证其完成度，保证设计的沟沟壑壑都被新人填平。
有限的时间
在实践中，存在新人因对业务和流程的不熟悉，而将很多时间放在对项目工作的辅助知识的学习，对必要知识的学习进行了延迟的情况。于是在这个教程中，我们通过实验对每个任务的完成时间进行了建议，完成时间是一个范围，定义了最少需要的时间和最长需要的时间。
对于不同角色的新人，在新人指引阶段的侧重点可能会有所不同，时间建议可以帮助buddy评估所需花费的时间及优先级。同时，在新人进行学习的过程中，可以帮助其合理安排时间。
测试和改进
好的产品不是一蹴而就的，教程也是。制作好的教程需要迭代、测试和改进。
在教程的制作中，我们进行了数次迭代和测试：
-
教程制作者对教程进行了完整的试用，自测
-
邀请项目中的新人使用该教程进行完成项目引导，收集反馈
-
邀请曾使用旧教程的同事阅读新版教程并给出建议
在此过程中，果然发现诸多问题。其中包括：
-
刚刚好的知识差了一点，导致无法进行
-
没有提供完整的功能测试样例，使新人完成任务后自测Happy Path后认为一切都很完美，完美忽略了设计者埋的坑
-
外链的项目架构说明已经过时
修改后的教程在不久后就发布了，那是一个更好的版本，解决了此前发现的所有痛点，大获好评。
结语
随着项目发展、团队扩张，新成员的加入成为很多团队频繁发生的事情之一，如何高效地帮助新人完成项目引导成为亟待解决的问题。在这方面做得好，能大大缩减新人融入团队和上手工作的时间，并有助于判断发现其能力水平，帮助制定个人成长目标。反之，则可能影响团队工作进度，同时增加能力评估的风险。
高效的新人项目引导教程意味着更短的时间和更好的知识吸收，这显然需要教程设计者丰富的经验和不懈的努力。因此，可以说这是一个成本很高的事情，比如，项目的这个教程花费了5人天。那么它是否值得呢？说到收益，就要谈谈使用场景。对于团队规模小，人员流动性弱或业务和技术比较简单的团队，人工的新人引导可能是最高效的；对于团队规模大，人员流动性强或是业务和技术复杂的团队，人工的新人引导就存在差异化大、时间长、效率低的现象，使用一致性的规范化教程则可以为团队提供很大帮助。因此，是否需要制作这样的教程，需要根据项目的实际情况灵活安排。
网友评论