对分析需求的判断校验

[Q]

前番谈了提问和判断，在洞察需求者意图时，可以通过提问的方法引导，但最后要经过自己的判断。

同时也将分析需求中，需要的提问和判断列出。

基本上，需要对分析方向（领域）、群体、指标、现象、方案进行提问和判断。最终，是要得出分析者要做的事情，也就是几条BQ——通过那么多提问和判断，最后才得出3、4条BQ，甚至2、3条，是否值得呢？

当然，这里的提问和判断已经不光是界定出BQ，对后面构建AL也输入了很多信息。然而，即便是界定BQ，对于洞察能力不足的人，问不出问题，捏不准判断，很可能就算是完成那么多提问和判断，仍然是得到错误（不合需求者意图）的判断。于是，在那些提问和判断中，应当有一些校验性的东西，提问和提问之间是有关联的，可以交叉检验，看是否是矛盾的。如果有矛盾之处，可能判断错了。

于是，对每一块所需要的判断，再行梳理，得出如下的表格。

为了看明白这个表格，解释一下，表格有三列，信息点、取值和判断。

信息点也就是在提问要得出的信息；取值，是一般如何表述该信息；而判断是根据这个信息是否有进一步的判断。

在取值方面，有这几种类型：

命名：用一个简短名词称谓对象

描述：自然语言陈述

列举：列举出命名，用逗号分隔

单选项：选择其中一项（用/分隔）

多选项：选择其中多项，（用-分隔）

BQ：BQ的三段陈述（对{分析对象}，当做{分析对象类型：领域/指标/群体/现象/方案}，进行{BQ类型}分析；）

          根据分析对象类型不同，BQ类型不同。

               领域 – {问机}

               指标 – {预期-求解-计量}

               群体 – {分治-描廓-识别}

               现象 – {求因}

               方案 – {估行-评效-选秀}

好，开始吧，首先是分析方向的：

信息点	取值	判断
分析名称	命名	本次分析活动以此为名
发起部门	IT/业务/高层管理	部门不同，可能分析性质不同，决策层级不同。 IT – 多发现，验证 业务 – 多验证，精细 高层管理 – 多解释
触发事件	描述	从事件陈述中，判断分析性质、核心问题和预期目标
分析性质	解释/验证/发现/精细	不同的分析性质，可能判断出不同BQ类型 解释 – 问机，分治，描廓，求因 验证 – 描廓，求因，估行，评效，识别 发现 – 分治、描廓、求因、问机 精细 – 预期、求解、识别、选秀
核心问题	描述	根据描述的清晰程度，可以判断处于什么分析阶段。越模糊，越处于初级阶段，越具体，越后期； 同时越具体，越可以判断出决策领域或分析领域
分析阶段	模糊混沌/已有初步分析，深入/已有成熟分析，改善	分析阶段不同，判断所需分析类型不同： 混沌-多问机、分治、选秀 初步-多描廓、分治、求因、估行、 成熟-多预期、求解、识别、评效
困难点	描述	从困难点判断重点要做的分析，比如特征描述不够清晰，那么本次分析可能一个重点就是“描廓”分析
决策部门	IT/业务/高层管理	根据部门判断是否有明确的行动计划，如不清晰，分析多半停留在混沌阶段
决策行动	描述	根据描述的具体程度，判断是否有明确的行动计划
决策层级	战略/战术/操作	判断“决策行动”的层级，应当跟决策部门相匹配。不同层级的决策，所需分析类型不同，所以可以跟“分析性质”互相检验。
决策领域	命名	界定出的分析对象名称。如果决策部门、行动、层级明确而具体，那么此处应当命名一个决策领域。比如“终端营销”。
预期目标	命名	预期改善的方面
预期目标水平	描述	改善达到的水平，跟“预期目标”一起，可以当做是分析的最终目标
分析领域	命名	如果指定了要从哪方面入手分析，对这方面进行命名定义
分析领域明确性	明确/模糊	明确，也就是需求明确指出要从这方面入手分析。在存在决策领域的情况下，以决策领域优先，分析领域应当作为参考。
期望结论	列举	期望从该分析领域得出什么样的结论，按条描述。根据结论的期望形式，可以为判断做什么类型的分析提供参考
期望行动	列举	期望用结论产生的行动，应当与“决策行动”的属于统一类型，与“决策层级”相符
交付形式	报告-系统-名单	最终结论交付形式，与“决策层级”，“决策部门”相互校验
时间紧急度	紧急/宽松	决定分析的深度，以及是否划分阶段。 如紧急，避免划分阶段。
是否分阶段	要求/不要求	需求方是否明确要求划分阶段
阶段划分	列举	划分成几个阶段，可以根据阶段分配对BQ的定义（本次分析只需要定义第一阶段的）
关注指标	列举	提及的指标，将带入指标定义中，根据需要展开
重点指标	列举	明确提出要分析的指标，需要展开定义
关注群体	列举	提及的群体，将带入群体定义中，根据需要展开
重点群体	列举	明确提出要分析的群体，需要展开定义
关注现象	列举	提及的现象，将带入现象定义中，根据需要展开
重点现象	列举	明确提出要分析的现象，需要展开定义
关注方案	列举	提及的方案，将带入方案定义中，根据需要展开
重点方案	列举	明确提出要分析的方案，需要展开定义
是否明确方向	有/没有	如果需求方明确提出要分析什么，直接在此指定
+已明确BQ	BQ	当存在明确方向时，直接定义（可定义多个），但同时也可以多了解一些其他关于决策领域、分析领域的事情，以帮助需求方判断是否该BQ能实际解决问题
问机决策领域	需要/不需要	根据前面的信息，综合判断。 如果上面提出了决策领域，应该对决策领域进行问机
问机分析领域	需要/不需要	如果没有提到决策领域，应当对分析领域进行问机。 所以，通常情况下，两者必选其一。（除非需求方要求很具体，而且分析阶段已经到成熟阶段）

