文章目录
  1. 1. 前言
  2. 2. 当初的选择
  3. 3. 技术成长
  4. 4. 眼界变宽
  5. 5. 工作上的反思和改进
    1. 5.1. 执行力变强
    2. 5.2. 对 scrum 有了更深认识
    3. 5.3. 更注意沟通效率
  6. 6. 总结

前言

大约在去年这个时候,我离开网易有道,开始了自己的创业不归路。一年过去了,总是在忙碌,在最忙的时候,我连博客都没有时间更新了。但是这一年的经历对我的成长重大,还是挺值得写下来的,在此将我的故事分享给那些一同走在创业路上的朋友。

当初的选择

这次的创业其实并不算是真正意义上的创业,因为我并不是创业合伙人,也没有股权,对于公司的发展,我更多是执行者,很少有参与讨论的机会。但与此同时,我的薪水并没有大幅度减少,期权所画出的大饼也确实有些吸引力,另外,我可以独立负责 iOS 开发,对我来说是一个不小的挑战,作为一个早期加入的核心员工,我可以享受到公司成长带来的好处,也可以和公司一起成长,承担更多责任,学习和体会创业的过程。

所以,如果我这次创业失败,对我的影响相当小,我不用担心交不起房租,更不用担心找不到工作。不管创业成功与否,我都将收获在 iOS 开发领域快速的成长,也可以感受和学习创业公司的工作方式。现在一年过去了,创业发展顺利,我还可以进一步感受和思考公司规模扩大所带来的各种问题,以及一起参与解决这些问题。

某种程度上说,这符合我对于第一次创业的期望方式:有挑战,有收获,风险小,潜在收益也不错。因为我工作才 3 年,在各方面还很嫩,选择加入一个创业团队比直接自己当创业合伙人要安全得多。

技术成长

由于我不是合伙人,所以我可以继续专注于 iOS 开发,不用管市场,运营以及产品的事情。以前在前公司,我只是负责某 iOS 产品的 UI 部分,我甚至都没有机会了解将 App 发布到 AppStore 的过程。在这次创业中,整个 iOS 端的开发都是由我一人负责,我学习和接触了很多以前没有机会了解的东西。

在项目开发中学习是最好的学习方式,这次创业我也不止做了一个 App,每做一个 App,我就会尝试一些新的技术方案和挑战。

  • 在做粉笔网客户端时,我尝试了完全使用 ARC,也尝试用 UIWebView 写了很多 javascript。
  • 在做猿题库行测时,我尝试了使用 AVFoundation 来自定义扫描界面,尝试用 OpenCV 来实现答题卡识别算法,尝试用 CoreText 做部分界面的渲染。
  • 在做猿题库申论时,我尝试用 Storyboardcocoapod 来做包管理。
  • 在做猿题库司法考试时,考虑到团队可能扩大,我尝试用全手写界面的方式来开发。并且用 Git Submodule 来管理猿题库公用模块。
  • 在即将上线的猿题库新课程中,我尝试了结合多 target 编译和 Submodule 来管理多个猿题库之间的差别,力求将新课程的开发成本减少到只需一些配置文件即可。

如果不是因为创业,我可能都无法决定使用这些技术方案,更别说负责整个 iOS 端了。

眼界变宽

以前在网易,公司里有很多做 iOS 开发的同事,偶尔有一些技术交流,现在创业只有我一个人做 iOS 开发,我最担心的是我自己由于交流太少而眼界变窄。于是我想只有通过网络和同行进行更多的交流了。于是我就建了一个 QQ 群,然后把以前的同事都拉到群里面,但是大家还是交流还是比较少,我想了想,主要是因为这些同事都不太喜欢交流和分享,强行把他们拉到 QQ 群里面,并不能促使他们交流,于是我就开始在网上寻找一些喜欢交流的同行,邀请他们加到群里面一起聊技术。这样慢慢地,群里面就有自发的讨论出现了。

有一段时间,我发现讨论的内容还挺有价值的,于是就觉得 QQ 群不能将讨论内容沉淀下来太可惜了,当时正好微信公共账号比较火,我就想试试把有价值的内容通过微信公共账号发出去。刚开始很难,原因一方面是整理信息的成本很高,写成微信很花时间。另一方面,我也没有那么多时间来写微信。不过我坚持了一段时间后,渐渐发现有一些牛人会被吸引到我们的 QQ 群里面,这样就行成了一个良性循环。QQ 群不断有牛人加入贡献高质量的讨论,讨论内容通过微信发出去后,又吸引更多牛人要求加入。由于申请加入的人太多,我提高了申请加群的要求,因为群里人数一旦过多,就会影响平时的工作了。所以现在 QQ 群的人数基本稳定了。群里面的人员组成主要分以下几类:

  1. 比较大的 IT 公司的 iOS 开发者,包括腾讯、百度、新浪、搜狐、网易、阿里、人人等
  2. 比较小的 IT 公司的 iOS 开发者,包括豆瓣、美团、知乎、拓词、花瓣、Clover、流利说等
  3. 自由职业者或自己在创业中的 iOS 开发者
  4. 海外的 iOS 开发者

