管理者如何做好团队规划

之前看过一篇文章,讲述的是孙正义如何设定目标及如何达成目标, 具体的原话忘了, 大概的思路是: 先设想自己10年后想达成的状态和目标,之后再分析要达到这个目标, 在第8年的时候需要哪些资源, 需要达成怎样的状态, 之后不断倒推, 直到当前;当然, 这么牛叉的目标设定方法, 不是每个人都能掌控的。。。

以前也曾经听一个Google资深产品经理的讲座,介绍Google的产品设计理念时,也提到Google一开始会将产品设想得比较宏大, 之后从某一个小点入手推进该产品,直到将该产品越做越大, 直到影响几乎全人类。。。

进行团队规划时,也是如此。下边就来介绍下在团队中, 一般我们是怎么做团队规划的吧。

简单来说,团队规划,是不断回答完善以下一系列问题的过程,这些问题需要在工作推进的过程中定期review和调整:

  1. 希望你的团队成为怎样的团队
  2. 现在离理想状态还有多远
  3. 分几个阶段每个阶段如何做才可以做到
  4. 需要哪些资源才能做到这样的团队

希望你的团队成为怎样的团队

这个问题,解决的是目标问题, 我们经常说‘指哪打哪’, 这个问题就是回答‘指哪? 以及是否指对’  的问题。 这个过程相当于为团队明确定位, 例如需要明确团队的职责, 理想的团队梯队和组织架构, 团队的意识和价值体系, 理想的团队氛围, 团队能够对更大范围产生的影响和输出价值。

明确团队的职责和定位: 这个相当于是限定了团队所要做的工作的范围以及价值, 例如之前我们对位团队负责百度搜索变现流量的挖掘,以便提升公司搜索变现效率。 这就是团队的职责,符合该职责的工作, 都需要考虑是否去做。 在这样的目标设定下,首先可以选择一些当前认为重要的, 且可以做到的事去做,量力而行,逐步推进。 之后可以设定设定一些未来看起来有希望的能够做到的重点工作作为中期目标进行推进。在设定中期目标的时候,一定要抓住重点,例如以前我的老大就跟我说过: 抓住最重要的3件事,避免大而全。

团队一般还会有其他的一些目标,但这些目标一定是围绕着团队的职责来设定的,例如组织架构是为了更高效地完成团队的职责,而且好的组织架构可以用一张清晰的图就能表述清楚;团队的价值体系也是使用简单明了的话就能进行介绍; 最好还能够形成几句比较好记,琅琅上口的团队口号, 这样能够让团队,员工更有凝聚力, 这个很重要。 例如经常说百度的使命是:‘让人们更便捷地获取信息,找到所求’, 我们团队会经常类比, 说我们的职责是:‘让广告主更高效准确地覆盖适合他的流量’, 简单地一句话就能概括团队的职责。

如何确定团队职责和定位是正确的:这个可以从多个角度来验证,例如和自己的上级, 下级, 平级的同事讨论。这个非常重要,团队的职责很多时候只有得到老大的认可这是必须的,如果老大都不认可这样的定位, 那后续的工作几乎能难开展(或者从某种程度上也没必要开展: 毕竟谁出钱谁拍板!),也很协调到资源来做。 与下级讨论的主要目的有两方面, 一方面下级对团队也会有自己的看法, 可以让管理者从另外一个角度来看团队定位职责是否正确, 因为有些资深员工还是会有自己非常独到的看法,从技术的角度来对这个问题进行审视; 另外一个主要的作用,就是可以看下下级对团队职责定位的认可程度, 毕竟他们是这些职责定位的落实者, 他们具体做事,只有他们认可,后续的工作才能顺畅开展(当然即使某人不认可, 也可以通过多次沟通进行说服)

另外需要注意,这个阶段更主要的是确定近期目标, 例如半年或一年目标, 所以需要确定的事既要比较实际,又要有所拔高; 同时也需要往前看一两年, 心里边要有一个大致的谱: 一两年后,自己的团队会走到哪里。

现在离理想状态有多远

分析团队现状:在指定这些目标的时候, 非常重要的一点,就是需要分析团队的现状: 例如团队现在的梯队,组织架构, 氛围, 相当于我们设定目标的时候是从当前的实际情况去做拔高,这个非常重要,如果起点很低,而将目标设定的非常高,也不是说不能实现,但有可能会出现目标过高导致不可能实现(具体设多少,是个技术问题,有时像又是个艺术问题)