待续..

[darcy007007]

要过年了，借群内人气发个招聘.

天猫-个性化推荐团队求贤

数据挖掘工程师（推荐算法方向）3人

职位层级：p5-p6

岗位职责

1、根据不同应用场景和业务目标，设计、开发天猫个性化推荐算法；

2、分析用户特征，制定算法优化方案，并改进推荐算法。

岗位要求

1、二年以上推荐相关项目关工作经验；

2、精通机器学习算法及其原理，算法特点有深刻理解，能快速制定算法实现方案；

3、熟悉Oracle、Mysql等常用数据库，精通SQL；熟练使用挖掘工具。有算法开发经验；

4、具有优秀的逻辑分析能力、沟通能力；优秀的分析问题和解决问题的能力；

6、有java或C++开发经验。

符合下面条件的人将优先考虑：

1、有mahout开发经验；

2、有搜索引擎开发经验。

数据挖掘专家（算法研发方向）2人

职位层级：p7-p8

岗位职责

1、基于业务特征，抽象算法模块；

2、规划、梳理个性化推荐基础算法体系，构建个性化推荐基础算法库；

4、设计统一的算法实施架构，方便进行算法的统一的开发、测试、部署、评估；

岗位要求

1、三年以上互联网行业的算法架构工作经验；

2、精通机器学习算法及其原理，有推荐算法深度优化经验；

3、对个性化推荐架构有深入研究，对算法框架有深度思考，有完整个性化推荐项目架构、实施经验；

4、熟悉常用存储结构，对计算复杂度敏感，有算法开发和性能调优经验；

5、具备战略性和前瞻性思维能力，规划能力强、执行力好，有责任感；

符合下面条件的人将优先考虑：

1、对算法研发痴迷；

数据挖掘专家（算法应用方向）2人

职位层级：p7-p8

岗位职责

1、对天猫用户数据进行挖掘分析，挖掘用户行为特征；

2、深入研究某一方面用户行为特征，支持业务部门的数据化运营；

3、深入研究业务问题，输出基于挖掘技术解决方案。

岗位要求

1、五年以上互联网、电信、金融等行业的数据分析/挖掘相关工作经验；

2、精通数据挖掘算法及其原理；

3、挖掘工具熟练，熟悉Oracle、Mysql等数据库，精通SQL；

