|
4 重视数据而不盲从数据 决定产品方向时, 要的是想象力, 激情和胆量, 而不是数据. 数据能让你的团队沿着正确的方向前进而不出轨, 也有助于产品从“一开始是什么样”到“最后应该是什么样”的逐渐优化成型. 但数据不能帮你决定方向. 举个例子, 当我们在人工智能(机器学习)上压上我们团队所有的资源的时候, 我们忐忑不安. 但是我们坚信一点, 现有的基于人工规则引擎的防欺诈系统会很快成为死胡同, 因为它太死板而且不易规模化以处理大数据。所以, 就像在电影指环王中Frodo明知通向Mordor的道路很黑很冷很危险, 但那是一条他必须要选择去走的路; 我们选择了在机器学习上压上所有的宝。失败, 整个团队会很难看; 但我们决定走艰难但我们认为是正确的路. 这种思路同样应用在如何设计用于用户报告(外部工具)和案例审查(内部工具)的工具来应对潜在的欺骗行为。 我们最后决定的方向是”进行自动处理”和”建立反馈机制”。直接抛给人工来处理总是很容易被选的一条路, 因为只要建立一个人多人傻的客户支持团队即可. Lame! 我们希望通过自动处理来解决大部分的欺诈案例，而把精力则放在那些确实需要单独处理的特殊案例上, 同时把从业务支持团队(即客户支持部门)的处理意见自动采集并集成到下一轮的机器学习中去。由此, 我们的机器判断会越加精确和聪明且与时俱进. 但你不能忽视数据。没有数据的支撑而一味靠直觉走黑路, 很容易走岔道, 甚至大错特错。有一段时间我们认为爬 行工具(通过分析关联的cookie,信用卡)可能可以找到很多欺诈的同伙。通过实验结果却发现, 这种预期是否成立很大程度上取决于当前流行的欺诈行为的特点. 比如, 当失窃或贩卖信用卡的案例非常普遍的时候,关联分析是一种有效的方法。但如主要情况是帐户被黑或小宝们冒用妈妈的信用卡去网游消费时，关联分析就作用不 大。直觉在现实前面碰了一脸的灰。 不过幸运的是我们很快意识到这点且把这个项目叫停了, 所以没有浪费太多的资源。 另外, 顺带提一下A/B测试。A/B测试并不会告诉你去做什么产品，但它可以帮你确定实现产品时的哪个细微版本更能揪住用户大爷们的心. 5 避免无谓的时间浪费 刚进Facebook做工程师的时候，我非常享受那种日夜泡在码海中的感觉。后来慢慢的承担的项目责任越来越大越来越多，写代码的时间越来越少(但 绝大多数时候仍占大头). 有时候更多的是把时间花在决定产品的方向和设计上。很多事情是和产品经理设计人员一起搞的. 但在Facebook攻城狮们有很大的发言权甚至有些时候是拍板的权力。Facebook希望攻城狮们有王者风范. Facebook希望攻城狮能决定自己要做什么应该做什么, 而不是总是”被决定”做什么(一种流行的说法是，write your own job description). 因此，我花了大量的时间在思考这些问题 – 哪些功能需要添加，哪些功能需要删掉，需要开始或停掉哪些测试，我们正在流血流汗的是不是现在最最最重要的问题, 我们是该花时间优化用户交互流程呢, 还是减少出错率, 还是让系统更快, 等等。这些问题很伤脑筋, 答案经常不确定, 比一个劲码到手抽筋要难. 但这些问题很重要, 甚至可能决定了你熬的日日夜夜究竟有没有必要. 建议所有的攻城狮思考思考代码之外的这些问题, 团队领导者就更有必要了. 当然, 攻城狮的大多数时间还是应该花在代码上. 那究竟哪些时间不应该被浪费呢？ 很多, 但我只举两个我认为最重要的例子。 邮件。不是所有邮件都发而平等。有些邮件纯粹打酱油的. 有些邮件是不需要马上处理的. 我尝试使用过滤规则来踢掉打酱油的邮件, 突出需要马上处理的重要邮件。对此，分享两点。 1) 建立一个适合你的邮件过滤系统. 我会对重要和紧急的邮件做即刻回复，而暂缓处理那些可以等到晚上再回复的邮件（尤其是发自我自己的团队，产品经理，兄弟连和顶头的不顶头的上司们的邮 件）。但是，我要确保在我挣扎的爬到床上之前，把这些邮件全部处理掉, 读的读, 回的回。对于那些仅供参考的邮件，过滤系统会将其塞到某个固定的角落，我隔三差五去瞅瞅。此类邮件诸如某酒鬼询问Napa Valley哪个酒窖比较正点等等. 这些邮件通常比较有趣, 挖的坑很大很深所以也很耗时间, 我通常不跳或者不马上跳。 2) 广而告之你的个人邮件处理策略. 我让我身边的战友们知道我是如何处理邮件的, 并把这个政策放到我所有的邮件末端。如是说 – “正在尝试个人邮件处理策略-为了戒掉Email瘾, 我将强迫自己每隔三小时或以上查看一次Email，急事请电话/短信/IM我” 这么做更多的是让别人明白不要指望马上得到回应. 其实我查email比每3小时要频繁, 但至少不用马上逼得去回每个email了, 我可以憋着悠着点. 因为如果真的很急, 我的iPhone应该已经响过了. 而且, 批量处理真的效率要高很多. 不骗你. 会议。开会太容易变成一群人互相在扯对方的蛋. 浪费时间而且开完后发现没有结论且很蛋疼. 但开会对于teamwork很多时候是必要的. 如何主持会议是门学问, 这里不细谈. 不过, 你不可能也不需要参加每个邀请你的会议。当你认为你参加某会议于己于人都无太多价值的时候, 建议你考虑不去。如果想要有礼貌一点, 那就写个email问问主持人你是否可以缺席. 通常当你想过这个问题决定发这样的邮件时，答案通常都会是yes。有些时候我也会很可耻的让我的产品经理替我去开会。当然，我会鼓励他也争取不要去。Only make the meetings you really have to. 同样, 我要求我自己的团队在组织和参加会议的时候要慎重，也经常问他们想想看自己花在会议上的时间是不是多了。一个做法是把可能的会议都整合在一起。有一个例 子。早些时候, 我们会经常收到来自支持团队的比较随意的会面请求。这让攻城狮的一天被会议分割得支离破碎. 写代码的都知道没有3-4个小时的连续时间是不容易高潮的. 而且这种会议通常效率很低. 于是，我们改变了做法，每周安排固定的答疑时间(office hour)和支持团队嗑想法然后follow up。当然, 紧急的问题另当别论应当马上处理. 有一个被经常忽略的原则 – 有意识地去思考哪些事情不应该做并且马上不做。例如，哪些是无谓的争论可以避免介入，哪些功能可以放弃，哪些关系不应该发展, 哪些人应该开掉, 等等。我经常问自己一个很简单的问题，我现在正在做的是否对我的目标很重要。如果你清楚自己正在做的和自己想要的，答案会明了。Go for it. 6 增进亲密感是减少紧张关系的有效方式 工程师和支持团队之间有着纠结的合作竞争关系(注意, 合作在前)。互 联网技术公司中很多人(尤其是聪明人)总是期望工程师对所有问题给出一个让人会心一笑的解决方案。但现实是，不是每一个问题都可以或者应该在技术框架下解 决。对于一些具体的问题, 客户支持和运营部门会有一些非常深刻独到的见解. 工程师未必行. 毕竟很多见解需要不同的专业知识, 依靠实地经验。没错, 工程师可以在代码中自动log大量的原始数据，但从原始数据中提炼可靠的判断却并不总能如愿. 和很多其他公司的客户或支持部门不同, 我们的支持部门招募了质量相当好的员工(很多来自美国名校 – 在我直接接触的反欺诈支持组20来人中就有3名斯坦福校友)。因此，当两群都很聪明的人观点相左时，该听谁的呢? 紧张关系再所难免。 不同的工程师团队也存在着合作竞争关系。 反垃圾邮件、安全和反欺诈（我的团队）这几个团队之间存在密切的工作协作关系。这些团队也都尽可能地相互学习，分享经验和技术。但是，有时候各团队独立处理类似但不同的一些问题时，都试图向对方推销自己的解决方案和理念。 如何让合作竞争保持在一种健康有序的状态? 我觉得关键是促进人与人之间的亲密感。把 人搞近了, 事情就容易了. 我花大量时间用在建立和其他团队的关系上面。例如两周一次或者一月一次和其他团队老大们的1对1碰头会。越相关的团队, 头碰得越频繁. 我自己或者我的团队成员会有选择性的经常参加一些其他团队的会议 (我们称之为Friends & Family meeting)。当为一个共同的大项目工作时，我曾安排不同的部门成员（工程师、支持、数据分析、金融财务）坐到一起进行项目冲刺。这是拉近相互之间距 离的非常有效的一个做法, 尤其对于减少扯皮的机会. 因为互相之间经常会请或被请喝咖啡 (可称之为“咖啡外交”). 我也会经常和一些人约定吃工作午餐, 经常聊的是家常, 增的是感情。有的时候一次长距离的散步也更能让人畅所欲言。而这样的紧密关系，在我们面对一个极具挑战性的项目的关键时刻，会帮助大家紧紧的抱团闯关. 7 习惯委托, 但不要盲目, 请谨慎 分配任务委托别人的重要性比较容易理解. 因为你不是超人, 不能端茶倒水什么都做吃喝拉撒什么都管. 有些时候, 你往往还不是最适合的人选. 当团队一大事情一多, 你一定要学会委托别人来负责合适的任务. 对有些领导者而言, 委托别人一个重要的目标可能不是很放心, 觉都睡不好; 但我非常习惯委托别人, 有时候可能太习惯了. 这是我一位前老板给我指出来的一个问题. 有一次我给一位组员分配了一个既有技术难度又有协调挑战的难题. 进程比较缓慢. 但我给了他太多的时间空间来折腾, 而事实上他在某些方面需要一些加强, 有些方面需要我更多的主动的帮助. 我老板指出来, 如果我要让别人随便折腾的话, 前提是我需要有足够的信心. 我需要有事实来逐渐证明我的决定是正确的. 需要谨慎委托. 因为如果项目失败, 对他而言, 最终负责的人还是我, 不是别人. 所以我不能以别人不行来给失败的委托埋单. 如果你有一个重要的任务需要委托给别人, 你要么 1) 已经对此人非常了解. 知道他战斗力非凡可以搞定; 或者相信他可以迅速学习提高打鸡血搞定; 要么 2) 需要在一开始手把手教他, 时不时问他, 直到你对他有足够的信心. 具体我是这么做的. 项目开始时, 我让被委托人给我一个整体计划以及几天内可以完成的任务. 一开始经常会面跟进, 然后确定后几天的任务. 根据每次完成状况来估计他能不能”高快狠”地完成最终的目标. 信心逐渐建成后可以减少关于该项目的细节讨论. 此时的委托可以放得更开. 但有一点要注意, 如果跟的太紧的话, 可能让人觉得你对他不放心, 他也会做得畏首畏尾, 这可能比盲目的委托还更差. 所以在委托和谨慎之间, 有一个微妙平衡. 我觉得在这一点上我还要加强. 这里也和大家提个醒. |
