昨天飞机晚点，落地回到家已经半夜了。刚刚我还在被窝里，闺女已经过来站在床边大声背起诗来了：“……万里赴戎机，关山度若飞。朔气传金柝，寒光照铁衣。将军百战死，壮士十年归……”
有段时间没和销售一起打仗了。我发现自己还是那么嗜血好战，听到POC拼刺刀就兴奋。来来来，把竞争对手打得满地找牙！
自从公司培训了财务三张表，就热衷于关注各大巨头的负债率。目前亚马逊是72%，京东是64%，腾讯是48%，阿里是36%。
总算到家了
Leave a reply
思绪
今年就是狂出差、狂加班，偶尔出去和朋友聚会。下面是好几次酒局回来出租车上，在手机上记的一些不成体系的思绪（有些可能源于别人向我复述的文章）：
说到底，做金融风控的乙方，客户对你的期望是：名校数学专业科班出身，博士学位是在美国读的，在Capital One干过几年，回国后在阿里金融风控见过世界最大的金融大数据场景……
少年公司心无芥蒂百无禁忌……再过十年就是一个中年公司，盘根错节，一堆know how，满脑子都是SOP，开始靠钱包说话……再过十年就是一个大平台，被新来的人挑战，成天想的都是防守和抄袭……
听他们分享最近读的好书。很多人一年大概读30到40本。突然意识到，自从三年前完成“一年50本并在BLOG分享读书笔记”的FLAG之后，读书量大幅度下降。今年打着加班的旗号，不读书，不思考，不写文字，其实是在偷懒。也罢，今年是gap year嘛。
喜欢跟那些”自得其乐，兴致勃勃“的人相处：沉迷于旅游，沉迷于社交，沉迷于摄影，沉迷于马拉松，沉迷于创业，沉迷于代码，沉迷于销售……
师爷写诗
做产品最关键的原则是懂收敛，场景越具体越好，用户接口越少越好。对toB行业而言，见过太多只懂技术不懂产品的家伙，把底层技术裸着给出去，界面变成“配置地狱”。电影《让子弹飞》里，县长要求师爷写诗：要有风，要有肉，要有火锅，要有雾，要有美女，要有驴。
我年轻的时候，经常以为很多产品做得烂是因为懒或笨。后来才意识到大多数是因为，甲方 or 作者自己就没打算好好做。
艰难但正确的决定
有个很年轻的90后女孩，之前是天使投资基金最年轻的合伙人，打算创业。朋友们都帮她改BP。非常优秀，在目前创投最寒冬的时刻拿到了很多资金。
但是她认真考虑了2周，告诉大家，计划不够成熟，然后解散团队，把钱还给投资人。
昨天我知道了，马上找她喝酒。庆祝她小小年纪能做出如此艰难但正确的决定。
她转眼间已经收到了五六份offer。
云从科技AI平台中心招聘（北京、苏州）
高级Java工程师
工作职责
1. 从0到1全程参与数据治理产品研发落地；
2. 负责数据的采集、清洗、预处理、存储、分析挖掘和数据可视化以及架构设计、开发、部署、自动化运维等工作的具体实施；
3. 设计应用系统架构，出具应用实施解决方案，包括：系统架构设计、接口规范制定、技术文档编写、可用性与稳定性等。
任职要求
1. 大学本科学历，3年以上Java研发经验，精通JAVA，熟悉Python、Linux Shell；
2. 熟练使用SpringMVC/SpringBoot/SpringCloud、Mybatis框架；
3. 熟练使用Mysql/Oracle数据库，了解数据库优化、SQL优化、查询性能等优化；精通数据库架构Sharding、高可用性、主从复制等技术，有相关的性能优化经验；
4. 熟练使用Elasticsearch、MongoDB、Redis等nosql数据库；
5. 具备2年Java开发经验+1年系统架构设计经验；
6. 具备大规模系统设计经验、分布式存储/计算经验、高负载/高并发/高可用架构和调优经验经验；
7. 熟悉分布式存储、搜索、异步框架、集群与负载均衡，消息中间件等技术；
8. 有优秀的解决问题能力，有很强的责任心，有良好的沟通能力。
加分项
1. 有数据仓库开发经验；
2. 具备金融系统研发、架构经验；
3. 有持续集成和结对编程等工程实践经验。
高级大数据工程师
工作职责
1. 从0到1，全程参与数据治理产品研发落地；
2. 负责数据的采集、清洗、预处理、存储、分析挖掘和数据可视化以及架构设计、开发、部署、自动化运维等工作的具体实施；
3. 设计应用系统的规划及架构，出具应用实施解决方案，包括：系统架构设计、接口规范制定、技术文档编写、可用性与稳定性等。
任职要求
1. 大学本科学历，2年以上Java研发经验，精通JAVA，熟悉Python、Linux Shell；3年Hadoop/Spark应用研发实战经验；
2. 具备架构师意识和大规模分布式系统设计经验、高负载/高并发/高可用架构经验；
4. 熟练使用Hive、Spark等大数据技术，并有相关的性能优化经验；
5. 熟练使用Elasticsearch、MongoDB、HBase等nosql数据库；
6. 熟练使用Kafka等分布式消息框架；
7. 熟练使用DataX、Canal等工具；
8. 具备大数据平台运维能力、问题排查解决能力、平台优化能力；
9. 有优秀的解决问题能力，有很强的责任心，有良好的沟通能力。
加分项
1. 有大型数据仓库开发经验；
2. 有持续集成和结对编程等工程实践经验；
3. 具备大数据金融系统或是反欺诈系统研发经验。
前端工程师
工作职责
1. 负责数据治理产品的设计与实施；
2. Web前沿技术的研究和新技术的调研。
任职要求
1. 熟悉各种Web前端技术（HTML/CSS/Javascript等)，熟练掌握跨浏览器、跨终端的开发；
2. 熟悉W3C标准，对可用性、可访问性、http协议相关知识，有深入的了解和实践经验；
3. 精通至少一个MVVM框架（React、Angualr、Vue）等，理解组件化开发和框架底层机制；
4. 熟悉webpack,gulp 等自动化构建工具，拥有丰富的实际配置经验；
5. 熟练使用SVN，git版本管理工具，能根据实际需求进行代码仓库的维护管理；
6. 有优秀的解决问题能力，有很强的责任心，有良好的沟通能力。
加分项
1. 了解任何一种后台语言；
2. 有持续集成和结对编程等工程实践经验；
3. 熟悉自动化测试工具（如Selenium）。
资深测试工程师
工作职责
1. 负责数据治理产品的测试相关工作，保障项目交付质量；
2. 制定测试计划，编写用例，监控项目实施，撰写测试报告；
3. 根据产品特点设计自动化测试解决方案。
任职要求
1. 计算机相关专业本科及以上学历，6年以上的工作经验，3年以上测试开发经验；
2. 优秀的的开发能力，能用Java/Python/Shell进行快速开发；
3. 熟悉软件测试技术、流程、理论、方法，熟悉常见测试管理系统，理解主流自动化测试工具、框架（如selenium、jmeter、RF等）；
4. 很强的分析问题能力，能坚持原则，有项目管理概念，有产品概念。
加分项
1. 有大数据、云计算、机器学习算法的测试经验；
2. 有企业级私有化软件测试经验。
数据产品经理
工作职责
1. 负责数据治理产品的市场调研、需求分析，完成需求文档、原型和API设计；
2. 产品的生命周期管理，在研发、开发、发布和迭代过程中负责沟通；
3. 负责用户体验优化。
任职要求
1. 本科或以上学历；
2. 熟练掌握各种产品原型工具和PRD文档编写；
3. 较强的逻辑思维能力，充分理解商业目标，对市场、行业有自己的调研方法；
4. 善于换位思考，善于跟客户沟通，较强的场景抽象能力；
5. 有极强的跨团队协作能力和执行力，能承受较大的工作压力。
加分项
1. 有企业级软件产品设计经验；
2. 有云计算、大数据和人工智能产品设计经验；
3. 有中台研发团队工作经验。
[得到大学课程作业] 利用“教育家思维模型”管理长期目标
前一阶段CEO对我所在部门进行了调整，剥离了短期业务，剩下的人被明确赋予了一个长期目标。这个目标实现难度很大，但战略上对公司非常重要。
我很同意“教育家模型”这一课的一句话：“管理长期任务的挑战是，时间会稀释你的目标感。”此前我们部门的目标感的确有点模糊。某种意义上，这次组织调整，就是公司高层在用最直接的行动点一下。因此组织调整后，重点如下：
1. 把精力放在统一目标上：
通过All hands和头脑风暴等形式，统一团队共识，让每个人都弄明白这个部门的使命和路线图。我们并不是要求大家像阅兵方阵一样机械统一，相反，希望一线同学根据具体情况作出更高效合理的决策，只要每个人清楚目标和底线在哪里，不南辕北辙。
进一步也花了很多时间和其他部门沟通。总之，把目标昭告天下，争取所有人的知晓和配合。
2. 用持续行动维护信用
我们定下规矩，每两周，副总裁和总监们都要深度讨论和复盘一次。有时候会上吵的很凶，但最终，做了不少“艰难但正确”的决策。
例如，决定向另一个团队让出一块成熟而容易出绩效的业务。因为这个产品与我们的战略目标关系不大，应该把人手撤回来，保证核心战场的“范弗里特弹药量”。
这个行动清楚告诉所有人：“我们是认真的”。一线同学的注意力变得集中；与“礼让跑道”的兄弟部门之间，边界更清楚，信任感更强，他们经常主动为我们提供各种关键的火力支援。
总之，从我的实际体会来看。拥有一个长期目标，虽然一时会面临更复杂困难的局面，但处理好的话，这个目标本身就会变成一面旗帜，让各种人和资源向你聚拢。（具体而言，应该做到“耐心沟通统一目标”、“知行合一维护信用”这两点。）像滚雪球一样，越往后，自己、团队和友军越能获得更多成就感。
[得到大学课程作业] 利用“指挥家思维模型”推动多部门复杂协作
这个季度，由我的部门牵头推动一个重要项目。该项目对公司具有的战略意义，但是难度又很大，尤其是复杂度很高，涉及到7个不同的部门（算法研究院、1个数据中台团队、1个硬件中台团队、1个系统中台团队、3个前台行业部）。所有部门都有各自不同的打法，例如：
- 对硬件团队而言，开一次模上百万，换个供应商一般12个月才能保证稳定。
- 然而，对前台行业部来说，紧贴客户订单quick and dirty，因为每半年要根据业绩末位淘汰。
我是怎么解决的呢？借鉴“指挥家思维模型”，在立项时，通过和各方的反复沟通，统一了重点：
1. 明确业务节奏和进度里程碑。确保业务节拍不同的团队，互相能够产生节奏配合，例如硬件产品推出前大约4个月，市场团队已经开始上一代产品的回访和新技术布道。
2. 规定各个层次产品和业务的关键产出。划出下限，确定最坏情况下也必须限时拿下的山头。同时提前准备好风险预案。
3. 安排内部“吃自己狗粮”团队和Beta天使客户。每一版新产品刚推出，都会在特定的内外部用户先期投入试用，听取反馈，验证产品可行性。通过Alpha 和Beta测试，建立标杆项目，总结最佳实践手册以后，再大范围推广。
总之，通过抓住“同步节奏”、“划定下限”、“先期排练”这三件事，推动复杂的战略项目逐步落地。
[得到大学课程作业] 利用“银行家思维模型”经营人力资源信用
创业GeneDock时精心经营雇主信用，也因此获益：
一、 招聘阶段
GeneDock技术团队始终坚持：
1. 至少四轮技术面试，前两轮必须现场写代码。
2. 最初阶段可以远程视频筛选，但不允许只通过远程面试就发offer。
3. 一票否决，CEO和我（CTO）也不能推翻。
严格遵守原则导致错过了不少人才。但产生了很好的口碑。业内的同行、客户、猎头都对GeneDock的严酷标准有清晰了解。有候选人面试时说：“两年前就一心想来GeneDock，但自己在XX和XX两方面达不到GDer标准，我努力做了这些事……”
我们还通过细节取得信任。例如其他公司的招聘岗位描述（JD）都马马虎虎，只有我们认真“原创”（不止一家大公司曾为抄袭GeneDock招聘文案而道歉或辩解）；再例如，有前端工程师投奔的原因是，上家公司要复制GeneDock的网站，结果他在HTML源码里发现一句话：“呆在只会抄袭的环境有意思吗？给我们投简历吧……”
二、离职阶段
和大多数公司不同，GeneDock在离职阶段花了很多心血。离职一般分为两种：工作不合格被解职，或者能力出色被挖墙脚。
对OKR不合格的员工，不允许直接“杀人”，必须做一次面谈，由组长、我（CTO）和员工本人参加。组长负责详细列出导致不满意的事项，并和员工一起制定改进绩效的Todo List和deadline，给最后一次机会。坦诚沟通往往带来情绪压力和管理成本，但这是对员工负责任的行为。曾有人面临痛苦的绩效约谈，经历激动人心的“触底反弹”，半年后被评为优秀员工。也有同事虽然遗憾离职，却在多年后表达感谢，因为“当时公司让我心服口服”。
对于跳槽的员工，不想让人家走恰恰说明有贡献。优秀员工离开，都会收到一份认真准备的推荐信，向未来雇主列举优点和贡献。于是，很多人跳槽后很久还主动给我们推荐人才和客户。我们曾有一次询问前员工谁愿意回来，一个月后就有“新同事”在All hands上打招呼：“大家好，很激动，我又回来了！”
当然，也遇到过突破底线的恶性事件，对峙公堂；也遇到过资金困难的至暗时刻，夜不能寐……回头看问心无愧，不必细说。
总之，雇主信用不仅体现在招聘阶段，也应该体现在分手时刻。在人力资源市场建立强大的信用带来巨大优势。2018年B轮时，GeneDock创造了“融资额/团队人数”比值的领域历史记录。
BTW：这节课提到如果要对信用资产”加杠杆“，必须保持警惕，个人非常赞同。
[得到大学课程作业] “造物者思维模型”：设计云服务的计费策略
不仅游戏，所有提供虚拟产品的场合都需要应用“造物者”思维模型，制衡各方利益，引导体系演进。我曾负责设计过一个复杂云服务产品的计费策略，深有体会。
简单介绍一下，这个云服务主要用于对上千张表、上P的数据进行复杂的计算。典型的一次计算任务，往往占用上万节点几十个小时，说耗费的存储、计算和下载流量成本超过几十万元。麻烦在于，系统不是独占的，往往有上百个用户的不同计算任务混在一起。
如何计费？常规思路往往从技术实现角度拆分，把一次计算任务占用的进程、内存，以及中间IO交换的数字都拿出来，分摊到对应的CPU、内存、网络设备和磁盘的折旧成本去。然后再加上一定的利润率。
然而，想深一点的话，这种计费策略并不好：
1> 从用户角度看：“运行时间”这个变量用户失去控制。海量数据的分布式计算有特殊之处：很可能第一次运行用10分钟，重跑一下，调度到另一个节点，就用了12分钟。相同的计算任务，有时收1块，有时收1.2块，用户疯掉了。
2> 从平台角度看：如果技术团队优化了底层系统，把计算速度加快1倍，收入就少了50%。这会让平台方丧失优化动力。
于是退回原点，先定义什么是好的计费策略：
1. 基于统计，简单可解释：基于统计；尽量简化；输入参数用户可控；
2. 可预期，可重复：实际运行前就能算出花费；同样的任务重跑，价格不变；
3. 正引导性：各个角色做好事（优化自己的代码）不受惩罚，最好获得奖励。
一个例子是手机话费：两个人面对面手机通话，与一个在城南一个在城北通话，实际成本肯定不一样。如果运营商按照通信链路经过了几个路由器、几次转发来计费，用户就晕倒了。所以手机计费策略采用阶梯的、区域的、分时的模型，符合上面3条原则。
最终的计费模型主要由“输入数据量 * 复杂度”组成，其中“复杂度”是一个简单的阶梯表，完全取决于用户计算作业的难易程度。（更多参考 http://wangleheng.com/2014/07/odps_meter_money/）
几乎同时，谷歌公司推出了同类产品Google BigQuery，计费方案和我们几乎一样。他们甚至在官网上贴了一篇BLOG，详细描述了计量计费模型的“设计哲学”。大家彼此完全独立思考，得出的方法论和最终模型却殊途同归，这很有趣。
总而言之，无论是复杂云服务、电子商务平台……都需要谨慎设计利益策略：尽可能简化规则，保证统计公平性，对“好事”建立正反馈。必要时，不妨参考经典电信服务的计量计费策略。
[得到大学课程作业] 注意投资者思维模型的局限性
这一期4个思维模型都和投资者有关，重点都是建立模型并遵守纪律。如果在复杂背景下进行跨领域博弈，这都是好工具。然而，大多数人不是职业投资者，最好弄清楚模型的适用边界，保证独立思考，以防东施效颦。
亲身经历，作为创业企业的联合创始人，我就有几次郑重提醒自己的CEO：你负责融资，和VC打交道很多，似乎被他们的模型“过训练”了。
举个例子，这些年很多风险投资人都在强调“网络效应”的概念：不仅仅企业和客户存在买卖关系，客户之间也能互相连接，进而增加系统粘性。对资本而言，这种生意可以通过烧钱进行催化，最终通过网络规模建立垄断。很多投资机构把“是否有网络效应”写入模型，以决定标的估值。
“网络效应”的思路适于 toC 基础服务。进入其他领域，例如 toB 企业级服务，情况就变了：
1. 从业务逻辑而言，企业不太可能因为同业或上下游的公司在用某个软件，就非用它不可。甚至恰恰因为是同类企业，所以存在关键需求的差异：竞争对手强调品牌营销，我强调供应链降成本……这意味着，对手的软件供应商未必合适我，应该寻找符合自己战略的解决方案。toB 采购更强调“标杆效应”：供应商的方案与企业本身的策略一致，且已有成熟的落地案例。
2. 从产品逻辑而言，“网络效应”本质还是增加迁移成本。但并非只有这一条路能增加产品粘度。大多情况下，做好功能和服务，解决客户问题，让他没有离开的动力，就够了。尤其是toB 场景，没有企业会乱折腾，轻易迁移软件系统。
回到投资者的角度。他们喜欢建模，简单点说，就是外行总结过去的成功经验，以筛选更多投资机会。模型就意味着抽象概括。投资者有机会多次下注，只要掌控概率就够了，创业者却是All in，因此必须洞察每个关键细节，细节是魔鬼。
淘宝免费，不符合“产品必须收费”的陈规；京东做物流，不符合“尽量做轻”的陈规……随后，投资人跟随成功创业者修改了自己的模型，然后又对下一代创业者说：“你必须XXX，我才投你”。
总结一下，专业人士要相信自己在客户现场获得的洞察，不要屈从陈规俗见，不要被投资界的模型过分“驯化”，导致动作走样。我们最该从巴菲特和索罗斯那里学到的，正是独立思考本身。