例如11年团队调整的时候, 当时关键词搜索推荐团队分为工程, 策略团队(当时的现状), 后来考虑到这种组织架构会导致策略调研和策略上线之间存在断层(分析‘现状’), 出于提高团队策略迭代速度的考虑, 后来就将工程团队和策略团队进行合并, 且重新制定开发流程, 即后续很多项目, 都是从策略调研, 开发, 到最终推上线小流量乃至全流量都是由唯一负责人负责, 这样就避免了原来策略团队策略调研完毕后, 工程开发同学还要向策略同学了解具体策略考虑的代价, 同时工程同学也不会再觉得自己就是个外包, 避免了那种帮别人实现算法的失落感。 当架构有非常大的调整时, 才会引入外部纯工程团队, 一起合作推进架构的重构。

规划时,排除干扰因素:在很多公司我们都会说: 拥抱变化, 或是说: 世界上唯一没变的, 就是变化。 的确很多时候我们在做规划的时候, 都是在一个动态发展的节点对未来进行预见,会有很多变数。 例如13年就碰到两次大的团队调整, 而且第二次调整时, 团队调整方案已经定下来了, 而且已经和团队成员沟通了团队调整方案后, 突然接到老大通知, 调整方案有变, 整个团队会很快被划到另外一个部门, 后来不得不重新进行规划。 在这样变化的环境中, 会有很多的干扰因素, 但规划的时候, 其实可以在一定程度上先排除这些干扰, 否则考虑太多这种干扰因素, 会导致规划无法进行。

分几个阶段达到理想状态每个阶段如何做才能做到

分几个阶段做: 每次做年度规划的时候, 都觉得第一季度的事是相对比较明确的,第二季度的也还基本可以预知,但第三,第四季度的就很难把握了, 而前面也提到, 指定规划后, 需要定期review和调整, 所以每个阶段,最好不要超过一个季度,否则可能出现有些方向走偏但没有意识到的情况。每个阶段进行review,之后根据当前的进度进行目标的调整。 如果有些目标的达成需要太长时间, 则可以将这个目标达成再进行分解,避免某个节点持续时间过长。

需要哪些资源才能达到这样的团队水平

设定了上述预见的远景外, 就可以分析, 要达到该远景,需要哪些资源了。

资源可以从几个维度去区分:自己团队需要那些人, 需要上级的哪些支持, 需要兄弟团队的哪些支持,需要更大环境的哪些支持。

例如, 我们在进行百度关键词搜索推荐引擎团队规划时,认为后续需要在机器学习上进行加强, 于是开始联系HR,让其帮忙招聘更多机器学习方面的同事,同时开始联系擅长机器学习的团队, 一方面希望从兄弟团队引入对我们的项目感兴趣的同学,另一方面也了解他们团队中的机器学习工具和技术。

再比如之前团队调整过程中, 觉得关键词搜索推荐应该加强与百度检索投放系统的联动,所以后来与老大讨论后, 将底层涉及基础技术的topic model 方向划到了关键词搜索推荐小组。 这就是需要上级支持的典型。

还有一个大原则, 就是上述的规划,并不是一经制定后就是一成不变的,我们经常说计划赶不上变化,那为什么还要做规划?   规划的更大的作用是能让我们能将这些事在现阶段想清楚, 就类似于说拿破仑虽然每次战争都不是按照作战计划进行, 但每次战前他都会制定周密的作战计划。 所以, 我们要对规划怀着开放的心态,做好调整的准备。

百度关键词工具介绍参见:http://support.baidu.com/product/fc/4.html?castk=24b18bi7062c720d0d596

也可关注我的微博:  weibo.com/dustinsea

或是直接访问: http://semocean.com

关键词推荐工具中的用户引导机制之二:suggestion架构