4、数据掘项目经验丰富，在挖掘模型应用上有成功案例；

5、对数据挖掘方法论有深刻理解，能深入分析、定位业务问题，利用挖掘模型解决；

6、具有良好的逻辑分析能力、沟通能力和文字表达能力；

数据挖掘专家（数据分析方向）2人

职位层级：p7-p8

岗位职责

1、对天猫用户行为进行专题分析，撰写分析报告；

2、围绕个性化推荐算法优化进行深度分析，提出算法优化建议；

岗位要求

1、五年以上互联网、电信、金融等行业的数据分析/挖掘相关工作经验；

2、对数据分析方法论有深刻理解，有系统性的分析思路，对业务发展趋势有敏锐的洞察力和创新意识；

3、熟练使用各种统计分析软件，熟悉Oracle、Mysql等数据库，精通SQL；熟悉常用数据挖掘算法及其原理；

4、对数字敏感，有良好的执行力和耐心；

5、具有良好的团队协同能力和报告撰写能力；

符合下面条件的人将优先考虑：

1、有咨询顾问工作经历优先；

有兴趣加我QQ7891455，或者简历发我邮件darcy...@163.com

[Kaymo Yang]

2013/1/24 darcy007007 <darcy...@163.com>

--
您收到此邮件是因为您订阅了 Google 网上论坛的“ttnn BI 观点”论坛。
要向此网上论坛发帖，请发送电子邮件至 tt...@googlegroups.com。
要取消订阅此网上论坛，请发送电子邮件至 ttnn+uns...@googlegroups.com。
通过以下网址访问此论坛：http://groups.google.com/group/ttnn?hl=zh-CN。
 
 

--
杨凯木

[Kaymo Yang]

哟～推荐火了！工厂，猫猫都在挖人呀。

2013/1/24 Kaymo Yang <kaymo...@gmail.com>

--
杨凯木

[darcy007007]

是啊，业务起来了，现在网站都是要千人千面才行，需要各界精英。基本上产品、分析、算法、模型都需要。属于内部推荐招聘，比猎头靠谱

有兴趣就联系我吧

要取消订阅此网上论坛，请发送电子邮件至 ttnn+unsub...@googlegroups.com。
通过以下网址访问此论坛：http://groups.google.com/group/ttnn?hl=zh-CN。
 
 

[Q]

给出指标和群体的信息判断校验。

**指标

信息点	取值	判断
指标名称	命名	在分析方向，或群体、或现象中曾提及的指标名称
业务含义	描述	指标必定是衡量某个业务领域的
指标性质	KPI/业务指标/新概念	KPI，明文规定的 业务指标，业务约定的 新概念，本次分析新提出的，业务上尚未形成固定说法的
关注部门	描述	如果是高层部门，约有预期和求解的需求，越底层，跟关注指标背后的群体、现象
指标形式	过程/结果	过程指标，多为时期数，可实时监控，有预期和求解需求 结果指标，多为时点数，观察周期长，一般无预期和求解需求，有计量需求（如对满意度形成一个综合指标）
计算类型	计数/汇总/比率/综合	计数、汇总，多预测，求解 比率、综合，不可预测，求解，偏向计量
量化状态	定性/定量	目前指标的状态，定性指标不可预测、求解，多计量 跟指标形式相互校验。一般过程指标应当是定量的，而结果指标可以是定性的
严谨程度	严格定义/不太严格/模糊	与“计算类型”和“量化状态”相互校验，
是否需量化	需要/不需要	当“严谨程度”非严格定义时，需要判断是否需量化定义，以此判断是否进行“计量”分析
口径定义	描述	当存在较“严谨程度”时，指明计算方法、条件； 此处计算方法应当和计算类型相校验
分解指标	列举	该指标从业务上约定分解成哪几项指标，即指标=sum（分指标），如无约定，不必填写，至“相关指标”
相关指标	列举	通常与该指标一同提及的兄弟指标，或关键分指标
是否有异常	发生/没发生	如发生，可能需要对现象进行定义
指标现象	列举	指标的异常变化，进入现象定义
是否需预测	需要/不需要	需求方是否提出要对指标进行预测，判断需要进行“预期”分析
预测支持行动	描述	预测的结果用来做什么业务行动，根据描述的具体程度，判断“预期“分析的必要性
是否需分解	需要/不需要	需求方是否提出要对指标进行分解，判断需要机型“分解“分析
分解支持行动	描述	分解的结果会用来做什么业务行动，根据描述具体程度，判断“分解“分析的必要性
指标分析判断	预期-求解-计量	从前面的信息点，勾选是否需要对该指标进行这三种分析的其中某几个

 

