知道什么时候该离开

有时候,放下成功的创业是最好的选择

下周我将离开PlayHaven的全职工作,它在世界上最富有的城市之一,我待遇不错,公司还在成长,我和一群牛逼的伙伴在一个团队工作。我一直问我自己,”我他妈在做什么?“

下面就是我的故事……

大约3年前我搬到了旧金山加入了PlayHaven。硅谷一直对本地俄勒冈州人充满吸引力,能够加入由有远见的Adny Yang创办的热门移动游戏公司的机会使我不假思索地做出了一个决定。老实讲,我不知道我要做什么。很快我就发现,团队也不知道。

我们有一款效益和接受程度几乎停滞的产品,我们需要改变一些事情。最初的5个月是最令人激动也是可怕的5个月,由于资金困难,我们在讨论接下来做什么。裁员即将来临。

在裁员之前,我和Andy有过一次非正式【注1】沟通,他告诉我接下来要发生什么,以及几周后我可能也要丢掉工作。我做了什么?我从舒服的老家搬到这个不熟悉的城市来加入一个垂死的创业公司?”我想仅仅度过这段然后回老家“。

但是我幸运地留下了。数周后公司规模缩小了,当我的朋友、同事收拾东西时,我难过地与他们说了再见。然后剩下了我们这6个人。

3个月后,事情开始好转。我们规划了新的、让人兴奋的愿景。团队都很开心。我们埋头从旧代码里扒拉,重新建立了新产品。做为唯一的产品经理,和一个5人的小团队一起合作,这是伟大的合作,一定是的。除了回复支持请求、偶尔发送营销邮件和其他各种工作,我负责制定用户体验,为新控制面板画线框图。这样同类的工作我都做,我不得不边做边学,还要快。感谢优秀的、饥饿的工程师团队,我们取得了很大进展,但是当时间流逝的时候,我们仍然没有收益。我们决定在2011年7月在Casual Connect举办一个私下的发布。

之前忙碌而兴奋,无数个痛苦的漫漫长夜,激情真是一剂良药,让你度过艰难的时光。为了使产品达到可用状态,在资源有限的条件下,我(非技术人员)搭建了一套本地环境开始消除bug。每次提交到GitHub都让我们对进度表示满意。

为大量客户准备的重要演示的前夜,凌晨2点。没有QA小组(甚至没有一个QA人员),我检查产品到晚上找bug,想发现并修复更多的bug。这是非常不科学的,但是我们没有时间定”流程“。我们仅仅想搞定它,最终产品达到了稳定发布的阶段,我们签了第一个大客户。太好了,我们庆祝了首次告捷。

相较于初期的简配,团队增加到了85个。我们拥有了数千名客户,产生了数百万收益。我们正抱着更大的愿景在成长的市场上运作(我对这一天充满信心)。一起进展得不错。

为什么这时候离开呢?

我上面提到了,我最想学习。在过去的3年我成长了许多,特别是最具挑战的艰难时光。

PlayHaven教会了我许多:发现人们真正想要的东西的方法论,提供合适的(最小化的)功能的重要性,把想法变成现实的过程,怎样扩大公司规模,如何把控雇佣合适的人,以及建立平等文化等等。

但是为了加速我的能力,我准备好了下一次挑战。我的朋友Nathan...

撤销

我爱互联网,不过我仅仅希望它能给我们提供“撤销”功能。

撤销错误的功能是电脑相较于其他同等竞争产品最有力的优势,然而自从网页app开始兴起后,我感觉到我们正慢慢失去这个牛逼的功能。

毕竟,撤销或许普遍存在于桌面端,但是你最后一次看到带有撤销命令的网络app是什么时候呢?

DROP DATABASE

我做为web开发人员,在职业生涯初期就着着实实地感受了一次。我为第一位客户搭建了一套定制化的CMS,在用root使用PHPMyAdmin时,错误地删除了整个数据库。