在《关键词推荐工具中的用户引导机制之一》 我们分析了用户用到机制对搜索引擎/关键词工具的重要性,同时也提到按照用户在搜索引擎/或者关键词工具上交互的阶段,可以按交互前,交互中和交互后为用户分别提供种子query,suggestion和相关搜索词对用户进行引导。 种子query是比较经典的推荐问题, 对于‘相关搜索’,后续会有博文专门介绍, 该文以下内容主要介绍如何构造高效的suggestion服务。包括架构及内部检索逻辑。
suggestion到底有多大作用呢, 在很多搜索引擎中, 一方面,从自然搜索结果的角度,suggestion能够引导客户将输入表现的更利于搜索引擎理解用户的意图,得到更优质的搜索结果; 另一方面, 从商业变现的角度看, 大的suggestion策略的上线, 往往能够带来搜索引擎几个点cpm的提升, 这可是非常了不起的贡献。 所以对于搜索引擎, 和关键词推荐工具这样的基于搜索的系统, suggestion的作用就至关重要。
图: 百度suggestion效果
图:关键词推荐系统suggestion
基本概念
要了解suggestion的设计细节,需要先定义以下名词:
  • Query片段:特指query的前缀,例如用户输入的query为“鲜花快递”,其全部query片段为‘鲜’,‘鲜花’,‘鲜花快’,‘鲜花快递’。
  • 拼音片段:本文中特指query片段对应的拼音片段,例如用户输入query为‘鲜花’,则全部拼音片段为‘x’,‘xi’,‘xia’,‘xian’,‘xianh’,‘xianhu’,‘xianhua’。
  • 候选query:指挖掘出的候选种子query。
  • wcode:建立suggestion 索引时,为每个候选query的编号,该编号值表示对应字面在数组结构中的下标位置,为无符号整型。
  • 个性化suggestion:根据客户帐户信息进行推荐的query suggestion。
  • 通用suggestion:与个性化suggesion对应,所有客户都适用的query suggestion。
解决方案的权衡
索引方式
suggestion可以做得比较简单, 也可以比较复杂,例如在搜索引擎搜索框中, 可以输入汉字, 拼音, 或者输入几个汉字后,又将输入法切换为拼音进行输入, 或是正好反过来。 这样对于suggestion,就需要考虑是只对汉字输入query提供suggestion结果, 还是需要对混合输入(拼音+汉字)query提供结果。 不同的功能会导致实现不一样。
 
图:全拼音模式suggestion
图:汉字+拼音混合模式suggestion
经过统计,候选query平均长度为13.9字节(约7汉字),其对应的拼音平均22.1个字母。如果仅对汉字建立索引,则可假设每个候选query对应7个query片段索引片段,而如果要对汉字+拼音建立索引,则每个候选query需要对应约30个索引片段(7+22=29)。但建立拼音片段能够支持用户拼音输入,或是中英文混合的情况,所以要达到较好的用户体验, 最好是实现: 索引结构支持拼音+汉字方式
性能
作为引导机制,suggestion的性能必须足够快, 应该做到迅雷不及掩耳的速度,否则在用户灵活的手指配上高效的输入法下出现任何一顿一顿的感觉, 都会异常影响用户体验, 所以在内存允许的情况下, 所有数据常驻单机内存,是比较理想的情况, 如果单机内存存放不下, 那么可能的选择是使用资源定位系统,将数据进行水平拆分(最简单的方式, 按照query签名作为key,然后取模)
P.S. 对于如何对数据进行扩展, 推荐大家仔细揣摩《ebay网站架构原则》, 每一条原则都值得细心思考体会。
图: 水平拆分,例如按照key签名取模
使用该方式, 请求可轻松达到1w+/s
结果merge及rank
suggestion返回结果由个性化suggestion(针对每个用户单独挖掘)与通用suggestion结果组成,个性化结果在前,通用结果在后的方式,当个性化结果不足时由通用结果补足。
其中,不管个性化结果,还是通用结果,由两部分组成:原始query片段索引结果与拼音query片段索引结果。对于二者的merge方式存在两种思路:
  • 原始query片段索引结果与拼音query片段索引结果merge,按权重从高到低排序,返回前N个结果。
  • 优先返回原始query片段索引结果,数量不足时由高权重的拼音query片段索引结果补充。
