领会Lean Startup精神

不知道国内对lean startup的关注多不多。从google上的搜索结果来看好像运用lean startup方法的创业公司很少(也许很多人用着lean startup方法但是不知道是lean startup也说不定)。

按惯例我先介绍一下名字的含义。国内中文很多翻译成为精实创业的。虽然我听着有点怪,但是觉得还是比较准确的。lean startup的主要精神就是不做任何浪费资源的事情,好钢都用到刀刃上,这就是精;还不能闭门造车,要按实际情况随时调整,和传统的计划好后一成不变的生产过程有很大不同,所以是实。最初Eric Ries创造lean startup这个词时好像是受了lean development的影响。

这篇文章题目是说领会精神,实际上我也是在学习过程中。只不过今天碰巧读到Mr.Jamie的《網路:進入門檻極低,成功門檻極高》才发现,原来现在所作的,只不过是把以前所接触的传统意义上的经营方式忘掉。怪不得年轻人在新的IT创业中往往做的比老一辈人好。就像张无忌学太极拳一样,要完全忘掉以前所学。

在实际运用中,lean startup讲究的快速推出MVP,不要怕得罪顾客,不要怕产品太简陋,如果有错误马上改正,推出新的解决方式再进行试验。和传统教育的思维非常不同,首先不能拘泥于面子,也就是必须脸皮厚;然后用科学的试验方式总结概括,直到慢慢接近真理;还有就是犯错没什么,知错就该就好,鼓励你犯错。和中国传统教育特别是大陆的传统教育完全的是两个极端。所以为什么辍学生反而更容易不按常理成功,这个应该就是原因之一吧…

P.S. Eric Ries有可能受我的邀请来哥德堡客座一番,当然还得等我先把赞助商拉到再说(他的代理人给我的报价差不多是一万欧)。

对”多些时间能少写些代码“的一些不同看法

我认同这篇文章里的不少观点,像是”聪明的程序员使用50%-70%的时间用来思考,尝试和权衡各种设计和实现,而用30% – 50%的时间是在忙碌着编码,调试和测试。“很多时候看你活做得好不好不是看你花了多少时间Coding,或是Code有多少行。要做到Clean Code或Beautiful Code里提到的那种程度必须编码前的思考和规划。

不过对于文章里很多观点我个人觉得都有值得推敲的地方。首先我感觉作者对Agile有些误解。下面把我的观点一一道来。

软件开发真是这样的吗?难道不需要花时间去思考吗?

Agile里定义的开发应该不止是Coding吧?研究,计划,设计都是开发活动。用Agile不是说把所有开发活动都变为Coding了。

TDD快速原型和迭代可能会对软件和团队产生负面影响。一开始,你需要花很大的精力来让你的软件从无到有(做过软件的人都知道,从零开始写代码是很痛苦的事),但是因为你没有想好,先做再说,所以,后期你会面临更多的质量问题而让你需要花更多的时间精力。。。TDD、迭代、原型只关注功能性需求,其不会关注非功能性需求,比如性能问题,高可用性问题,系统维护问题(模块的耦合问题),等等。而这些问题往往都可以让你的软件设计重新来过。

同理,如果你把研究计划设计定义都算为Agile里的开发,这个论点的依据就不成立了。此外还有一个我觉得普遍的观点就是传统开发由于计划周全,所以后期出现的意外质量问题少。其实很多问题早期设想根本不可能看到,只有实际deploy后才会发现。而如果从0到开始部署周期太长的话问题会出现的很晚,解决起来更痛苦。

重构是恶梦,重构应该越少越好

我个人反而喜欢重构。比如以前写了10个method现在重新设计为3个,或者基本没什么变化但是变量,缩进设计和method安排使得代码可读性更高了,其实都是增加了价值。我觉得代码就要经常重构,大的或者小的。这样才能改进产品和个人能力。当然一般的老板意识不到重构也是做产品。本人是Clean Code和Beatiful Code这两本书的忠实执行者。

所以可能对重构的抵触也是和Agile不兼容的原因之一?但是很多传统的开发方式不是避免了重构,而是把重构的成本变的很高所以公司会选择能拖则拖,最后technical debt越滚越大。

我现在在做的项目,花了几乎4个月的时间来做设计,在这个过程中,我们反复思考、讨论和权衡若干种实现方法,并尽可能地穷举所有的场景和细节以及未来可能的变化(那怕是那些简单的模块),有个模块被重写了至少三次,每次都是写到一半就被推翻重写,我们整个团队不断地在和其它团队讨论,并在对系统不断地认识中对系统进行简化和优化,并力求达到完美。现在看来,没有贸然使用Scrum是明智的。

我们公司用的是scrum。在写新系统的时候,大部分任务都是investigate,或是benchmark不同的solution,或是按照想法做demo。可见我们花在计划上的时间也不少。所以这个和你用不用敏捷是无关的,而是思考和计划在公司里的位置。

最后声明一下,我对Agile的知识都是在公司里工作学来的,没怎么看过理论。而公司里用的是Scrum。我个人对开发方法没什么喜好,什么管用用什么。但是我们公司开发情况比2年前用Waterfall时好太多了。

程序员创业:给自己做产品还是给别人做开发

大学起就开始向往财富自由的日子:一边每天打点一下生意,一边环游世界的生活一直是俺的梦想。越是工作的时间长,越是不喜欢朝九晚五的日子。想趁着IT界的东风也离职创业一把吧,但是一摸裤子好像没什么钱,摸摸胸口也没有这个魄力。所幸看过不少IT财富自由人士也是业余创业起家的,看来这个选择还是不错的样子。

从一开始自己做了几个软件,到后来和网上认识的朋友一起做一个服务+app软件的project,还有最近尝试了一下从网上接点小活。每种方式都体验了一下。今天刚好发现了Johnqh的非常有价值的一篇连载,虽然是讨论做iOS自由开发的,但其实对所有开发都适用。我也在这里整理一下自己的想法。

选择自己做软件,或是服务+软件的。大体要考虑的事情差不多。除了开发和维护,还要有初期的设计,中期的宣传和推广,后期的客户服务或者升级。要做的事情蛮杂,风险相对大些。但是如果坐起来的话可以有现金流收入。一个人做会很累,多人合作做好些。这也是那篇连载里推荐的做法。

选择网上接活的给别人写代码的,只需考虑开发即可。风险小,只要任务过关就有钱拿。名气大的还可以挑挑活。坏处也有,一旦不做就没有收入了。而且地域关系大,像是我在瑞典做的话由于这里生活贵,不可能开出很低的薪金。如果竞争者和你水平差不多,但是来自印度,就算收一半钱可能活的还比你好。

原先以为自己做产品,可以挑自己喜欢的东西做,自由度大。其实不是,做出来最终的目的还是为了挣钱(除非是自娱自乐),所以很多时候要找对自己有利的方向而不是自己喜欢的方向。而且我发现如果给我自己打工的话,很多时候我很多项目都想试一下。其实这篇文章里说的建立自己的优势领域蛮对的。毕竟人的经历是有限的。

所以到底是自己做产品还是接活搞开发呢?我也不知道。真要是想做自己喜欢的技术,其实还是找一家做这个的公司最方便。稳定不稳定我不知道(在瑞典以前那些号称稳定的公司都裁员),但是是适合大部分人的选择的。

至于我,我还是想一边上班,一边做点自己觉得有用的产品,看看未来的“钱”景如何。