这个问题其实是一个伪问题,因为大多数软件从业人员都相信没有银弹,但很多时候这一观念需要不断被强化。Ivar就说过,软件行业是一个时尚行业, 人们不断将旧的概念包装和组合来创造新的概念。在过去十年中,先是面向对象/UML而后是CMM(I)被当成银弹来出售。据我个人的观察,敏捷有被神化成下一颗银弹的趋势。
那么什么是敏捷(Agile)呢?虽然敏捷这个概念近来很火爆,但当你向敏捷一个的狂热支持者提出这个问题的时候,那多半会看到一张茫然的脸。所以,我从Wikipedia中找到了下面的定义,我相信其他版本的定义也大同小异:
Agile Software Development is a conceptual framework for software development that promotes development iterations, open collaboration, and adaptability throughout the life-cycle of the project.
在这个定义中,指出了敏捷的三个要素:迭代开发、坦诚合作和自适应性,下面我们分别对这三个要素进行以下分析。 阅读全文…
最初在《程序员》上看到这篇文章,对此文的标题就深有感受。在网上很容易找到电子版的来转帖下,顺便大家也可以讨论下产品经理的JD。
一个成功的产品就像一个人的成长过程一样,会经历孕育、婴儿、少年、青年、成年、老年等几个不同的阶段,而产品经理就像无数操心的父母一样,在不同阶段要有不同的心态和处理方式,以帮助产品茁壮成长。
在我贴出的一篇博客中,有这么一段:
最后说点完全不相干的事,别错过了6月3号微软技术大会上的即兴演奏会。我们几个SourceGear来的小跟班儿打算上台表演一曲 Pinball Wizard。我弹原声吉他,我们的开发经理Jeremy Sheeley 弹贝司,而我们的产品经理Paul Roub弹 EvilMastermind Schecter PT。
话说回头,那篇博客的第一个读者评论写道:
3个经理。哇。你们公司肯定还在增长,要么就比较大。
发表评论的仁兄很可能是用“经理”一词来指代“管人的人”。如果是这样,那是没错,我们公司的经理不止3 个,但是演奏Pinball Wizard 的3个并不都符合这一名号:
- Jeremy Sheeley的确是个经理。他管理着Vault 和Fortress 开发部门。
- 严格说来,我觉得我是经理。但是认识我的人会说,把我当成经理实在太抬举我了。
- 但是Paul Roub是“产品经理”。在SourceGear(还有我所知道的大多数其他公司)这里,产品经理并不[必然]管理他人。
因此,当我看到那个评论时,我告诉自己应该写篇有关产品经理角色的文章,也就是本文。 阅读全文…
7月份的时候上过一次赵越老师的战略市场营销课程,这次又有个难得的机会再参加了一次战略市场营销的商战模拟培训,把一些学习到的理论得以重温,并且有机会在模拟的战场上演练一番。3.5天的课下来十分的紧张,十分的疲惫,这里把一些新的心得记录一下。
要STOP,不要执着于眼前的结果,要看问题本质。
其实这个上过赵老师课应该是有这个素质的,但是在遇到实际的问题的时候却不能冷静的处理。
新入手的时候要停,失败的时候更要停,胜利的时候也要停。停下来也许从一个很短的时间片段来看是落后于别人了,但是实际生活不是100米冲刺,是马拉松,所以从长远看停是为了更好的看清楚方向,向前冲。
同时在面临问题的时候不要只看到问题的表象,要从更高的层次去看问题,找问题的原因。例如在第5轮,如果按照原有计划我们的现金流是负数,我在组内第一个沉不住气,首先想到的是清理库存,裁剪销售人员。但是这都是数字上的游戏。我并没仔细考虑我们将来要做什么,问题的成因是什么。同时也体现了我太争强好胜的性格,反而让我迷失了问题的本质。
有一个同事,工作敬业,一直长期加班,抗压力很强。我看着也一直觉得她很辛苦,也想帮她解决问题,但是也问到她的时候她总是说就是那么多事情,忙得没时间去想为什么。这其实同样是没有STOP。殊不知也许一直没时间思考的就是忙的根本的原因。如果不去STOP思考,也许就会限制自身更高层面的发展。
其实自己又翻出来之前培训的感受,发现自己感悟最深的还是这点。所以基本可以说之前学的魂都忘记了,只是记得了一些术上的东西,例如什么市场细分啦,用户感知啦等等。可见学以致用做的很差,我只是过分的执着于术的东西,还没有悟道。Sigh~~~
大道无我,大道利他
这个同样解释的是因果的问题。例如我们追求的流量,用户数这类的KPI,都只是解决我问题的结果。如果我们只是将视角集中在这个点上出发去考虑问题,那就成了以终为始的局面,本末倒置。越做越不明白,越做越累。而如果将视角从自己的KPI,自己的绩效考虑转移到客户到底用我们的产品有什么不爽的地方,怎么去帮助他们解决,那么如果做好了,什么流量、用户这些就都解决了。其实内部的部门也是同样的道理。这就是所谓的无我和利他。我们之前的KPI太简单粗暴了,改进质量,提升流量,这些都太容易从我的视角出发,从做数字上去解决问题了。所以,我们明年的任务的思路就要一切从用户的问题出发,怎么让用户用的爽,对应有的人的KPI就一切都以解决问题的这个视角出发。理论上如果我们识别用户问题对的话自然就会越做越活。
公司所有员工是否考虑过,如果有一天,公司销售额下滑、利润下滑甚至会破产,我们怎么办?我们公司的太平时间太长了,在和平时期升的官太多了,这也许就是我们的灾难。泰坦尼克号也是在一片欢呼声中出的海。而且我相信,这一天一定会到来。面对这样的未来,我们怎样来处理,我们是不是思考过。我们好多员工盲目自豪,盲目乐观,如果想过的人太少,也许就快来临了。居安思危,不是危言耸听。
我到德国考察时,看到第二次世界大战后德国恢复得这么快,当时很感动。他们当时的工人团结起来,提出要降工资,不增工资,从而加快经济建设,所以战后德国经济增长很快。如果华为公司真的危机到来了,是不是员工工资减一半,大家靠一点白菜、南瓜过日子,就能行?或者我们就裁掉一半人是否就能救公司。如果是这样就行的话,危险就不危险了。因为,危险一过去,我们可以逐步将工资补回来,或者销售增长,将被迫裁掉的人请回来。这算不了什么危机。如果两者同时都进行,都不能挽救公司,想过没有。
十年来我天天思考的都是失败,对成功视而不见,也没有什么荣誉感、自豪感,而是危机感。也许是这样才存活了十年。我们大家要一起来想,怎样才能活下去,也许才能存活得久一些。失败这一天是一定会到来,大家要准备迎接,这是我从不动摇的看法,这是历史规律。
华为公司老喊狼来了,喊多了,大家有些不信了。但狼真的会来了。今年我们要广泛展开对危机的讨论,讨论华为有什么危机,你的部门有什么危机,你的科室有什么危机,你的流程的那一点有什么危机。还能改进吗?还能改进吗?还能提高人均效益吗?如果讨论清楚了,那我们可能就不死,就延续了我们的生命。怎样提高管理效率,我们每年都写了一些管理要点,这些要点能不能对你的工作有些改进,如果改进一点,我们就前进了。 阅读全文…
上周有幸参加了长江商学院3天的战略市场营销课程。感觉和之前对一些西方MBA书或文章认知上有较大的差异。西方的MBA注重的是介绍工具和方法,而长江商学院的课程则是把营销上升到了哲学的层面。所以长江推崇的是明道、取势、优术。在课程中除了有通常的案例分析和互相PK的答辩,还有通过一些和中国传统文化(如:孙子兵法、道家、佛教)的思想结合试图解释事物的本质。甚至老师还会带着学生打坐静心。这种培训方式对于我来说是第一次,课后一些感受记录下来以便今后温习。
在授课之前赵老师通过引导让大家能够放空心态,不要我执,对于不能理解的事物不要急于否定,先接受存疑,到思考辨明是非,再到是否能为我所用。其实仔细想想我们在做产品的时候多多少少会用到我们的经验主义。在平时我们看到一些新生的时候的时候容易急于做出判断,对于不符合自己认知的都给予否定。工作当中我们产品经理很难接受别人的意见,将所有的疑问都视作是挑战。我们自认为自己了解用户的需求,而实际上我们所看到的只是我们所利于自己的信息,甚至我们看到用户其实只是镜子中的自己。我们把自己的想法堂而皇之的用用户需求来包装了起来。经过这次课程后,我感觉到自己有一些明显的变化——遇到不了解的事情我不再是急于表达观点了,而是喜欢先说“我不知道。”,然后再花些事情去想想。
其次是解决问题的3个维度,“全面的看问题、本质的看问题、中长期的看问题”。虽然之前也遇到问题的去进行思考和选择,但是缺乏系统性,这3个维度给我思考问题提供一个验证的依据。比如现在的一个项目计划中,我们首先把所有的可能全部列出来,然后再回归到本源,将这些项目重新进行删减,这里面进行取舍。我认为这个由简到繁、再由繁到简的过程其实就是先全面的看待问题,然后在本质看待问题的过程。在难以取舍的时候我就会想到老师提到的“我是谁?从哪里来?到哪里去?”至于中长期的看问题,一旦你明白事情的本质了,这时候短期内你就反而不会执着于一城一地的得失了。
最后对于STOP,我有很深的感受。用我之前的话来理解就是要低头做事,还要抬头看路。我们并不是每天把部门的工作安排的满满的,让每个人都在闷头做事就是好的。需要给大家一些空间去停下来,抬头看看前面的路。去把日常的思考积累下来。甚至有的时候极端的认为,为了做事而做事,不如不做,借着空闲让大家修养恢复,等到需要的时候可以鼓足劲更好的完成任务。其实看看自然界的规律,猎豹、狮子均是及时的STOP,它们精确的计算每次行动,不会忙忙碌碌的死去。
最后的最后,通过老师的照片感觉到世界如此美好,有机会一定也要出去走走看看。
最近看了一些关于在通用搜索引擎里面能够比较精细化的展示用户需要的信息的东东,感觉这些产品都做的蛮有特色,而且应该也发挥了很大的作用,比如google的onebox,yahoo的handout-boss,百度的阿拉丁,都有很多相似之处,先看看onebox有哪些功能:
google onebox是什么?
?????? Google今年在国内大力广告宣传的Google整合搜索,谷歌在搜索时能找到专门信息匹配用户的特殊需求,这些专门信息被排在搜索结果的最顶顶端,也就是第“0″位,统称 Onebox,也就是能够能让你在最快的时间找到你最想要的内容。
阅读全文…