从用户体验与效率考虑,原始query片段索引结果与拼音query片段索引结果的merge方式采用思路2。
思路2还有一个问题需要考虑,原始query片段索引结果数量不足时,进行字音转换成拼音串后,存在拼音串片段检索结果与用户输入query的汉字串前缀不一致的情况。例如:query为“鲜花”,转换成拼音串“xianhua”后的检索结果可能有“鲜花”,“仙花”,“闲话”,这时候的检索结果可能包含“仙花”,“闲话”同音但不同字的suggestion结果。从检索逻辑复杂性、效率、数量量考虑,针对纯汉字串片段索引结果数量不足时,不进行字音转换后的拼音片段索引检索。
针对非纯汉字串,原始query片段索引结果数量不足时,通过字音转换成拼音串片段进行检索。在检索过程中,考虑最大汉字前缀匹配的方式。例如:query为“鲜hua”,转换成拼音串“xianhua”后的检索结果可能有“鲜花”,“仙花”,“闲话”。在此例子中,会使用汉字前缀“鲜”去与候选query进行匹配,最终得到候选query“鲜花”。
使用上述方式, 可以在保证结果个性化(个性化结果需要在离线进行挖掘)的同时,保持suggestion应有的高效。
内存数据结构
在决定了使用全内存的存储方式后, 就需要考虑内部数据结构的设计了。 要想让效率最高,最快的方式就是直接使用hash进行query片段签名查找。
图: hash方式进行倒排查找。
索引中主要包括以下结构:
片段索引字典:存储片段签名到片段推荐词倒排的偏移地址。使用bsl::hashmap存储
片段至推荐词倒排索引:存储每个片段到候选关键词wcode的倒排索引。使用hashmap存储。通用拉链与个性化拉链倒排拉链合并存储,区别在于个性化拉链不仅包含关键词wcode,还包含关键词的个性化weight。两种结构根据标志位flag进行区分。为了提高在线服务时,合并字面返回的效率,针对每个索引的拉链会有序(weight从大到小)存储。
字面队列:存储具体wcode字面与字面权重,使用bsl::deque存储,片段至推荐词倒排索引中的wcode值即为该队列索引下标。
在线检索流程
当用户在搜索框进行suggestion请求时,会经过对片段进行归一化,查找汉字索引片段,查找拼音片段及merge结果阶段,结果merge及rank主要的原则是汉字片段结果排在拼音结果前, 各类结果内部按照线下挖掘的权值进行rank。 线下挖掘在业界及学术界的方法参见后续博文。 附上一个流程图, 类似的画法是在工作中逐渐形成的习惯, 其中将function和data structure单独分开表示, 虚线表示数据依赖, 实现表示处理逻辑依赖。  该方式自己觉得比较清晰, 特别是对照着文档写代码的过程中:)
更多内容可参见:
《eBay网站的架构原则》 : 网上都有,每一条扩展原则都值得细心揣摩及体会,各大搜索引擎大数据的支持原则异曲同工
也可关注我的微博:  weibo.com/dustinsea
或是直接访问: http://semocean.com

推荐系统中的相似度度量

Cosine

最常使用的相似度计算方法,而且总体效果较好,可以说是简单实用。数学描述如下:

cosine_define

其中 是X的模。

例如,在推荐引擎中,使用 r_ui表示User u对Item i的打分,则可以使用u对各Item打的分数的向量作为User u的兴趣爱好,则User u和User v之间的cosine相似度计算方式为:

cosine_define1

其中 I_ui 表示User u,v均投票了的item。

Cosine的几何意义为向量空间中,将待计算相似度的向量均归一化为长度为1的向量, 所有被归一化后的向量  ov的v点坐标均落在以向量0为球心,半径为1的球面上,使用二向量的夹角度量二者相似度,夹角越小,相似程度越高。

在文本处理过程中,cosine度量方式表现效果都会比较好。

Mahout中参见CosineDistanceMeasure.java

Pearson Correlation

用于度量线性关系最常用的方法, 定义 为协方差,σ为标准差, 则Pearson相关系数为:

Pearson_num

例如,使用 表示User u对Item的打分,则User u,v之间的相似度计算方式为:

Pearson_num_2

其中 表示User u,v均投票了的item,与COS的区别是考虑了投票的均值, 且分母考虑的是User u,v共同投票的Item。

很多时候,针对User的PC要比针对Item的PC效果较好,因为针对User的PC相当于对各个用户的投票Scales做了一个中心化,避免各用户对相同Item投票时,因为投票习惯不一样而导致的差异。例如:投票分值分[1,5]档,有些人投4表示非常喜欢, 而有些人会投5表述相同的喜好程度。

PC的缺点如下:

  1. 如任意User仅投票了一个元素, 则无法使用该公式计算。
  2. 如任意User的每个投票分值均一样, 则无法使用该公式计算。
  3. 计算时没有考虑投票的总数量, 例如User u投票了200 Items,而v仅投票了2Items,则最后有可能还是v与待比较User近似。

另外PC也经常用作序列趋势的相近程度度量。在检索,推荐系统中经常需要考虑检索结果及推荐商品的季节因素,例如根据往年某一商品的季节特征,预测类似产品的接下来的流行程度。 下图分别为检索词‘吴莫愁’,‘梁博’,‘滑雪’在过去3个月的搜索PV,使用PC度量,很容易得到检索词‘吴莫愁’与‘梁博’的相似度远远大于‘梁博’与‘滑雪’的相似度。

