听上去很美的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库用管道式的方式写,可能会取得一些方便,但想想还是用原生的语法来做吧。

Read More

写出angularjs风格的源代码提交历史

你的项目中是怎么写提交历史的?

不论你是用SVN、GIT或是其他源代码仓库,去看看实际项目中的提交历史吧,你是否能很快地从中找到之前某次改动吗?

看看这张图中的提交历史,眼熟吗?

这还算是不错的呢,还有很多项目的提交历史根本就是大段空白!很多程序员其实并不清楚为什么要写 **提交历史(commit messge)**。

Read More

结对编程与结对工作

结对编程最早源于极限编程XP中。
每一行代码的编写都是由两个人在同一台电脑前完成的。结对编程提高了软件质量,却并不会影响交付时间。这是反直觉的,但是2个人在同一台电脑前工作,可以产出与2个人单独工作时同样多的功能,同时质量更高。而更好的代码质量和可读性可以节省项目后期的时间。

结对编程的最好方式是在电脑屏幕前并排就坐。不断地滑动键盘和鼠标。一个人敲键盘并从战术层面来思考当前编写的函数,同时另一个人从战略层面思考该函数如何适应到类中。这种做法需要一些时间来习惯,所以不用一开始感觉到的不适应。
除了编码,其他工作也可以结对完成,比如测试、分析、研究等等。

结对的好处在于可以自动地完成代码评审,从其他人那里学习技巧、技术、领域知识,甚至是良好的习惯。两个人在共同工作时可以碰撞出更好的想法,更迅速的解决掉问题。
还有一点,通过结对编程一种很好的传播知识的方式,降低团队核心人员的压力,降低项目的整体风险。

Reference:

用户故事图谱和用户画像

产品愿景

产品愿景(Product Vision)是对未来产品切实可行的构想,建议用一句宣传语来简明地向所有人传递产品愿景。
例如:“针对中型公司的市场和销售部门,CRM-Innovator是一款基于网页服务的产品,提供销售跟踪、商机发现、销售支持等功能以改善客户关系,不同于其他产品,我们产品具有巨大的成本优势。”

用户画像

用户画像(Persona)是真实用户的虚拟代表,建立在一系列真实的市场数据和用户调用数据之上的目标用户模型。建立persona的目的是为了让PO与团队成员在产品设计的过程中能够抛开个人喜好,将焦点关注在目标用户的动机和行为上进行产品设计。PO为具体和特定的人物做产品设计要远远优于为脑中虚构的东西做设计,也更来得容易。有了共同的认知基础,PO和团队在实现产品的时候也更容易对优先级和实现手段达成一致。可以参考书籍《创建定性用户画像》。

Read More

深入理解代码评审

代码评审(Code Review,以下简称CR)是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。其目的是帮助提高代码质量,尽早发现由于编码习惯而造成的缺陷,重新梳理思路,最重要的是促进团队沟通共享,共同识别优秀的习惯和模式,把代码评审活动看做一种 学习活动而非批判活动。

内容

  • 编码风格、文档与注释
  • 代码结构
  • 工具框架的使用
  • 功能和业务逻辑、异常处理
  • 安全性、性能
  • 可测性
  • 工具扫描出的违规项和编译器警告

形式

Read More

TDD测试驱动开发

定义

在编写任何产品代码之前,先写一个测试来表达期望的行为,此时测试应当会失败,因为功能还没有实现。然后编写实现来使测试通过。换句话说,__”只为修复失败的测试而编写代码!”__
TDD要求测试可以完全地自动化运行,通常会借助单元测试作为基础。

Read More

单元测试

单元测试(Unit Testing简称UT)是最微小规模的测试;测试粒度在某个类、函数或代码块。典型地由程序员而非测试员来做。单元测试是在软件开发过程中要进行的最低级别的测试活动,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

在Java语言环境下,推荐采用JUnit,也可以和Eclipse集成或单独运行。

语言环境 推荐工具
Java/Android JUnit
C# NUnit
iOS XCTest
Javascript Jasmine

下文以Java的单元测试框架JUnit4和Eclipse为例。

Read More