**群体

信息点	取值	判断
群体名称	命名	在分析方向，或指标、或现象中曾提及的群体名称
严谨程度	严格/不太严格/概念性	不同严谨程度的群体需要的分析不同 严格 – 可以直接提数，是比较成熟的，求分治可能性较大 不太严格 – 数据口径不成熟，求描廓可能性大 概念性 – 求分治可能性不大，多描廓和识别
提取口径	描述	如较严谨定义，描述如何提取数据的
群体规模	绝大多数/一大半/一小半/极少数	规模越大，越需要“分治“。越具体，越需要”描廓“。少数，极少数，可能关注潜在，需要“识别“
潜在群体关注度	关注/不关注	是否明确提出关注潜在群体。跟群体规模相校验。 一般小规模群体关注潜在。
是否有样本	有/没有	如关注潜在，是否有明确的样本群体。如无，“识别”存在风险。
样本口径	描述	根据口径描述的具体程度，判断是否足以进行“识别“分析 。
子群体	列举	列举出业务上约定束成的完全分解的子群体，如具体，“分治“的可能性不大，更可能“描廓”。
关键子群体	列举	如不能列举完全分解子群体，在此处列举提出的关键子群体。如有必要，对该子群体进行深度定义。 如指定该信息，更可能是进行“描廓”和“识别”分析
相关群体	列举	通常跟该群体同时提及的其他群体，根据需要进一步展开。 如指定，可能需要“描廓”分析，并以此作为对比群体。
相关指标	列举	在该群体上计算的定量业务指标，根据需要进一步展开
相关现象	列举	该群体表现出来的某种特有现象，根据需要进一步展开
是否需细分	需要/不需要	是否明确提出细分、分群、分类等字眼
细分支持行动	描述	如该群体分成若干群体，会展开什么行动或决策。根据描述具体程度，判断“分治”分析的必要性。
是否需特征	需要/不需要	是否明确提出特征、标签、对比等字眼
特征支持行动	描述	如得出该群体的特征，会展开什么行动或决策。根据描述具体程度，判断“描廓”分析的必要性
是否需个体列表	需要/不需要	是否明确提出需要提取名单进行一对一行动
列表支持行动	描述	如得出群体列表，展开的行动是什么。根据描述具体程度，判断“识别”分析的必要性。
群体分析判断	分治-描廓-识别	依据以上信息，最终判断对该群体进行的几项分析

 待续...

[Jerry Wu]

借这个地盘打个广告，长三角的就不说了，去天猫方便，如果在北京的话，欢迎来去哪儿，如果狂热追求业务效果的挖掘狂人，更欢迎来这边，每个人负责1、2个业务项目都没问题，都是马上快速迭代见业务效果的数据挖掘哦，哈哈  

2013/1/25 darcy007007 <darcy...@163.com>

要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 ttnn+uns...@googlegroups.com。
要向此网上论坛发帖，请发送电子邮件至 tt...@googlegroups.com。
通过以下网址访问此论坛：http://groups.google.com/group/ttnn?hl=zh-CN。
 
 

[suwenkui]

呵呵，这个比较有煽动性，见效快就数据挖掘的精髓啊。

其实算法都是试出来的，不是推出来的。

 

---

suwenkui

 

发件人： Jerry Wu

发送时间： 2013-01-28 00:51

收件人： ttnn

主题： Re: Re: 要过年了，借群内人气发个天猫的招人贴

[Q]

接着，是对现象和方案的判断。通过这些判断，将得出需求者的BQ，对什么做什么分析。

有时候我怀疑他的意义，折腾这么长时间，才得出三条BQ？仅此而已？后来我想，很多时候，我们其实在做不必要的事情，而借助这个判断的步骤，可以让我们确定做什么，更关键的是，不做什么。

