草泽笑的图书主页-查字典图书网

很好很牛逼

2015-08-06

真正的创新，是推动人类进步的创新。而不是简单的把新科技复制到生活的方方面面。而且正确的创新是人类进步的自然规律，不会被一时一刻的艰难低迷阻挡，要一直保持创新世界的热情。

创新性垄断才是一个公司正确的状态。完全竞争导致利润疯狂降低。为了垄断，不一定要击败对手，可以联合，看看优酷土豆，看看滴滴快的，看看58同城赶集。

创业公司的价值不在当下，在未来。所以当创始人，风险很大，工程师工资不能低，创始人的工资却不能高。而持久性盈利有几个特征：专利技术（远超同行）、网络效应（利用小众市场打开网络效应）、经济规模（在小众市场的垄断地位）、品牌（用产品带动品牌）。

风险投资的回报并不服从正态分布（死掉的公司和回报率超高的公司一样少，大多数中等公司一直持平）。实际风险投资的回报遵循幂次法则（一小部分公司完成其他所有公司）。所以风险投资的两个奇怪规则：一，只投资给获利可达到整个投资基金总值的有潜力公司。二，第一条太苛刻，不需要其他规则了。幂次法则适用于所有人，你做一件事情或选择一份职业，是因为你相信它将在以后的几十年里变得很有价值。

为什么要创建公司，我们的世界分成：常识（稍作努力即可达到的目标）；秘密（不懈努力才能达到的目标）；神秘之事（再怎么努力也打不到的目标）。常识和神秘之事都不能创建公司。创建公司基于追求秘密，不受原教旨注意的影响，不受害怕犯错的影响，不受自满或不自信的影响。所有成功的企业都是基于鲜为人知的秘密创立的。找到秘密，不与人分享，而是创立公司，并与公司内部人士分享这个秘密，才是正确的方法。

蒂尔定律：基础没有打好的初创企业是无法挽救的。所有权（谁在法律上拥有公司资产呢），经营权（谁实际上管理公司日常事务），控制权（谁在形式上管理公司事务）。想弄明白这三权问题，不是简单这一章文字能说明白的。简单说，就是合伙人很重要，一定要情投意合；三权要有机结合，投资人与创始人避免不了分歧，产生分歧后，就看权力掌控在谁手里。

创业初期，创业团队一定是志趣相投的一群人，而且远景目标高度一致。

创业公司折戟的七个问题：1，工程问题（技术是否具有突破性，不能仅仅是改进）；2，时机问题；3，垄断问题（要在小市场抢占大份额）；,4，人员问题（合适的团队）；5，销售问题；6，持久问题（未来10年20年，保住市场地位）；7，秘密问题（找到一个没有人发现的独特机会）

总而言之，这本书写的很好很牛逼，然并卵！

读书笔记

2014-12-16

——第一，通过用户参与能够做出好产品；第二，一个好产品通过用户的口碑，是能够被传递的。

——互联网思维就是口碑为王，因为今天用户主要以口碑来选择产品。
**应该说互联网的是用户体验至上，而用户体验的直接反馈就是口碑，这也是互联网信息对称的结果。**

——而今天口碑为王的背后，我理解我们面临的信息传播发生了以下三个重要的转变： 1. 信息从不对称转变为对称； 2. 信息传播速度暴增，影响范围空前扩大；3. 互联网信息是去中心化的传播，通过社会化媒体，每个普通人都是信息节点，都有可能成为意见领袖。
**传统模式下，只有厂商传播产品信息。互联网模式下，用户可以传播体验信息，同时也能或许广告之外的产品信息，比如参数。并且成本为零。

——以前不对称体现在只有厂商对产品有话语权，用户的话语即使发出，也无法传播。现在的对称，体现在用户也对产品有话语权，而且传播更广，权重更大。**
**信息传播的边际成本为零**

——社交网络的建立是基于人与人之间的信任关系，信息的流动是信任的传递。企业建立的用户关系信任度越高，口碑传播越广。
**社交网络的建立应该是基于兴趣关系，维护才是基于信任关系，或者说没有利益冲突下的信任关系。而其中信息的流动和传播，个人觉得有其自身的复杂性，比如信任，比如兴趣，比如用户自我单纯的Show。
很难理解用户与企业的信任度这个关系，口碑应该是基于用户对产品和企业的好感度。**

——互联网思维核心是口碑为王，口碑的本质是用户思维，就是让用户有参与感。
**参与感应该是用户体验的一个更深层次的体验，不仅用户能反馈自我体验，还能看到自我体验在产品上的体现。**

——构建参与感，就是把做产品做服务做品牌做销售的过程开放，让用户参与进来，建立一个可触碰、可拥有，和用户共同成长的品牌！
**这应该是小米最领先的地方，也是很难模仿的地方。**

——三个战略：做爆品，做粉丝，做自媒体。
——三个战术：开放参与节点，设计互动方式，扩散口碑事件。
——“做爆品”是产品战略。产品规划阶段要有魄力只做一个，要做就要做到这个品类的市场第一。
——“做自媒体”是内容战略。互联网的去中心化已消灭了权威，也消灭了信息不对称，做自媒体是让企业自己成为互联网的信息节点，让信息流速更快，信息传播结构扁平化，内部组织结构也要配套扁平化。
**做自媒体，不能定位为传统媒体模式，要定义为朋友模式。**

——消费者正凭借独一无二的个人经历在创造价值的过程中发挥着越来越大的作用。