条形码
最近一直在看Query识别方面的文章,觉得对于Query的识别方面还可以做的更好,结合同事做的化工行业的编码识别,觉得应该还有一些其他的类似于行业规范一样的编码能够更好的和商业搜索的东西结合起来。前两天去找商机部门的同事聊天的时候,发现他在研究条形码,希望以后用户在发布商品的时候,可不可以也输入条形码,这样可以减少手工录入的成本,还可以把商品的发布流程变的简单,发布信息更加准确,在检索的时候也能够很准确的进行检索,所以就查了下这方面的知识。
条形码或条码(barcode)是将宽度不等的多个黑条和空白,按照一定的编码规则排列,用以表达一组信息的图形标识符。常见的条形码是由反射率相差很大的黑条(简称条)和白条(简称空)排成的平行线图案。条形码可以标出物品的生产国、制造厂家、商品名称、生产日期、图书分类号、邮件起止地点、类别、日期等信息,因而在商品流通、图书管理、邮政管理、银行系统等许多领域都得到了广泛的应用。
阅读全文…
最近在看一些Query识别方面的文章,然后就顺便研究了下google的Query识别和重写,Google的错误Query的识别和纠错蛮不错,很准,截了两个屏。

意图不是很明确时
当用户意图不是非常明确的时候,google只是给出提示信息,“您是不是要找***”。 阅读全文…
网页的提交一般都是采用表单的方式,通过各种各样的表单项和组合可以形成各种各样的查询。表单的提交方式有两种,POST方式和GET方式,POST方式所有的提交网址都是同一种形式,表单内容都隐藏在HTTP的请求中一起提交的,而GET方式则每次都是不一样的。
我们可以想象每一个Form后面都有一个数据库,每一次Form的提交就类似于查询SQL语句一样:select * from DB where I1=V1 and … and IN=VN 。但是也不是所有Form中的每一个表单都是对于这个数据库是有意义的。比如:排序,分页大小的选择等等。如何得到一个非常适合的Query集合是非常关键的。
为了得到更合适的Query集合,我们想到了采用Query模版,也就是一个Query的表单集,能够迭代得到最多可能的所有的Query。对于一个卖书的商店,对应的Query集合可能如下:
<Z> {select * from DB where zip = z | z are valid zip codes }
<T> {select * from DB where type = t | t are valid store types }
<T, Z> {select * from DB where zip = z and type = t | … }
阅读全文…
From:Google工程师Jayant Madhavan在2008年VLDB大会上的发言。
Deep Web指的是隐藏在HTML表单之后的信息内容,举例来说,对于一个网上卖书的网页来说,用户必须反复的尝试不同的值去提交表单,网站返回给用户的是一个列表展示的各种书的页面,这些内容其实都是属于Deep Web的内容。

阅读全文…
最新评论