**现象

信息点	取值	判断
现象名称	命名	在分析方向，或指标、或群体中曾提及的现象名称
发生群体	命名	如指定，表示现象发生在群体上的，指定群体名称。如有需要，进一步展开对该群体的定义。
体现指标	命名	如指定，表示现象体现在业务指标变化上的，指定业务指标的名称。如有需要进一步展开对该指标的定义。
现象历史	历来就有/最近发现	如历来就有，“求因”的急迫性不强，因为大家多少知道原因。除非需求方明确提出需要分析原因。而最近发现，更有必要做一个“求因”分析
现象重复	重复出现/偶尔出现	重复出现的现象更可能“求因”，偶尔出现的，建议继续观察，或对该现象依附的群体和指标进行分析
发生频率	随时/短期/中期/长期	随时
现象主体	命名	指该现象依附的群体属性或指标
前观察窗口	一周/一个月/三个月/以上	发生前观察时间，窗口越长，表明现象越稳定，越可以做“求因”分析
前状态	描述	主体在现象发生前的状态，如描述模糊，需要进一步定义现象，做“问机”分析
后观察窗口	立即/一周/一个月	发生后观察时间，窗口越短，越关注原因，越长，越关注改变。 与现象关注点相互校验。
后状态	描述	主体在现象发生后的状态，如描述模糊，需要进一步定义现象。
现象关注点	解释-改变	需求方明确表明的关注点，是需要一个解释？还是改变这种现象。 如不关注解释，那么，可以不必进行“求因”分析，或简化“求因”分析。
解释支持行动	描述	得出原因，将如何行动？根据描述判断是否有充分的求因必要
现象改变行动	描述	如何对现象进行改变？是否具备充分的行动条件。根据描述判断是否只能停留在求因层面。
需要求因现象	需要/不需要	根据以上信息，判断是否需要对该现象进行求因分析

 

**方案

信息点	取值	判断
方案名称	命名	在分析方向，提及的方案名称
方案阶段	筹划/设计中/设计完毕/执行中/执行完毕	方案阶段不同，需要的方案分析自然不同。 筹划 – 不需要对方案本身分析，可以转移到指标分析上去，量化预期目标 设计中 – 不需要对方案本身分析，转移到指标、群体、现象分析，寻求方案策略 设计完毕 – 论证方案可行性，可进行“估行“分析 执行中，执行完毕 – 监控评估方案效果，可进行“评效“分析
方案类型	策划案/候选项	方案是解决目标领域问题的任何计划、手段或具体对象。 策划案 – 根据阶段不同，多进行估行和评效 候选项 – 已经算是设计完毕，如存在多个方案，多进行选秀
方案内容	描述	如方案进行已经到设计完毕阶段之后，陈述方案内容
发起部门	命名	给出发起部门的陈述，如筹划阶段，该信息应当具备。
设计部门	命名	给出设计部门的陈述，如设计阶段，该信息应当具备。
执行部门	命名	给出执行部门的陈述，如执行中，该信息应当具备。
评估部门	命名	给出评估部门的陈述，需要注意当发起、设计、执行部门不同时，“评效”分析的必要性。
预期目标	命名	方案将在哪个方面带来变化，应当跟分析方向里的预期目标一致，或存在明显的关联
预期目标值	描述	方案方面带来变化，应当跟分析方向里的预期目标一致，或存在明显的关联
关键环节	列举	列举方案重点解决的业务难点，应当与“预期目标”有明显的关联。将作为评价方案的关键考虑因素。
优点	列举	列觉方案的优点方面，将作为评价方案的考虑因素。
缺点	列举	列举方案的缺点方面，将作为评价方案的考虑因素。
评估方面	列举	列举从哪些方面来全面评估方案，将作为评价方案的主方面，应当完全覆盖所有可能的方面。
是否多个方案	有/没有	以此判断是否进行“选秀”分析
候选方案	列举	作为选秀的候选项
方案分析类型	估行-评效-选秀	根据以上信息，主要是方案阶段和方案类型，判断需要做什么分析。此处判断比较直接。