如果说有什么特点,就是他们都是喜欢分享的人,大部分人都维护着自己的原创博客,这保证了群里面讨论内容的活跃。同时他们都还很忙,这保证了群里面不会很水,有问题讨论问题,没问题的时候就很安静。这是我非常喜欢的。因为这样的讨论组一方面保证了讨论的即时性,另一方面又不至于太吵而干扰平时的工作。

如果不是因为创业,我可能也不会被迫组建并维护这么一个高质量的 QQ 群,进而也不会有这么好的交流圈子了。

我的微信公众账号是 iOSDevTips, 现在关注人数有 3000 人。6 月 6 日,微信公共账号同时得到了 @Fenng@ 池建强 在各自的微信公共账号上的 推荐,关注人数也暴涨。很高兴自己最终坚持下来了。如果你是 iOS 开发者,欢迎关注我的微信公共账号,只发干货。用微信扫描下面的二维码即可关注:

工作上的反思和改进

虽然我在创业中专注于 iOS 开发,但是我还是会参与一些产品讨论,也会负责面试招人,也会反思现有工作方式的各种问题。这种反思的过程持续地在每一天进行。这种反思和改进包括如下几个方面。

执行力变强

似乎什么事情都可以归结到对资源和时间的合理分配和控制。对于创业公司来说,对于产品开发进度的控制是尤其重要的,我们很高兴地看到,我们的创业团队在过去的一年,不但保证了所有开发项目不延期,并且还保证了很快的开发进度。在过去一年,我们花 4 个月完成了粉笔网的开发,3 个月完成了猿题库行测的开发,2 个月完成了猿题库司法考试的开发,7 天完成了猿题库申论的开发,这些项目的开发进度和我们之前计划的完全一样,没有任何延期。在软件开发领域,项目延期对于很多公司来说从来都是常态,我们通过团队的努力以及一些合理的进度管理方法来让按期交付变成了常态。

首先说说团队的努力,团队的努力主要在于团队每个人都努力工作,提高效率。就我个人来说,我会更加关注自己每天花在写代码上面的时间和沟通的时间,以及工作间隙刷微博的时间。我有些时候状态好,可以一连写好几个小时代码,有些时候状态不好,写一会儿代码就会分神干别的,这个时候我会把所有干扰工作的 QQ, 邮箱都关掉,然后戴上耳机,给自己设置一个 45 分钟的番茄钟(不知道这个是什么的,可以搜一下番茄工作法),然后每个番茄钟到了再休息一下,一般连续做过 3 个番茄钟之后,精力就又容易集中了,之后就不用设置番茄钟又可以连续写上好几个小时。当然,适当活动也是必要的,我有时候会注意每一个小时动一下,公司里面也有哑铃可以举几个。另外,我还安装了 rescue time 软件 ,可以方便自己回顾每天的工作效率变化情况。

然后说说我们的进度管理方法,我们使用 scrum 来进行进度管理,但是根据我们创业团队的情况,我们做了不少改变,我们对于 scrum 的主要改变是:

  1. scrum 中每个 sprint 的周期变为 1 周。下面会展开阐述理由。
  2. scrum 会议中的回顾会议和计划会议一起开。主要是为了减少会议的次数。

1 周的 sprint 相比传统的 2 周或 4 周 sprint 最大的优点是,可以对进度有较强的控制,因为迭代周期减小为一周,所以可以更早地发现开发中可以出现的问题,进而进行微调。微调的粒度变小,就保证了整体进度的可控。我们对开发进度的微调包括:

  1. 通过每周的 sprint,尽早发现开发进度上的风险,合理加班或者减少部分需求开发。
  2. 通过每周的 sprint,尽早地将产品功能的改变融入到新的 sprint 中,使得产品能够尽快应对来自市场需求或产品需求的变化。

1 周的 sprint 也有一定的缺点,首先是它的时间非常紧,除去开回顾会议和计划会议的时间,通常只剩下 4 天半。4 天半时间通常会排满开发进度,常常会造成留给测试同事的时间比较少。对于要上线的 sprint,sprint 结束日那天的上线工作也会占据不少时间,因为上线通常会涉及很多系统运维相关的操作。另一个缺点是,它无法安排一些长期并且重要的事情,例如技术分享和讨论,新技术调研等。

但整体说来,对于创业公司来说,活下去才是最重要的,1 周的 sprint 可以带来产品按时交付的巨大优势。所以我们直到现在还是坚持 1 周的 sprint。或许以后公司大了,时间不是最最紧迫的资源时,我们可能会考虑 2 周的 sprint。

对 scrum 有了更深认识

scrum 很容易被误解,也容易被错误地实践。

