你有过 "招聘经理的悔恨 "吗？这就是你在雇用某人后立即后悔的地方。这可能是因为你不喜欢他们的脸，或者只是想看到世界被烧毁。更糟的是，他们可能提到他们喜欢爵士乐。不管是什么原因，这篇文章是为了帮助你通过为他们挑选最糟糕的启动项目来让他们自己辞职。
不要等他们安顿好了再去做
他们还没有得到一个显示器？PM还没来得及向他们展示你们团队正在做的产品？他们的胸牌不能用，他们不得不要求队友陪他们去洗手间？这是一个完美的时机，让他们坐下来，解释新项目的所有细节。是否有一些组件他们还没有准备好？先不要向他们解释，以节省时间--当项目完成后，他们会自己把所有的东西拼凑起来。
挑选大项目
这一点至关重要。确保该项目涉及尽可能多的组成部分。理想情况下，最资深的人应该至少花2-3个月的时间来完成。挑选一个大的项目，确保他们不会得到任何小的胜利或自我感觉良好。如果他们设法将项目分解成较小的部分，你需要确保他们明白你只关心最终目标，而且你担心他们在应该工作的时候 "把时间浪费在项目管理上"!
如果有人反对你对项目的挑选，只要告诉他们你希望新来的人有 "所有权感"。
让他们拥有他们要取代的人所拥有的任何东西。
这就增加了项目不好玩的几率，而且团队中没有人真正知道发生了什么。
挑选有争议的东西
如果可能的话，选一个有些人反对的项目。也许是技术方向的问题；也许是项目经理和设计师在用户体验上意见不一致；也许有些人只是认为用户会讨厌这个项目。
如果你设法找到了这样一个有争议的项目--*不要告诉他们！*但要确保他们与谁互动。但一定要确保他们与反对这个项目的人进行互动。奖励点：如果反对者是一个团队成员，让他们成为导师。
让他们收集需求
确保只选择一个没有已知需求集的模糊项目。尽可能少地描述项目的细节，让他们自己去想其余的东西。
增加一些跨团队的合作
选择一个尽可能多的其他团队参与的项目。这里有一个可能的跨团队合作的清单。
- 这个项目可以依靠另一个团队的API，而这个团队太忙了（加分：让新人自己和外部团队见面，告诉他们你团队的要求）。让他们有压力，感觉这里没有安全网；他们应该内化如果他们迟到，会有多少人感到失望。
- 另一个团队可能急需你的团队的项目。让新人知道，其他团队对新人得到任务感到很沮丧。内疚和低自尊是你在这里的朋友!
让他们向团队介绍一项新技术
我们要做的是，既不了解团队中每个人每天都在使用的现有工具*，*又是团队中唯一熟悉新技术的人，这是一个甜蜜的点。
要求进行大量的非编码活动
不要让他们各自为政。确保他们必须做任何事和所有事。
- 让他们管理任何与项目有关的会议（确保他们也必须在这些会议上做笔记--这将确保他们没有时间去听和理解）
- 必须确保项目被优化到了极致--让他们做一些基准并分析结果
- 让他们搞清楚整个项目的生命周期--获得法律批准，通过安全和隐私检查，当然还有--准备一个启动日历。
确保项目阻碍了其他人
这个项目不应该只是自己辛苦。我们希望新人的负面情绪对他们不利。我们通过增加压力和低自尊来做到这一点。让他们知道其他人依赖于他们。奖励积分：当他们在房间里时，代表他们承诺一个严格的时间表。在大多数情况下，他们就会愣住，接受你说的任何东西。当他们抱怨最后期限太紧时--只需提醒他们，他们当时可以说些什么！他们会很高兴。
挑选最忙的队友作为他们的导师
确保帮助他们的人有很多事情要做。他们应该有大量的会议，也许还有一个不规则的时间表。也许他们是远程工作，或者在早上5点来上班，以避开交通。加分项：挑选一个即将休假的人。
将任何帮助的请求至少推迟两个工作日
大多数新人在寻求帮助之前，都会花很长时间自己想出办法。这意味着，如果你在他们已经请求帮助的时候让他们悬而未决，你就会确保他们在等待时无法完成任何事情。这就拖延了项目，造成压力。但它也培养了一种普遍的无助感和低自我价值感。记住：种瓜得瓜，种豆得豆！所以要播种一些苦难。
与一些高层人士建立频繁的同步会议
如果使用得当，同步会议可以成为推进项目的一个很好的工具--所以不要适当地使用它们！在项目的早期就开始安排它们。在项目的早期就开始安排他们，并包括尽可能多的人。让上级领导期待快速的进展，并让他们知道谁在负责。这里的经验法则是，每一次同步会议都应该让新人觉得自己是个失败者和失望者。让他们知道你希望他们为会议提交一些东西--这样的话，你就能确保他们把时间浪费在准备会议上，而不是推动项目的进展。
如何挑选一个能让人留下的启动项目
啊，这真令人尴尬。你以为他们说他们喜欢爵士乐，但实际上他们澄清说他们喜欢讨厌爵士乐。而且他们的脸在你身上越来越大。嗯。也许我们应该改选最佳项目，好吗？
起步任务，而不是起步项目
人们低估了对他们的代码库做一次修改有多难。你想的是代码行数，但它远不止这些。你的团队把对你的代码库进行修改的行为称为什么？提交一个差异，推送一个提交，发送一个合并请求？每个团队的做法都不一样，以至于我们甚至不使用相同的术语。每个团队都有不同的源码控制、问题跟踪、票据处理、命令行工具等。这可能是你的第二天性，但启动任务应该是帮助新人轻松进入这个领域。这不应该是一个不成功便成仁的情况。
从很小的事情开始。 不，比这更小。 甚至更小。一点点小....！让某人修正一个错字。让他们在你最近还没来得及做的那个模块上修正一些编码习惯。让他们在项目的CONTRIBUTORS 文件中加入他们的名字。这应该是绝对没有挑战的事情。弄清楚开发流程就已经是挑战了。
然后，以小博大。让他们修复一个小错误。在你分配给他们之前，你一般应该知道解决方案是什么样子的。初始任务不应该给你带来新的突破。让他们为那一个bug添加一个测试。让他们弄清楚如何运行测试，如何确保持续构建能抓住他们的变化。让他们追踪到生产。不要急于求成。
小任务提供了很多容易赢得的机会，但它们也是对你的代码库的一次小的参观。新人会接触到所有东西的一小部分。他们会开始认识组件的名称，联想到特定的技术，并 "寻找 "它们中的每一个，弄清楚他们的代码在你的源码控制中储存在哪里。他们会对你的工作和你的工作方式有一些了解。
让他们从事核心业务，即你的团队的面包和主食
每个团队都有他们优化的东西，以做更多的事情，即面包和面包。一个从事支付平台工作的团队可能会把 "增加一个新的支付供应商 "作为他们的面包和主食。一个从事待办事项应用程序的团队可能被优化为增加新的任务属性和过滤功能。对于一个免费的待办事项应用程序团队来说，实现支付或支付系统为用户增加很酷的头像选择并不是面包和主食。
让他们做任何你的团队最擅长和最经常做的事情。这将意味着他们在做项目时学到的所有东西都是有用的，这些技能可以转移到未来的项目中。这也意味着团队中的每个人都可以帮助他们，所以他们永远不会被卡住等待某个特定的人。
任务应该尽可能地自成一体
理想情况下，新人应该只需要与核心团队的人交谈，以完成启动任务。当然，如果一个任务很小，而且定义明确，那么在推送之前，如果我们需要让PM来处理，也不是什么大问题。但是，在开始与其他职能部门合作之前，让新员工对自己有更多的信心，会使这些互动对他们来说更加积极。
自成一体也意味着没有复杂的跨任务的依赖性。他们不应该依赖别人的diff，他们 "刚准备在2-3天，也许15天后提交"，其他人也不应该依赖他们的变化。没有必要引入更多的压力。他们刚刚开始一份新的工作，他们的压力已经够大了（而且压力肯定会越来越大）。
从过去的错误中学习
向团队中的人询问他们的入职经验。向最后加入团队的人寻求帮助，而不是最资深的人。最新加入的成员可能对这段经历有更好的回忆。他们可能更清楚地知道团队中的哪些组件难以掌握（应该避免），哪些工具是入职培训中必须要涉及的。
选择一个导师，但要确保团队中的每个人都平易近人
团队中最好的开发者不一定是指导新员工的最佳人选。挑选一个喜欢教书并且可以为新员工服务的人。如果他们平时有很多会议要开，他们可能应该在新员工来办公室的头几天就清空。
然而，一个人是不够的。他们可能很忙，生病或在休假。导师和新雇员可能只是没有化学反应，觉得彼此之间的交谈很尴尬。确保团队中的每个人都是平易近人的，而且新员工感到可以放心地寻求帮助。你可以通过以下方式来促进这一点。
- 让团队中的其他人介绍和审查每个小的开始任务
- 让团队中的人就你的产品和相应的代码库发表谈话
- 在新员工开始工作时计划一些有趣的活动，这样他们就会对每个人都感到舒服。
积极主动地提供帮助
正如我在上面提到的，大多数新人在寻求帮助之前，都会花很长时间自己琢磨东西。通过主动提供帮助来预防这种情况。然而，这应该是谨慎的，因为这也可能是一种压力。提供帮助可能意味着你认为他们已经晚了，你希望现在就能看到一些进展。让他们知道，如果他们需要你，你就在那里，不要给他们施加压力。
当你帮助他们的时候（无论是否主动），尽量不要让他们不知所措。许多（主要是高级）工程师倾向于用大量复杂的细节和长篇大论来回答问题，说明目前的情况是如何产生的（"这是一个很久以前的故事，当时源码控制只是一个富人的游戏......"）。告诉他们必须知道的东西，并问他们是否想深入挖掘。或者让他们先完成（小的）任务，然后在他们对该组件的具体作用有了亲身体验后，再给出更多的背景。
如果你能在下面的评论区分享你的启动项目经验，我将非常高兴。什么可怕的选择会毁掉一个人的新工作经验？你那了不起的经理是如何让你的入职工作变得轻松有趣的？
