转载别人的读书笔记，但是找不到出处了。共8个部分。
豆瓣：http://book.douban.com/subject/21365482/
2014.6.28 “QClub天津”精创周末主题沙龙顺利举行
QClub天津系列活动即“精益创业周末”主题沙龙，于6月28日在天津夏日荷花酒店举行。来自某国际知名户外运动品牌的市场运营总监柴婧女士和来自百度PMO的李忠利老师为大家带来了分享。天津软件沙龙作为协办方提供了会议组织和服务。
听上去很美的O2O本地生活服务
近一两年，O2O（Online to Offline）的概念炒的火热，不管是BAT互联网大鳄，还是秉承精益创业的理想者，甚至传统产业的觉悟者，纷纷跳海。前几年惨烈的团购大战之后，去年的打车软件烧钱补贴还历历在目，誓要改变人们的生活行为。如今战火继续蔓延，保姆、洗车等领域也都卷入其中。
远镜投资的金戈先生，最近家里恰好有保姆钟点工的需求，于是他选用了一款叫做e家洁的app软件。结果他大呼慎用啊，因为这软件真是太“巧妙”了。
他发现，一开始用的时候阿姨几乎90%以上都是好评。定了服务之后：
1.你定的时间他们来不了，会和你重新约时间。
2.你定的人来不了，需要重新指派。
3.指派的人到时间完全不来，还联系不上。
4.投诉后重新派单，居然没到的这单显示完成，要求我评价。
5.该评价不能点差评，文字无法录入自动清空，选1星提交会自动返回4星好评。最终此单会成为默认好评。难怪大部分好评都是所谓的默认好评。
目前的本地生活服务o2o大多是从小时工、保洁等家政服务入手，进一步试图进军家电维保等领域。无论是e家洁、95081、云家政之类都是如此。尤其从小时工领域更易入手，以互联网+LBS的模式一方面为用户提供足够多的选择，另一方面通过评价体系尽可能的消除信息不对称，此外还依赖LBS尽量提高服务效率减少路程奔波所带来的时间浪费。
听上去很美，实际上很难。几大难点：
1.家政服务员本身管理困难，服务质量难于标准化评测和监督，与用户交互界面时间很长，需要培训的关键点太多。这就导致，如果采用纯平台的轻模式（类似95081），则服务质量保证难度较大。而如果采用员工均自聘的模式，则扩张受限，员工人数、用户规模、用工效率也易成为难以解决的矛盾，管理成本也会居高不下。
2.家政服务容易“短路”平台。用户当发现来的家政服务员很满意的时候，往往会选择直接联系服务员（尤其是遇到e家洁这种，很可能你约的服务员来不了会安排其他人的），而如果用户用的家政服务员不满意的时候，用户干脆就不会继续用这个app了。
3.利润微薄，作为中间商家政服务app目前几乎都是烧钱在做。在一个本身客单并不很高的行业，做平台商哪怕收取中介费用是否能支撑起一个足够有规模的品牌令人怀疑。这也是诸位竞争者不断进军新的领域的原因之一。当然，BAT或投资或合作插手其中，自有着大公司o2o战略的考量。
所以，金戈先生觉得本地生活服务o2o从家政入手未必是个好想法，虽然入手容易但想要做好有以上种种问题。还是找个高客单，低频次，易于标准化考量工作结果，用户对消除信息不对称和质量保障要求更高的事儿更靠谱。例如家庭维修安装，汽车保养维修等等。
用Python实现编程练习Kata-FizzBuzzWhizz
Functional programming leads to deep insights into the nature of computation. – Martin Odersky
近日软件匠艺小组的朋友用函数式编程的方式重新实现了一个古老的Kata练习题:FizzBuzzWhizz，用了很多种语言及其特性，非常精妙。这是一个软件匠艺的文艺复兴时代。
原帖见https://codingstyle.cn/topics/100
题目
FizzBuzzWhizz详细描述请自行查阅相关资料。此处以3, 5, 7为例，形式化地描述一下问题。
r1
+ times(3) -> Fizz
+ times(5) -> Buzz
+ times(7) -> Whizz
r2
+ times(3) && times(5) && times(7) -> FizzBuzzWhizz
+ times(3) && times(5) -> FizzBuzz
+ times(3) && times(7) -> FizzWhizz
+ times(5) && times(7) -> BuzzWhizz
r3
+ contains(3) -> Fizz
+ the priority of contains(3) is highest
rd
+ others -> others
Python实现
借助原帖的测试用例，我用python语言也练习了一把。本来想引入Pipe库用管道式的方式写，可能会取得一些方便，但想想还是用原生的语法来做吧。
写出angularjs风格的源代码提交历史
结对编程与结对工作
结对编程最早源于极限编程XP中。
每一行代码的编写都是由两个人在同一台电脑前完成的。结对编程提高了软件质量，却并不会影响交付时间。这是反直觉的，但是2个人在同一台电脑前工作，可以产出与2个人单独工作时同样多的功能，同时质量更高。而更好的代码质量和可读性可以节省项目后期的时间。
结对编程的最好方式是在电脑屏幕前并排就坐。不断地滑动键盘和鼠标。一个人敲键盘并从战术层面来思考当前编写的函数，同时另一个人从战略层面思考该函数如何适应到类中。这种做法需要一些时间来习惯，所以不用一开始感觉到的不适应。
除了编码，其他工作也可以结对完成，比如测试、分析、研究等等。
结对的好处在于可以自动地完成代码评审，从其他人那里学习技巧、技术、领域知识，甚至是良好的习惯。两个人在共同工作时可以碰撞出更好的想法，更迅速的解决掉问题。
还有一点，通过结对编程一种很好的传播知识的方式，降低团队核心人员的压力，降低项目的整体风险。
Reference:
- 《解析极限编程 (Extreme Programming)》, by Kent Beck
- 想要进一步了解敏捷工程实践，关注Certified Scrum Developer国际认证课程
用户故事图谱和用户画像
产品愿景
产品愿景（Product Vision）是对未来产品切实可行的构想，建议用一句宣传语来简明地向所有人传递产品愿景。
例如：“针对中型公司的市场和销售部门，CRM-Innovator是一款基于网页服务的产品，提供销售跟踪、商机发现、销售支持等功能以改善客户关系，不同于其他产品，我们产品具有巨大的成本优势。”
用户画像
用户画像（Persona）是真实用户的虚拟代表，建立在一系列真实的市场数据和用户调用数据之上的目标用户模型。建立persona的目的是为了让PO与团队成员在产品设计的过程中能够抛开个人喜好，将焦点关注在目标用户的动机和行为上进行产品设计。PO为具体和特定的人物做产品设计要远远优于为脑中虚构的东西做设计，也更来得容易。有了共同的认知基础，PO和团队在实现产品的时候也更容易对优先级和实现手段达成一致。可以参考书籍《创建定性用户画像》。