对于高压型的 Leader, scrum 很容易成为他压榨程序员的工具,因为程序员通常在估计工作量时很乐观,但是执行时就会出现各种问题,scrum 将任务拆分到每天做什么的时候,很容易造成程序员为了完成当天的工作而加班。如果管理者在回顾会议不能很好的处理这个问题,程序员就会认为这是一种管理者控制进度的工具,然后在以后的计划会议中故意将时间估长。

对于温和的 Leader, scrum 中的 sprint 很可能成为一句空话,每个 sprint 都会出现完不成的情况,每次当然都会有合理的理由:例如功能开发量估计不足,需求没有讨论清楚,遇到的技术难点等等。当大家对于 sprint 的按时完成没有压力的时候,scrum 本身就成了一个可有可无的东西了。

执行了一年多 scrum,我感觉 scrum 最核心的思想就是强调团队的自我反思和进步,而这一点要求 scrum 团队成员有较强的能力和素质。所以很多公司没有把 scrum 执行好,就是简单地执行了 scrum 中的各种流程和方法,而忽视了其中最重要的基础:团队成员的能力。如果团队成员本身能力不行,也不能为整个团队着想,为公司着想,搞 scrum 就是一句空话。只有大家真正相互欣赏,相互理解和配合,团队的作用才能发挥起来。我们通过一年多对 scrum 的实践和改进,最终形成了我们自己的团队工作方式和团队文化,这一点是非常棒的。

如果不是因为创业,我可能至今还以为 scrum 只是管理者为了压榨程序员的劳动力而建立的工具,也无法体会到 scrum 的好处。

更注意沟通效率

上面也说过,时间是创业公司最大的敌人。而对于我来说,除了写代码的时间外,最大的时间开销就是沟通了。我们想了很多办法来提高沟通的效率。比如重要的信息,我们都会记录在 wiki 上,比如每次 scrum 的回顾会议的总结,我们就会放到 wiki 上,服务器端的接口信息,我们也会整理到 wiki 上。wiki 对于新来的同事特别有用,因为他可以通过 wiki 了解到整个团队工作的历史,进而方便他熟悉和融入团队。对于一些相互依赖的接口信息,放到 wiki 上也省去了我们为了弄清楚接口而打断别人的工作,提高了大家的工作效率。

为了提高沟通效率,我们也把所有能省去的会议都省去了,我们没有产品评审会议,没有美术评审会议,我们也不会评审测试用例,以上这些会议,如果我们觉得有必要进行沟通的,就私下沟通,一切从简。

我们尽量减少打断别人工作的行为,如果我觉得有一件事情需要让所有人知道,我就会发一封邮件出来,如果该事情值得记录下来,我可能会同时把内容整理到 wiki 上。如果我在开发上的一些任务依赖后台相应的功能,我就会给相关人员报一个 Bug,让他抽时间处理这个 Bug 即可。小的产品文案的改动也是以报 Bug 的形式来沟通。如果有些事情急需要让大家知道,比如服务器正在重启,测试和开发暂时不可连接服务器,我们就会在 QQ 群里面说一声。只有当我的工作被严重 block 的时候,例如需要服务器同事的确认才能进一步开发,例如需要产品的确认才能进一步开发的时候,我才会去打断别人的工作当面询问。尽量保证别人的工作可以不被打断,其实也是提高了大家工作的效率。

回想起以前在大公司,所有的沟通大多是在 QQ 一类的聊天工具中完成,打字交流,效率极低。开组会的时候,很多人无所事事,玩手机开小差,效率低下。创业让我感受到了效率至上的工作态度,让自己每天的工作高效是非常快乐的事情。由于我们不鼓励加班,所以我们自然也享受到了高效工作的回报:自己有更多时间做自己的事情。我每天都比同屋的另一个在美团工作的朋友下班早,晚上下班回到家,有时候我会看看书,有时候看看电影,有时候也会研究一些新的技术,创业的生活不再变得苦逼了。

如果不是因为创业,我根本无法体会到创业带来的高效地工作环境,每天自己的时间都在做具体的事情上,而不是大量的沟通上。

总结

如果不是因为创业,我无法在 iOS 开发上负责更多事情并且快速成长,无法扩大眼界认识很多 iOS 同行并和他们组建高质量讨论圈子,无法成功地连续一年执行 scrum 并且保证所有项目不延期,也无法享受高效工作不加班的生活。有这么多收获,创业本身能不能成功反倒不是最重要的事情了,每天能够开心,认真,充实地工作本身就是一种享受。

身边有不少朋友都在创业,有失败的,也有发展顺利的,和他们聊天常常会谈到,创业是一条不归路,因为创业的过程就象是打开了潘多拉的盒子,你见识到了外面世界的精彩,就再也不能忍受在大公司的平庸生活了。愿所有在创业路上奔跑的人们,找到属于自己的精彩。