tread_liangbo_wumochou

Mahout中参见PearsonCorrleationSimilarity.java

Spearman Rank Correlation(SRC)

Spearman Rank Correlation和Pearson Correlation非常类似, 只是SRC没有考虑对User对某具体Item的投票,而是考虑Item 在User所有投票中的相对Ranking。其数学表示为:

SRC

其中 k_ui表示User u对Item的投票值在User u所有投票中的Ranking。

SRC的优点是能够避免每个用户因投票习惯不一致带来的误差, 缺点是计算开销较大(每次计算都需要进行排序)

Mahout中参见SpearmanCorreleationSimilarity.java。计算复杂度较高。

Simple Matching Coefficient

imple Matching Coefficient

仅考虑数据为二值的情况(0,1)。 如果数据非二值, 则将数据转化为为二值。定义M01为u中属性为0,但v中属性为1的数量,M00表示u,v中属性均为0的数量,M10,M11同理。则SMC定义如下:

SMC

例如u=[1,1,0,0],v=[0,1,1,0],则SMC=2/4=0.5

Jaccard Coefficient

与SMC计算方式类似,但具体运算公式如下:

JC

即仅考虑两个向量中,同一维度上值均为1的数量。该相似度度量公式在文本匹配中也较为常用, 比如在计算两个短字串的相似度时,首先将字符串切词,找到更细粒度的切词结果term,之后以不同的term作为不同维度的属性,使用JC计算相似度。

Extented Jaccard(Tanimoto)

extend_JC

 

距离度量方式

该度量方式是最直观的度量方式,一般使用曼哈顿,欧几里得距离度量,而更为广义的是闵科夫斯基度量方式。以Euclidean Distance为例:

欧几里得距离计算公式

可简单转化为相似度则表示为:

欧氏距离转相似度

在Mahout中参见以下实现:

EuclideanDistanceMeasure.java

ManhattanDistanceMeasure.java

ManhalanobisDistanceMeasure.java

其他内容

为了提高运算速度, Mahout中实现了CachingUserSimilarity.java来缓存两User/Item的相似度计算结果。

也可关注我的微博:  weibo.com/dustinsea

或直接访问 semocean.com

关键词推荐系统架构

在百度做关键词推荐系统3年多, 以前更多是从工程, 以及解决用户需求的角度去考虑系统的实现。 大概一年前开始系统地学习业界推荐系统相关的内容并对照自己手头的工作。 当时就画了以下系统结构图, 算是对百度关键词系统(KR: Keyword Recommendation)中主动推荐(主动push结果给客户)的一个总结。
系统逻辑图如下:
当中包含以下几个重要步骤:
  1. 离线的数据挖掘: 根据广告库,客户landingpage内容, 网名检索query等数据,建立关键词之间的关系。 这块能做的工作非常多,包括建立关键词之间的商业价值关系,等同相关性等。很多任务都是offline的, 在hadoop/spark上进行挖掘。
  2. 关键词候选集索引建立:当这些关系建立后,就将这些关系数据建立索引加入线上系统,而且经常会提前做结构化的预处理以提升线上处理效率。
  3. user profile建立:根据用户提词反馈, 包括显式的反馈,包括对关键词的正/负向评估以及隐式反馈(通过KR,或者通过其他途径提交了关键词),以及用户的注册信息,Landingpage等构建用户user profile
  4. 结果触发:当用户访问KR时,首先根据离线挖掘的各种关系数据进行触发, 得到关系数据的大量候选。之后结合user profile进行过滤
  5. ranking: 该处的ranking较为负责, 可以分别对采用率, 的pair的效用,使用模型进行预估, 之后综合加权。 此处的效用, 可以根据具体场景的不同而做定制。
  6. 业务逻辑的ranking(Marketing Rule):相较于上边提到的纯算法策略的ranking,有时也需要根据具体产品的出口, 场景等因素, 使用规则对结果进行reranking, 以满足业务需求(此处未在上图中体现)
当然真实系统并不是上述内容就能说清的, 例如线下数据挖掘,就会用到二步图, 全关系PageRank, 关联规则等多种方式进行挖掘。 触发时也需要考虑各种同意,核心等的变换, ranking时使用机器学习方法结合业务规则综合排序。 更多细节可以参考后续推荐系统相关文章。
更多内容可关注微博:weibo.com
或是直接访问: http://semocean.com