提纲

通常我得到了一个伟大的想法,比如 我认为向全世界公布2Pac仍然存在并且在旧金山的创业公司工作。

因此那时候我有了这个伟大的演讲想法,但是我面对音乐时被卡住了:我究竟如何充实整个演讲?有一些细微之处需要覆盖到,比如,我应该讨论 “2 of Amerikaz Most Wanted”实际上怎样成为了他急切想在安静的硅谷创业公司工作来度过余生的寓意吗?或者我应当提到他的十分可疑的纹身:

Path和2PAC的联系

不管何种情况,我差不多总是先做提纲来对付新的演讲。有一百万种方法,因此结果可能不同,不过这对我是适合的。

内部的提纲

我喜欢把我做的事情叫做内部的提纲,因为它像某种有趣的文字游戏,通过发明新的术语,最终你能够收取版税。

基本上,先写下重要的事情。这些应当是你的主要章节,足够丰富到深入细节。

它取决于演讲,但是我认为,如果你能够传达在三个章节,大多数演讲差不多都能过得去。诚然,这有限制,但是如果你能把主要论据放在三个均支持细节的不同章节,它会产生一个非常紧密的叙述。因此,对于Pac的演讲,我从这5个方面开始:

邮件收据:一个失去的机会

前几天我收到了Buffer的一封邮件:

Buffer的邮件收据

它是我们每月付款的收据。我凭直觉打开这封邮件,快速扫一眼支付的美元数目,然后归档。

那天之后我思忖半天想到,“多么可惜的机会呀。”

每个月Buffer的邮件收据都会引起她的最有价值用户的注意:她的付费用户。但是这条消息因为没有引起重视而被浪费了。对于一家专注于让客户惊叫的公司,我认为他们可以做得更好。

邮件副本是友好的,但它每次都一样。另外,任何人都会阅读他们的收据吗?我在写这篇文章之前是没有看过的。收据应该是品牌的延伸、让客户开心的机会。

或许她的每月邮件收据可以是这个样子:

推荐的Buffer的邮件收据

Buffer非常透明,其团队是品牌的脸面。在这个例子中,收据带上了这些员工的掠影,表明他们的专注和对支持的谢意。

Buffer每月发送16,401份收据。那是产生16,401张笑脸的机会。

如果你的业务发送收据,要考虑你如何:

...

为什么你的前任开发者是糟糕的

为什么你的现任开发者貌似如此优秀

你为正在使用的项目雇佣了一名新开发者,她好像已经解决了所有问题。虽然她只来了3天,她就已经建议升级了5个类库,重新组织了JIRA问题。每一次,她好像在向你证明,雇佣她是正确的选择。她发现了8个明显的、会产生致命崩溃的bug。你的前任开发者是多么地愚蠢呀,竟然一个都没有发现??她不理解他使用XYZ框架的决定,也不理解在这个特定的应用程序中,他为什么选择使用Postgres而不是CouchDB。她向你抱怨,缺乏CDN就是把你的大把时间花在了不必要的内容服务上。你怎么能对此视而不见?好吧,这不是你的职责,对吧?那是你的前任开发者的职责,他好像极度失败了。终于解脱了。

现任的诅咒

不要担心——你的处境远非个例。我一直时不时地看到这一幕,一个新的开发者来了,好像一夜之间改变了一切。她或他建议新的工具、新的流程、新的语言和新的一切。所有这一切都在诅咒前任开发者或团队。我在这出好戏扮演过各个角色。我曾经是新家伙痛骂的“前任开发者”。我曾经是把前任家伙用作替罪羊的新家伙。我雇佣过这两个位置上的开发者。我为公司工作,而公司不能明白,对我而言什么是简单的:这一直都在上演。

我把这称作“现任的诅咒。”做为一名开发者,当你看到用来构建某个应用程序的选择时,你每一次都被错误的决定吹走了。“为什么,啊为什么,在Node.js将是如此优秀的时候,它居然使用Rails?”,或“前任开发者怎么没有预见到,当他们选择MongoDB时,数据库是需要引用完整性的?”但是,你或许没有意识到,你以今天的眼光来看它当初的样子。当前任开发者(或团队)不得不开发的时候,他们不得不处理大量未知因素。他们不得不在信息不对称的前提下做出很多决定。你在现在的情况下被诅咒了,因此系统好像变成了错误决定下的苦差。

停止责备

开发者倾向于责备前任的另一个原因是因为责备比较容易。前任开发者不再需要评判他的行为,也不会在那儿保卫自己。因此责备他是超级容易的。如果一个开发者不想努力工作或解决一个特定问题,责怪系统固有的东西要比懒惰(或不胜任)更容易。当老板问“某个项目的时间点”,说“哦,通常只需要两周,但是由于我们正在处理某个类库的一个老版本,它很可能需要1个月。”老版本花费时间长或许是真的,但你这个开发者当月只是不想工作太辛苦也可能是真的。

辩解

由于某种原因你雇佣了这个新开发者。经过一系列的面试、代码测试以及类似的过程,你最终雇佣了这个人。现在,这个人不得不证明他们是物有所值的。开发者往往认为较好的方式是早些做出重大的改变。实现所有种类的过程,尽管不需要实现;引入所有种类的工具,最好是团队其他人没听到过的工具。我看到过不计其数的这种行为的组合,一个开发者四周转转,说使用Pivotal是多么地不好,我们现在需要使用JIRA,或他们不能相信我们仍然在用Subversion、因此我们应该怎样迁移到Git。这向我们已有的知识辩解,心里希望给你,哦,光荣的老板留下印象。

该结束了

我认为因为某事简单地责备前任开发者或团队是糟糕的实践。给他们怀疑的好处,设想他们在当时受限条件下已经做出了最好的决定。他们不了解这个完全通透的系统。短期看,它或许使你在融入组织的时候打上霸主的印记,但长期看,它伤害了我们所有人。我们一直都是在我们离开之后、因数不清的问题而被指责的开发者——知道这发生在你身上会觉得不舒服,因此为什么要对其他人这样做呢?把道德举高一些。即使是前任开发者的错误,不要那样陷害他。

通过成为一名可靠的团队成员,来做长期的英雄,在任何时候你都能做出好的判断。不要做短期英雄,这会众叛亲离。你很可能已经得手了,但是我们(开发者社区)不会太喜欢你,如果你是这样的话。现在,就算这样,有一些 前任开发者是一个真正糟糕的开发者 的情况。那种情况下,马上让利益相关者注意到这一切,而不是在你不想、或做不到的时候,做为你自己的一个方便的借口。

这是我的夸夸奇谈,我会继续的。
...