——正如克里斯安德森在《长尾理论》里的说法：过去，专业者和业余者之间永远存在一道界线，但在未来，将两者分开来谈也许会变得越来越难。

——传统行业的品牌路径是，先砸知名度，再做美誉度，最后是维护忠诚度。互联网企业由于产品即品牌，所以通常是先做美誉度，然后再做知名度。在强调工具化价值的互联网产品中，忠诚度基本很难建立。
小米做品牌的路径：一开始只专注忠诚度，通过口碑传播不断强化这一过程，到了足够的量级后，我们才投入去做知名度。

——对于一个品牌，知名度意味着能让用户听见，美誉度意味着走到了用户身边，而忠诚度则代表已在用户心里。所谓的粉丝文化就是看你的品牌有多少忠诚的用户。

——互联网是注意力经济，一个品牌和事件的关注度，一定要有碰撞、有矛盾、有张力才起得来。所以，传播途中有不同声音不但正常，还可能是好事，在其中因势利导、抓主流就可以了。一件传播事件中，如果有七成是正面声音就很好了，剩下三成负面的其实也无所谓。
**不像传统思维，高大上伟光正才是正确的。有话题，有讨论，才能传播更广更快。**

——用户对服务的根本需求是什么？他们要你发货快，咨询响应快，售后解决问题快。因此，要做好服务的核心，就是一个“快”字。

——如果纵览当代消费电子发展史，我们会发现，当社会经济增长出现跃升、基础科学技术刚刚开始工业化应用、电子产品性能出现跨时代巨大提升时，有着夸张未来感、科技感的设计会大行其道；而当“摩尔定律”适用性开始模糊，“消费主义”风潮涌起之后，用户们的口味则更倾向于科技语言取向平和，更婉转地融入生活设计场景中。

用户故事是敏捷开发的基础

2015-11-03

个人认为，敏捷开发、迭代开发，是软件时代发展的一个必然产物。传统的瀑布模式，已经不能适应当下的需求模式。传统模式下开发出来的软件，并不要求易用性至上，或者由理论大牛根据、市场反馈、人类行为学、心理需求学等等理论，制定软件需求。而面对市场情况不清晰、用户至上、反馈太多的情况，瀑布模式就显得笨重而迟缓。所以，敏捷开发就产生了。
敏捷开发产生的原因：
        1.硬件升级后，编译速度变快，跨平台编程也成为现实；
        2.面向对象编程以及后续的软件发展，使得编写软件相对更加容易；
        3.网络的发展，使得发布、升级软件变得容易，且几乎没有成本；
        4.市场的多变性造成用户的多变性，传统的软件开发方法不能及时跟上这种多变性，且在竞争激烈的环境下，更快的发布软件，更快的满足用户的需求，成为首要问题。

敏捷开发的基础是用户故事，所以用户故事一定是重点中的重点。而用户与开发人员都不一定确定用户故事是什么，所以制定用户故事一定是一个讨论过程，而且随着软件迭代，用户故事是发展的，满足用户故事也是发展的。

敏捷开发的原则是，要让迭代转起来，不停的发布，不停的满足用户故事。

【书摘】
一个优秀的故事应该具备以下6个特点：
        1、独立的。对于相互依赖的故事：1）合并为一个故事；2）考虑其它的划分方法；3）在故事卡上标明依赖关系。
        2、可讨论的。用户故事应该只包含一两句话，用来提醒开发人员和客户沟通，并且包含一些注释，用于标明在沟通中亟待解决的问题。
        3、对用户或客户有价值的。为了保证每个故事对用户或客户都是有价值的，最好由客户来编写故事。
        4、可估计的。如果缺少领域知识导致不可估计，需要和客户沟通，如果缺少专业知识，则可以把故事拆分出一个调研故事，最好将调研故事和原始故事放在不同的迭代中。
        5、小的。需要注意对大的故事需要拆分，而太小的故事则需要合并。
        6、可测试的。尽量采用自动化测试。

DSDM包括一个排列优先级的方法，称之为莫斯科（MoSCoW）规则
        必须有（Must have）：系统的基本功能。
        应该有（Should have）：很重要但短期内有替代解决方法的功能，如果项目没有时间约束，通常认为应该有的功能是强制性的。
        可以有（Could have）：如果没时间就可以在发布中不予考虑的功能。
        这次不会有（Won't have this time）：客户期望拥有但同时承认需要在后续发布中实现的功能。
用户故事不良症兆一览
        1.故事太小：不容易估算cost，且容易分裂故事之间的有机联合。
        2.故事相互依赖：很难做迭代计划。只能把相互依赖的故事放入同一期迭代计划。
        3.镀金：开发人员实现了计划外的功能，但是在验收测试中却没有相应的测试用例，容易埋下质量隐患。
        4.细节太多：在实现故事之前花太多功夫去收集整理故事细节。也可能花了太多时间写故事，而不是讨论故事。只有讨论才能真正了解用户真实的故事。
        5.过早考虑用户界面细节：界面应该是在后期才考虑的问题，用户的故事可能随时在变。
        6.想得太远：想的太多或者太远，都是在预估用户的需求，而在敏捷开发中，用户的需求是时刻变化的。
        7.故事划分太过频繁：在迭代计划中，为了确保迭代工作量合适，频繁划分用户故事。
        8.客户很难为故事安排优先级：可能需要重新讨论用户故事。