幸亏我有之前的备份,最终整个意外导致他们内部浪费了数个小时再次导入相同的数据。那次我意识到我犯下的愚蠢的、“愚蠢的”错误而带来的痛楚让我记忆犹新,我也是多么地希望能有个简单的 Command-z 快捷键(译者注:mac系统下的撤销,对应于windows下的ctrl-z)来挽回一切。

到底谁需要一个服务器

从那以后,我提交并分享了愚蠢的删除,每次我都诅咒自己,很想知道为什么因特网从来没有听说过撤销。

最近一次的例子发生在上个月,当时我以为正在清理一个没用的实例,实际上清除了产品的Sidebar服务器。

do-sure

很明显大部分要归咎于我,我应该更加小心,我应该多做一些定期备份。我非常清楚这些,但是我也想采取措施来避免这种事故。

...

QA已死,QA万岁

这不是针对刚开始,而是针对已经在应用写的。我最近经常被问到关于从两星期冲刺到一星期的建议,这样的对话发生了好多次。

客户:我们在用scrum模式,冲刺需要两周。我们想发布得快些,有建议吗? 我:QA也配备在冲刺里了? 客户:当然,冲刺里有基本的瀑布模型。 我:有建议了! 客户:太好了! 我:开掉你的测试人员。 客户:……

我是半开玩笑的。

我过去认为QA人员是第四个必要的技术岗位,随着组织成长还要添加更多名额。近10年我管理团队,都会确保每个团队至少有一名,去年我的观点发生改变了。我们的一个客户要求越来越快的发布,因此有些事情感觉不对劲。当我们保持填满QA角色时会遇到麻烦,问题还会随着发布时间表爆发。需要停一停了。

我们召开了一系列会议讨论我们的需要,以及告诉他们什么是应该做的。我们一致认为我们需要测试,我们也一致同意需要一个人来负责测试,也同意开发人员应该自己做单元测试,但是,关于设想或者他们应该做多少来集成测试的问题,引起了激烈的讨论。我们应该有个只做抽查的QA吗?人可以亲自重复测试吗?我们应该放弃手动测试,转而用一名首先是程序员的QA工程师代替?如果是这样,那么我们又该如何清楚地区分和其他工程师的工作?

这很难理解。我们花时间研究了大量的测试资源、书籍、blog和tweet。我们偶然遇到了关于Google早期形成的测试的《How Google Tests Software》,给了我们想要的答案,算是大获成功。天空开阔许多,我们过去一直错误地对待着测试。

我正在思索,但问题是有必要考虑QA的任何部分工作也是其他人的工作。目前我们还没有开始考虑工程师没有负责这部分工作,而是在考虑我们当然没有负责到底。工程师写一些单元测试,认为这就好了。管理人员把QA人员塞到工程师和每一次发布中间,并让他们完成工作。现实是,如果你把测试完全融入了代码的过程,那么你是否想完全避免瀑布模型——没有测试、但又都是测试。代码没有等到开始测试就完成了。

我们最初也是持怀疑态度的,当你走高空钢丝看到下面有张网时,这是令人不安的,对吧?一旦我们意识到,开发自己主导整个过程意味着钢丝实际上就变成了一座桥,没有什么好怕的。需要安全网的想法只是我们自己坏习惯带来的让人难忘的错觉。

当这样做的时候,你怎么知道是对的?你不需要任何测试人员,拥有测试人员将增加让其他人为你做测试工作的依赖,同样给版本过程增加了不必要的步骤。你首先成为测试人员。当QA需求属于战略规划组成的一部分、而不能被其他开发组分担时,单独的QA角色才应该存在。这多多少少取决于开发团队和产品,但大部分情况下,在四年当中的前三年都不是这样的。

自己做,设计一个工作流,让开发人员写自动化测试来测试自己的代码。开发人员会做出聪明的决定,你能够停止不必要的付出,最终你能够做完你的scrum当中的瀑布过程。我仍然建议持续发布不能没有这个方法,你可以不用专门的QA,从现在开始,你的代码、流程、开发、时间点,还有预算,都将因此而受益。

...