超的学习分享

关于非功能性需求变更

Wed, 06 Apr 2016 14:28:03 +0800

令人烦恼的非功能性需求变更
在软件开发中，大家都会遇到过这样的问题：客户的一个新想法，就推翻了之前与客户经过再三讨论而确认定下来的需求。如果是功能性需求变更还会让人容易接受一些，毕竟功能性需求不实现的话，是会大大影响到软件产品的质量。但现在我所负责的这个开发项目中遇到的都是一些非功能性的变更,而且许多是看起来无关痛痒的、鸡毛蒜皮的变更。
（1）什么是非功能性需求？
在IEEE中，软件需求的定义是：用户解决问题或达到目标所需的条件或功能。一般包含业务需求、用户需求、功能需求、行业隐含需求和一些非功能性需求。业务需求反映了客户对系统、产品高层次的目标要求；功能需求定义了开发人员必须实现的软件功能。所谓非功能性需求，是指为满足用户业务需求而必须具有除功能需求以外的特性。包括系统性能、可靠性、可维护性、易用性和对技术和对业务适应性等。其中最常见的是软件界面、操作方便等一系列要求。
（2）非功能性需求变更的特点
让我们从客户角度和开发人员角度去看看非功能性需求的特点。首先，有些非功能性小需求从客户角度看起来工作量不大，但是实际上开发人员要耗费比较长的时间去完成这些小功能。其次，许多非功能性需求，如界面美观、操作方便等都是客户头脑一热、或领导一拍脑袋就部署下去的需求，往往是原来在需求分析阶段所没有注意的内容。
其实，非功能性需求是常常被轻视，甚至被忽视的。原因是非功能性需求描述很困难，它很难像功能性需求那样，可以通过结构化和量化的词语来描述清楚。在描述这类需求时候，我们经常采用软件性能要好、操作要方便、软件界面要美观大方等较模糊的描述词语。例如，易用性就同时涉及到美工和UI界面、人机工程、交互式设计、心理学、用户行为模式等内容。这类描述词语都是脱离了软件的执行环境，是对人和相关的场景的描述，因此很难体现到软件架构设计和具体的实现中。
为什么非功能性需求变更会频繁发生？
为什么非功能性需求不能固定下来呢？或定下来后就不许变了呢？通常有许多人会问这样的问题。实际上，当他变成了客户时，他可能就不会问这个问题了。
（1）非功能性需求容易产生理解分歧
在软件需求分析阶段，客户和开发人员对非功能性需求的理解呈现"大体上共识多，细节上差异多"的特点。一般跟分析员的知识、背景，还有客户表述的标准程度、双方的交流情况有关。即使通过反复沟通，但是以实践经验来看非功能性需求的描述还是永远不够清晰、不够明确的，主要是因为在这个阶段所谓的产品还只存在于大家的大脑构思中。
作为一个客户，大多数情况下是不懂技术的，但他所需要的软件在他的心里还是有一个印象的。他会想象出软件的样子和功能，然后通过口头或者笔头的方式告诉需求分析人员。简单的说，就是在这个阶段用户往往不能确切地定义自己需要什么。用户常常以为自己清楚，但实际上他们提出的需求只是依据当前的工作所需，或者是他们想象出来的东西。结果是当客户向需求分析人员提出需求的时候，往往是通过自己的想法用自然语言来表达的，这样的表达结果对于真实的需求来说只是一种描述，甚至只是某个角度的描述，但远远不能保证这样的描述可以得到百分之百的正确理解。
当客户提出要求之后，在双方认为理解大概没有分歧的时候，开发人员就开始工作了。但随着开发工作的不断进展，系统开始展现雏形，客户对系统的了解也逐步深入。这个时候，客户就会对系统的界面、操作、功能、性能等有一些了解，就有可能提出需求变更要求，而且这些要求很多是基于主观的、人为的因素。总之，他们了解得越多，新的要求也就会越多。
（2）没有明确的需求变更管理流程
在软件开发中的常识是，一旦发生需求变更不要一味的抱怨，也不要一味地去迎合客户的新需求，而是要管理和控制需求变更。但令人不解的是我们常常看到变更的提出、讨论和执行常常只停留在口头上。这样做有两个弊端：首先是时间一长，无论是当事人还是开发团队都说不清楚变更是因何发生以及结果怎么样了。显然，这对于提高项目质量、改进开发过程是很不利的。其次是由于缺乏形式上的约束和对变更代价的定量分析，变更会被非常随意地提出、或被草率地执行，也会大大影响项目的进展和开发质量。
因此，没有明确的需求变更管理流程，就会使需求变更变得泛滥。因为并不是所有的变更都要修改，也不是所有变更都要立刻修改，需求变更管理的目的是为了决定什么类型的变更需要修改和什么时候修改。比如界面风格问题，就可以先不修改，或者规划一下修改的时间待到以后进行优化。
（3）没有让客户知道需求变更的代价
对变更的影响没有评估是需求变更泛滥的根本原因。变更都是有代价的，应该要评估变更的代价和要让客户了解需求变更的后果。如果客户不知道需求变更付出的代价，对开发人员的辛苦就会难以体会。
相比于需求开发人员而言，客户可能对需求变更认识不足，认为他们出钱，软件开发团队就要为它服务。因此，客户对需求变更往往会肆无忌弹，将需求变更视为儿戏，随个人喜好随意变更需求。所以，在和客户接触时应该挑明态度，特别是要让他们清楚需求随意变更所带来的代价和风险。如果客户认为代价太大，那么开发人员就没有必要及时修改，按原来的进度走，但仍要记录变更，待下一版本在修改。
如何有效控制非功能性需求的变更?
做任何变更之前，我们都要考虑后果。由于非功能性需求变更在开发中所处的重要地位，一旦需求发生变化，影响面是很广的。因此，有效控制非功能性需求频繁变更是一件不容小视的事情。
（1）建立明确的非功能性需求基线
对于软件开发来说，变更无可避免，也无从逃避，只能积极应对。因此，在开发过程中，建立明确的非功能性需求基线是一件重要的事情。如果非功能性需求没做好，基线范围就含糊不清，就容易被客户抓住空子，往往要付出许多无谓的变更。如果非功能性需求基线做得好，文档清晰且又有客户签字，那么后期客户提出的非功能性需求变更就会大大减少。因此，在建立需求基线的时候千万不能手软，这并非要刻意针对客户，而是不能让客户养成经常变更的习惯，否则后患无穷。
（2）建立需求变更管理流程
需求变更对软件开发成败有重要影响，既不能一概拒绝客户的变更要求，也不能一味地迁就客户，所以必须要做好需求变更的控制。有句通俗的话说得非常好：需求变更管理的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。需求变更管理流程包括变更申请环节、审批人员、审批事项、审批流程等。
目的有两个：一是将客户下达变更的流程尽可能地规范化，减少张嘴就来的非必要、非紧急、非合理、非高层领导意图的无效变更。二是留下书面依据，为今后可能的成本核算准备好变更账。因此，凡未履行审批程序的变更，一律是无效变更不予受理。在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。但正是由于这种观念才会使到需求变更逐渐变为不可控，最终导致项目的失败。
（3）确认客户是否接受变更的代价
需求变更作为一个计划外的风险对项目肯定存在冲击，只是大小的差别。而且客户的需求是永远不会满足的，可能一天一个样,为了达到控制频繁的需求变更。需要将变更后产生的成本进行评估与量化，形成分析报告提交双方领导。否则，一味的妥协只会让项目进一步恶化。因此，要让客户认识到变更都是有代价的，不要让客户养成随意变更的毛病。一般来说，如果客户认为该非功能性变更是必须的，而不是其上级领导拍脑袋提出的就会接受这些代价。通过与客户的沟通和协商，开发团队即使没有回报也不会招致客户的埋怨。
（4）加强合同约束力
虽然软件开发合同很难在签订之初就能够精确定义每项需求，单靠合同是帮不上忙的，但也不能忽视合同的约束力。因为有时销售人员为使客户能够快速的签订合同，往往草率决定和片面同意客户提出的需求。当客户提出新的需求时，销售人员往往一看"应该"只是一个小小的修改，没有太大的影响，可能会直接答应能变更。所以，在与客户签订开发合同时，可以增加一些相关条款，如限定客户提出需求变更的时间，规定何种情况的变更可以接受、拒绝接受或部分接受，还可以规定发生需求变更时必须执行变更控制流程等。
（5）加强感情沟通，注意沟通技巧
大多时候单靠合同的约束力是解决不了纷争的。客户着急了就是一句潜台词：做不做，不想做就滚蛋，想做的公司多着呢。例如，有时明明是不合理的要求，可是客户也会狡辩凭什么不给他们做，这可是合同范围内的工作。所以，单看合同是没用的。
那可怎么办呢？通常的做法是通过感情联络，争取客户的同情。我们常常对客户说的一句老生常谈的话，就是提需求也要讲究合情合理，这句话在变更管理中有着独特的意义。用我们的行话说是：做好需求变更管理控制只是做好了一半的工作，还有一半的工作就是去讲道理，去用心、用感情劝客户回头。
月有阴晴圆缺，潮涨潮落。变化并不一定总是给我们带来麻烦，有时也会带来惊喜。在软件开发中，对待客户提出的非功能性需求变更，我们需要用平常心去看待，不是一味拒绝，也不要一味答应。

业务需求访谈中需要注意的重要法则

Wed, 06 Apr 2016 00:14:09 +0800

毫无疑问, 任何企业信息化项目启动的源头来自于系统业务需求调研，业务需求调研在软件工程价值链中处于首当其冲的位置,做好业务需求调研对于项目成败的重要性是不言而喻的。而如何做好业务需求调研却又不是件容易的事，因为它既是门科学更是门艺术，更需要长期的经验积累。业务需求调研的方法多样，通常包括复查原有的表格和描述、主持与用户的业务访谈、原型建立、分发收集调查表、研究供应商的解决方案等方法。

而其中的业务需求访谈是一门被证明形之有效的技术和方法，然而怎样做好它，对有效的获得和分析业务需求均起着至关重要的作用。我们应当像重视软件开发过程那样关注管理业务访谈的过程和法则,做到“访谈前有准备,访谈时有效果,访谈后有总结”。如此一来,我们的需求访谈工作才能进入良性循环,我们的软件开发才能有保障。

正如人类发展历史蕴含着隐含的潜规则，业务需求访谈亦有其内在的法则所在，本文旨在挖掘这些规则以期同仁在业务需求访谈工作中有所参照和收获。

1、业务需求访谈前要从内容和目标上做好精心准备。
我们知道系统需求是新系统必须完成的功能和局限性。系统需求肯定不是生来就有的，也不是天生就存在需求分析员的脑海中，那么业务需要又在哪里呢？它存在于业务人员的脑海里,它存在与企业实践运作体系中。或者说它们并不一定存在，需求分析员的职责就在于通过包括业务需求访谈在内的各种方法使系统需求得以显示它清晰的本来面目。业务需求访谈本质上是一种知识迁移过程,通过业务需求访谈需求分析员最终完成了从业务到需求的迁移。
既然业务需求访谈有如此的特点，就注定了我们必须对其有所准备。一般而言,我们应对访谈的目标和内容有专门策划,做到有备而来。
现在让我们举例说明应该如何做才能算是做好了“准备” ,假设王五是某家贸易公司的新任需求分析员,它的工作职责是对公司已有的订单管理系统进行改进,为此他将对公司的业务部门做一场业务访谈。
首先,我们应该确定访谈的对象。通过企业的组织结构图,我们得知业务部门通常有三种角色,即业务主管、业务、助理。那么王五应该选择谁做第一次访谈的对象呢?我们有必要对每种角色作一番深入地认识, 我们会发现所谓主管，即总是对全盘业务相当熟悉的人,他负责协调部门全局；而业务是部门的主要业务执行人；助理则是管理系统的直接操作者。联想到本次访谈的使命是搞清业务部门的整体性流程,我们会很自然地选择主管作为本次访谈的对象。
接着,我们要确定访谈时间。主管一般都是比较忙的,他不会时时都在等你。因此,王五提前预约他,电话和登门拜访都是很好的办法。等他应约之后,协商一个确定的时间，再进入深层次的访谈也显得合情合理。
现在,我们只剩下一个访谈的内容需要准备了。我们可以拟定一些具体问题，这些问题越具体越好。最好打印出一份清单,这样访问过程可以按部就班地进行。当然,也学会有人认为不就是一场会谈嘛,何必搞得像晚会节目单一样? 但我们认为这实际上很有必要。“凡事预则立”,这是先贤站在哲学的高度对我们的启示。
王五访谈的具体问题由于篇幅所限就不在此一一列明,可以在相关资料上找到很好的答案。

2、选择访谈对象须由线及点，由点入线。
这是个选择访谈对象的问题，一般而言有两种方法。第一,选择工作角色，比如业务员、销售助理。第二,从业务主线入手，召集这条线上的角色。很显然，前一种方法容易实施，但容易陷入见点不见主线的陷阱。也就是说这个角色的主要工作职责是服务于哪条业务主线，你必须心知肚明。否则，访谈活动就变成了摸着石头过河了。一个成功的业务访谈者是访谈游戏的规则制定者，他必须知道他的对象链并心中有数。这样做访谈才不会跑题，才不会犯方向性错误。
我们仍然以上面的王五为例, 假设他也已完成了第一次对业务主管的访谈工作,下面他该如何把访谈进行到底呢?
按照点线原则,我们可以安排他对相关业务员和业务助理做访谈,由于这几个人的工作有相关联系性,我们可以采用应用联席会议的方式做为业务访谈的一种有效补充。事实上, 业务访谈和其他需求调研的方法是互相补充的关系。
另一方面,我们也可以根据业务部门的运作过程，对这条业务主线上的每个角色进行逐以地访谈。比如,王五所在的贸易的订单业务主线一般流程为：接订单->订单下达->采购->入库->收款。那么，他应该做出相应的访谈路线图。这样,他才能在一段时期内有效地把访谈工作进行到底。

3、访谈过程中坚持以我为主, 善于引导访谈对象。
访谈过程中我们要保持理性，自始至终以我为主,牢牢掌握访谈的主动权。因为只有访谈者掌握了访谈的方向和内容, 访谈的质量才有保证,效果才能预期。
优秀的需求分析员应该是有理性的人, 我们不能因为被访谈对象的情绪便打乱了我们本来已拟就的访谈计划。我们有必要树立目标法则,因之没必要特别在乎被访谈对象的一些抵触情绪。比如，王五和一个业务助理在谈话过程中，当他得知王五的系统计划很可能损害到他的潜在利益,他会变得情绪化, 会找些借口, 比如说他的薪水太低,因而不愿意配合。如果你也遇到类似情形,此时的你一定要冷静、理性地分析问题的症结所在 ,适当地引导被访对象，以使访谈工作继续进行下去。
另外,访谈对象总是有一些“防御”访谈者的手段，比如，被访谈对象对你的提问经常以“这是某某习惯”作答，那么你必须意识到这不是真实的答案，并且可以当面指出，让他逐步把对问题的回答引入到你在自己预设的轨道中——也惟有这样谈下去才能谈得更深入。一个好的分析访谈人员能够从表面挖掘出背后的真实商业规则，并且有这种发现需求真相的耐心和韧性,同时他必须很有主见,能够引导对方,达到既定的访谈目标。

4、访谈过程中要善于寻求异常和错误情况。
千万不要认为被访谈对象的话总是对的，他经常会说“应该”或者“可能”是这样的答案,但就是不说出当前的真实情况,。因而很多时候你需要求异思维去面对你的访谈对象，因为只有这样你才能挖掘到更多的业务细节。多问问“如果条件没有达到，你会怎么办?”,”如果不是这样你会怎么处理?”，而要少说"是"。
我们可以认为业务访谈是否有效的标志，在于能否更深入地探讨业务需求问题,。而能否进入访谈状态,需求分析员的性格很重要。需求分析员必须是那种有主见而不是那种唯唯诺诺的人,如果用户说什么你都只会说“是”,则意味着访谈应该提前结束——此乃业务访谈之大忌也。
正确的态度应该是客观理性的态度,不管用户说什么,你首先要分析,然后置疑,从而引导用户说出他们真正的需求所在。其实也需要耐心,我们觉得可以向优秀的新闻采访记者学习提问技巧, 他山之石可以攻玉。总之，优秀的需求分析员善于说不，只会说是的需求分析员永远得不到真正的需求。

5、业务需求访谈要搞清“4W1H”。
业务需求访谈要搞清”4W1H”。
有人说新闻就是4W1H, 业务需求也有同样的特点。需求分析员要清楚地掌握某个需求,应该能够清楚该业务的4W和1H ,4W是“What、Who、When、Why”,1H是“How”。
What：业务内容是什么。
Who：业务过程会有哪些相关者。
When：业务过程什么时候发生,周期有多长。
Why：为什么会出现这样的问题。
How：为完成业务目标所采用的方法。

6、业务需求访谈要深入调查细节。
现代系统分析员重要责任是调查系统需求细节，而细节不会凭空出现的，而是深入跟踪、深入访谈调研的结果。不但要“知道是这样”，还要知道“为什么是这样”，也要知道“如果不这样那会是怎样”。
做需求下结论前要事先调查和掌握好所有正反两个方向的商业细节，如此以来需求分析结论和解决方案才有现实可行性。这里有一个很好的实例，一般而言，物料编码都是系统自动提供规则实现的，而某贸易公司的订单系统偏偏不提供系统自编码。面对此问题，我们必须搞清两个问题：其一是该企业的编码规则，其二是该企业的编码规则牵涉到的前置条件和后置条件。知其然也知其所以然，是需求分析员的主要课题。经过多方调查发现，该企业编码规则中有两位是客户的版本更改数，而这在系统中是无法提供出来的，因而物料自动编码就失去了实现的土壤。所以说仅仅满足于看到了业务现象是远远不够的,我们更要搞清楚现象背后的原因,我们还要有能力能够提供诸多方案以解释和改造目前的现状。
层层发问法也是深入调查而经常采用到的方法。
比如,最近收到的客户退货比以往多,因为生产质量不好；为什么生产质量不好,因为采购质量不如以；为什么采购质量下降,因为采购员的采购件单价低了；为什么价格低了,因为采购员的绩效考核现在以采购成本为重要指标。经过层层发问终于发现原来症结在采购的以采购成本为绩效考核是存在问题的。

7、学会提问的技巧，先以对方的角度想想问题的答案。
你提问的问题最好比较具体，可回答性强。不要一下问得太大，搞得谁都不好回答。也不要满口的专业术语，很多访谈者喜欢说些专业术语，搞得双方无法充分沟通。我们提倡多说双方都便于理解的话，并且以对方的理解角度去问问题。比如你是想知道商业过程和操作是什么，你就可以提问"你主要干什么？"或者问"你的主要工作职责有哪些?"、"你的主要日常工作有哪些?"。你想知道商业过程应该怎样完成，你不妨问道"你如何完成它？需要那些步骤？"而如果你想知道需求什么样的信息，你就问道"你要使用怎么样的表单或报告？"。

8、时刻要记得的四个字"胆大心细"
“胆大”是指你在访谈过程中不要顾虑太多，应该放开心态，最大化的放大访谈效果。
“心细”是指你在访谈过程中观察到的访谈对象的业务操作动作细节，以仔细分辨、总结、归纳背景原因所在。同时，心细带来观察能力的提升，而观察能力之于现代需求分析犹如二郎神的第三只眼，总能让你发现意外的需求访谈方向，发现不曾有人提及的需求。

9、做业务访谈实录有利于提高访谈能力。
一旦本次访谈结束，有必要回去做一番总结，不仅要总结出提炼的需求结论，更重要的是要回忆还原出整个访谈过程，以便事后仔细研摩得失，这对提高业务访谈的能力是大有俾益的。这个过程相当于围棋中的复盘，优秀的棋手对复盘过程也是一丝不苟，好的需求分析员亦然。
业务访谈是一件如此有个性的事情，正如记者各有各的风格但规则是暗合的，以上是本人在业务访谈过程中总结出来的业务“规则”，现抛砖引玉，以飨同仁。

数据分析工作常见的七种错误及规避技巧

Sun, 13 Mar 2016 20:57:59 +0800

商业领域的数据科学家和侦探类似:去探索未知的事物。不过,当他们在这个旅程中冒险的时候，他们很容易落入陷阱。所以要明白,这些错误是如何造成的,以及如何避免。

“错误是发现的入口。”——James Joyce (著名的爱尔兰小说家)。

这在大多数情况下是正确的,但是对于数据科学家而言,犯错误能够帮助他们发现新的数据发展趋势和找到数据的更多模式。说到这儿,有一点很重要:要明白数据科学家有一个非常边缘的错误。数据科学家是经过大量考察后才被录用的，录用成本很高。组织是不能承受和忽视数据科学家不好的数据实践和重复错误的成本的。数据科学的错误和不好的数据实践会浪费数据科学家的职业生涯。数据科学家追踪所有实验数据是至关重要的,从错误中吸取教训,避免在未来数据科学项目中犯错。

福尔摩斯有一句名言是如何定义侦探的,而数据科学家在商业中的角色就类似侦探。

“我是福尔摩斯，我的工作就是发现别人不知道的。”

企业要想保持竞争力,它必须比大数据分析做的更多。不去评估他们手中的数据质量，他们想要的结果,他们预计从这种数据分析中获得多少利润，这将很难正确地找出哪些数据科学项目能够盈利,哪些不能。当发生数据科学错误时——一次是可以接受的——考虑到有一个学习曲线,但是如果这些错误发生在两次以上,这会增加企业成本。

在Python中学习数据科学，成为企业数据科学家。

避免常见的数据科学错误：

1、相关关系和因果关系之间的混乱

对于每个数据科学家来说，相关性和因果关系的错误会导致成本事件，最好的例子是《魔鬼经济学》的分析,关于因果关系的相关性错误，导致伊利诺斯州给本州的学生发书，因为根据分析显示家里有书的学生在学校能直接考的更高分。进一步分析显示,在家里有几本书的学生在学业上能表现的更好,即使他们从来没有读过这些书。

这改变了之前的假设和洞察：父母通常买书的家庭，能营造愉快的学习环境。

大部分的数据科学家在处理大数据时假设相关关系直接影响因果关系。使用大数据来理解两个变量之间的相关性通常是一个很好的实践方法,但是,总是使用“因果”类比可能导致虚假的预测和无效的决定。要想实现利用大数据的最好效果,数据科学家必须理解相关关系和根源的区别。关联往往是指同时观察X和Y的变化，而因果关系意味着X导致Y。在数据科学，这是两个完全不同的事情,但是许多数据科学家往往忽视了它们的区别。基于相关性的决定可能足以采取行动,我们不需要知道原因,但这还是完全依赖于数据的类型和要解决的问题。

每位数据科学家都必须懂得——“数据科学中相关关系不是因果关系”。如果两个关系出现彼此相关的情况,也不意味着是一个导致了另一个的产生。

2、没有选择合适的可视化工具

大部分的数据科学家专心学习于分析的技术方面。他们不能通过使用不同的可视化技术理解数据，即那些可以令他们更快获得洞察力的技术。如果数据科学家不能选择合适的可视化发展模型，监控探索性数据分析和表示结果，那么即使是最好的机器学习模型，它的价值也会被稀释。事实上,许多数据科学家根据他们的审美选择图表类型,而不是考虑数据集的特征。这个可以通过定义可视化的目标避免。

即使数据科学家开发了一个最优秀和最好的机器学习模型，它也不会大叫说“尤里卡”——所有这些所需要的是结果的有效可视化，可以理解数据模式的不同，和意识到它的存在可以被利用来获得商业成果。常言道“一张图片胜过1000个单词。”——数据科学家不仅要熟悉自己常用的数据可视化工具,也要理解数据有效可视化的原理，用令人信服的方式获得结果。

解决任何数据科学问题的至关重要一步,就是要获得该数据是关于什么的洞察力,通过丰富的可视化表达，可以形成分析基础和建立相应模型。

3、没有选择适当的模型-验证周期

科学家认为，建立了一个成功的机器学习模型，就是获得了最大程度的成功。但是，这只是成功了一半，它必须要确保模型的预测发挥作用。许多数据科学家经常忘记或者倾向性的忽视这样的事实，就是他们的数据必须在指定的时间间隔进行反复验证。一些数据科学家经常犯的一个普遍性错误：如果和观察到的数据吻合，就认为预测模型是理想的。已建立的模型的预测效果可以因为模型的关系在不断变化而瞬间消失。为了避免这种情况,数据科学家最好的解决方式就是每个小时都对含有新数据的数据模型进行评分，或者基于模型的关系变化快慢逐日逐月评分。

由于几个因素，模型的预测能力往往会变弱,因此数据科学家需要确定一个常数，用以确保模型的预测能力不能低于可接受的水平。有实例即数据科学家可以重建数据模型。能建立几个模型和解释变量的分布总是更好的，而不是考虑单个模型是最好的。

为了保留已建模型的预测效果和有效性，选择迭代周期是非常重要的，如果做不到，可能会导致错误的结果。

4、无问题/计划的分析

数据科学协会主席Michael Walker说： “数据科学的最高级用途就是设计实验,提出正确的问题和收集正确的数据集,一切工作都要根据科学的标准。然后你将获得结果，并解释它。”

数据科学是一个结构化的过程,以明确的目标开始，随后出现一些假设的问题,最终实现我们的目标。数据科学家往往站在数据之上而不考虑那些需要分析回答的问题。数据科学项目必须要有项目目标和完美的建模目标。数据科学家们如果不知道他们想要什么——最终得到的分析结果将会是他们不想要的。

大多数数据科学项目最终是回答“是什么”的问题,这是因为数据科学家通过手头的问题作分析而不遵循做分析的理想路径。数据科学是使用大数据回答所有关于“为什么”的问题。数据科学家应该通过整合以前未被整合的数据集，主动分析给与的数据集，回答以前没人解答的问题。

为了避免这种情况,数据科学家应该集中精力获得正确的分析结果，这可以通过明确实验，变量和数据准确性和清晰明白他们想要从数据中获得什么实现。这将简化以往通过满足假设的统计方法来回答商业问题的过程。引用伏尔泰的一句话——“判断一个人，是通过他的问题而不是他的答案。”——先确定明确的问题是及其重要的，能够实现任何企业的数据科学目标。

5、仅关心数据

根据博思艾伦咨询公司的数据科学家Kirk Borne，“人们忘记在数据的使用，保护以及统计产生的问题如认为相关关系就是因果关系会产生伦理问题。人们忘记了如果你处理的数据足够长，它就会告诉你任何事，如果你有大量的数据，那么你就可以找到相关关系。如果人们拥有大数据他们会相信他们看到的任何事情”。

数据科学家常常因为得到来自多个数据源的数据而兴奋,并开始创建图表和可视化来做分析报告，忽视发展所需的商业智慧。这对任何组织来说都是危险的事情。数据科学家经常给与数据太多决策制定的权力。他们不够重视发展自身商业智慧，不明白分析如何令企业获益。数据科学家应该不仅仅让数据说话，而且善于运用自身的智慧。数据应该是影响决策的因素而不是数据科学项目决策制定的最终声音。企业雇佣的数据科学家应该是可以将领域知识和技术特长结合起来的，这是避免错误的理想情况。

6、忽视可能性

数据科学家经常倾向性忘记方案的可能性，这将导致作出更多的错误决策。数据科学家经常犯错，因为他们经常说，如果企业采取了X操作一定会实现Y目标。对于特定的问题这没有唯一的答案，因此要确认数据科学家从不同可能性中所做的选择。对指定问题存在不止一个可能性，它们在某种程度是不确定的。情景规划和可能性理论是数据科学的两个基本核心，不应该被忽视，应该用以确认决策制定的准确性频率。

7、建立一个错误人口数量的模型

如果一个数据项目的目的是建立一个客户影响力模式的模型，但是他们仅仅考虑那些具有高度影响力的客户的行为数据，这不是对的做法。建立该模型不仅要考虑那些具有高度影响力的客户的行为数据，也要考虑那些不怎么有影响力但是具有潜在影响力的客户的行为数据。低估任何一边人口的预测力量都可能导致模型的倾斜或者一些重要变量的重要性下降。

这些都是数据科学家在做数据科学时常见的错误。如果你能想到的任何其他常见的数据科学错误,我们很乐意在下面的评论听到你的想法。

原文：7 Common Data Science Mistakes and How to Avoid Them

译者：36大数据翻译组-小金

链接：http://www.36dsj.com/archives/43459

数据挖掘必须要具备知识结构类型

Tue, 12 Jan 2016 12:23:38 +0800

一、概念/类描述

概念/类描述就是通过对某类对象关联数据的汇总，分析和比较，用汇总的简洁的精确的方式对此类对象的内涵进行描述，并概括这类对象的有关特征。概念描述分为：特征性描述和区别性描述。

特征性描述：是指从与某类对象相关的一组数据中提取出关于这些对象的共同特征。生成一个类的特征性描述只涉及该类对象中所有对象的同性。

区别性描述：描述两个或者更多不同类对象之间的差异。生成区别性描述则涉及目标类和对比类中对象的共性。

数据特征的输出可以用多种形式提供：包括饼图，条图，曲线，多维数据方和包括交叉表在内的多维表。结果描述也可以用泛化关系或规则(称作特征性规则)形式提供

例如：利用面向属性的归纳方法(AOI)，在一个商场数据库(2000销售)中进行属性归纳操作，获得了如下的归纳结果：

表2-1 AOI方法挖掘结果表格表示示意描述

区别性描述是将目标类对象的一般特性与一个或多个对比类对象的一般特性比较，这种比较必须是在具备可比性的两个或多个类之间进行。

例如，对某校讲师和副教授的特征进行比较，可能会得到这样一条规则： “讲师：(78%)(paper<3)and (teaching course<2)”，而 “副教授：(66%)(paper>=3)and (teaching course>=2)”; 该对比规则表示该校讲师中约有四分至三的人发表论文少于三篇且主讲课程不超过一门;而对比之下该校副教授中约有三分至二的人发表论文不少于三篇且主讲课程不少于一门。

二、关联模式

关联模式挖掘旨在从大量的数据当中发现特征之间或者数据之间的相互依赖关系。这种存在于给定数据集中的频繁出现的关联模式，又称为关联规则。关联可以分为简单关联，时序关联，因果关联等。这些关联并不总是事先知道，而是通过数据库中数据的关联分析获得的，其对商业决策具有重要的价值，因而关联分析广泛用于市场营销，事物分析等领域。

挖掘关联知识的一个典型应用实例就是市场购物分析。根据被放到一个购物袋的(购物)内容记录数据而发现的不同(被购买)商品之间所存在的关联知识无疑将会帮助商家分析顾客的购买习惯。发现常在一起被购买的商品(关联知识)将帮助商家指定有针对性的市场策略。

比如：顾客在购买牛奶时，是否也可能同时购买面包或会购买哪个牌子的面包，显然能够回答这些问题的有关信息肯定回有效地帮助商家进行有针对性的促销，以及进行合适的货架商品摆放。如可以将牛奶和面包放在相近的地方或许会促进这两个商品的销售。

根据关联规则所涉及变量的多少，可以分为多维关联规则和单维关联规则，通常，关联规则具有：X=>Y的形式，即：A1^…^Am=>B1^…^Bn的规则，其中, Ai (i属于{1,…,m}), Bj (j属于{1,…,n})是属性-值对。关联规则X => Y解释为“满足X中条件的数据库元组多半也满足Y中条件”。

例如：一个数据挖掘系统可以从一个商场的销售(交易事务处理)记录数据中，挖掘出如下所示的关联规则： age(X,”20-29”)∧income(X,”20K-30K”) Þbuys(X，”mp3”)[support=2%,confidence=60%]上述关联规则表示：该商场有的顾客年龄在20岁到29岁且收入在2 万到3万之间，这群顾客中有60%的人购买了MP3，或者说这群顾客购买MP3的概率为六成。这一规则涉及到年龄、收入和购买三个变量(即三维)，可称为多维关联规则。

对于一个商场经理，或许更想知道哪些商品是常被一起购买，描述这种情况的一条关联规则可能是：Contains(X,”computer”) =>contain(X,”software”) [support=1%,confidence=60%]上述关联规则表示：该商场1%销售交易事物记录中包含“computer”和 “software”两个商品;而对于一条包含(购买)“computer”商品的交易事物记录有60%可能也包含(购买)”software”商品。这条记录中由于只涉及到购买事物这一个变量，所以称为单维关联规则。

三、分类

分类是数据挖掘中一项非常重要的任务，利用分类可以从数据集中提取描述数据类的一个函数或模型(也常称为分类器)，并把数据集中的每个对象归结到某个已知的对象类中。从机器学习的观点，分类技术是一种有指导(我们通常称之为有监督)的学习，即每个训练样本的数据对象已经有类的标识，通过学习可以形成表达数据对象与类标识间对应的知识。从这个意义上说，数据挖掘的目标就是根据样本数据形成的类知识并对源数据进行分类，进而也可以预测未来数据的分类。(十一城注：这里的分类和日常生活中的分类含义有些不一样，它是将数据映射到预先定好的群组或者类中。所以很明显，它是有监督/指导的，即它预先定好了东西来引导别人分类。)

分类挖掘所获的分类模型可以采用多种形式加以描述输出，其中主要的表示方法有：分类规则(IF-THEN)，决策树(decision tree)，数学公式(mathematical formulae)和神经网络。

决策树是一个类似于流程图的结构，每个节点代表一个属性上的值，每个分枝代表测试的一个输出，树叶代表类或者类分布。决策树容易转换成分类规则。

神经网络用于分类的时候，是一组类似于神经元的处理单元，单元之间加权连接。

另外，最近有兴起了一种新的方法—粗糙集(rough set)其知识表示是生产式规则。

分类通常用来预测对象的类标号。例如，银行信贷部门可以根据一个顾客信用信息数据库，将功课的信用等级记录为一般或良好，然后根据挖掘得出信用良好的顾客信息特征，应用这些特征描述，可以有效发现优质客户。这一分类过程主要含有两个步骤：

(1)建立一个已知数据集类别或概念的模型。

(2)对学习所获模型的准确率进行测试。如下图所示

四、聚类分析

与分类技术不同，在机器学习中，聚类是一种无指导学习。也就是说，聚类分析是在预先不知道欲划分类的情况下，根据信息相似度原则进行信息集聚的一种方法。聚类的目的是使得属于同一类别的个体之间的差别尽可能的小，而不同类别上的个体见的差别尽可能的大。因此，聚类的意义就在于将观察到的内容组织成类分层结构，把类似的事物组织在一起。通过聚类，人们能够识别密集的和稀疏的区域，因而发现全局的分布模式，以及数据属性之间的有趣的关系。(十一城注：聚类和分类的区别在于聚类是无监督学习，分类是有监督学习。聚类其实也可以理解为是一种分类，只是它这种分类)

数据聚类分析是一个正在蓬勃发展的领域。聚类技术主要是以统计方法、机器学习、神经网络等方法为基础。比较有代表性的聚类技术是基于几何距离的聚类方法，如欧氏距离、曼哈坦(Manhattan)距离、明考斯基(Minkowski)距离等。

聚类分析广泛应用于商业、生物、地理、网络服务等多种领域。例如，聚类可以帮助市场分析人员从客户基本库中发现不同的客户群，并能用不同的购买模式来刻画不同的客户群的特征，如图2-6显示了一个城市内顾客位置的二维图，数据点的三个簇是显而易见的。聚类还可以从地球观测数据库中帮助识别具有相似土地使用情况的区域;以及可以帮助分类识别互联网上的文档以便进行信息发现等等。

五、预测

预测型知识(Prediction)是指由历史的和当前的数据产生的并能推测未来数据趋势的知识。这类知识可以被认为是以时间为关键属性的关联知识，因此上面介绍的关联知识挖掘方法可以应用到以时间为关键属性的源数据挖掘中。

前面介绍分类知识挖掘时曾经提到过：分类通常用来预测对象的类标号。然而，在某些应用中，人们可能希望预测某些遗漏的或不知道的数据值，而不是类标号。当被预测的值是数值数据时，通常称之为预测。

也就是说，预测用于预测数据对象的连续取值，如：可以构造一个分类模型来对银行贷款进行风险评估(安全或危险);也可建立一个预测模型以利用顾客收入与职业(参数)预测其可能用于购买计算机设备的支出大小

预测型知识的挖掘可以利用统计学中的回归方法，通过历史数据直接产生连续的对未来数据的预测值;可以借助于经典的统计方法、神经网络和机器学习等技术。无论如何，经典的统计学方法是挖掘预测知识的基础。

六、时间序列

具有一个或多个时间属性的预测应用称为时间序列问题。时间序列是数据存在的特殊形式，序列的过去值会影响到将来值，这种影响的大小以及影响的方式可由时间序列中的趋势周期及非平稳等行为来刻画。

例如：系统调用日志记录了操作系统及其系统进程调用的时间序列，通过对正常调用序列的学习可以预测随后发生的系统调用序列、发现异常的调用。表2-4给出了一个系统调用数据表。这样的数据源可以通过适当的数据整理使之成为调用序列，如表2-5，再通相应的挖掘算法达到跟踪和分析操作系统审计数据的目的。

七、偏差检测

偏差检测(deviation detection)就是对数据集中的偏差数据进行检测与分析。

在要处理的大量数据中，常常存在一些异常数据，它们与其它的数据的一般行为或模型不一致。这里数据记录就是偏差(deviation)，也就是孤立点。

偏差包括很多潜在的知识，如不满足常规类的异常例子、分类中出现的反常实例、在不同时刻发生了显著变化的某个对象或集合、观察值与模型推测出的期望值之间有显著差异的事例等。

偏差的产生可能是某种数据错误造成的，也可能是数据变异所固有的结果。从数据集中检测出这些偏差很有意义，例如在欺诈探测中，偏差可能预示着欺诈行为。

End.

来源：36大数据

读书笔记--设计的分离--《设计原本》

Thu, 07 Jan 2016 18:21:02 +0800

设计的分离

1 设计与使用和实现的分离

20世纪在设计原则方面最大的进展之一就是设计者和实现者与用户的进一步分离。

2 为什么分离

要求专业化和更长的学习时间；设计的东西复杂，以至于光是设计都要求专业化。

3 分离的结果

沟通不畅，分离导致沟通成本增加；

4 补救措施

补救措施1：用户场景体验；实际调查使用

补救措施2：通过增量式开发和迭代式交付与用户密切交互 ；从项目一开始就与用户保持密切接触。先构建一个能工作的最小功能版本，然后让用户使用，或至少以测试来驱动开发。即使是为大众市场构建的产品，也可以通过部分用户采样的方式进行测试

补救措施3：并发工程；有一种危险那就是如果设计者的个人经验就是全部输入，朴素的样例实现经验将对设计产生过度的影响，最好的平衡就是在主要设计实践中采用并发工程。在这种情况下，真正的实现者积极参与设计过程，他们的丰富经验为设计者有限的实现样例提供了平衡。（在软件领域，同样的实践有时候就被称为敏捷方法）

补救措施4：设计者的教育；理解用户需求和期望的技术与实践；从开始就直接联系用户，以理解用户及其任务。设计者认为自己在这样做，实际上只是在听别人描述用户行为、阅读用户相关用户、分析用户的特点而已，只是在开发过程较晚的阶段才向用户展示复查或验证设计；对直接用户接触和实际实现经验的需要要求更多的项目课程和体验，分析技术和正式的综合方法是必要的工具，

尽早关注用户并持续关注用户，对使用进行经验性测量，迭代式设计。

什么是路径分析

Mon, 21 Dec 2015 17:53:28 +0800

什么是路径分析：
　　路经分析是常用的数据挖据方法，一种找寻频繁访问路径的方法，它通过对Web服务器的日志文件中客户访问站点访问次数的分析，挖掘出频繁访问路径。
如何进行路径分析：
　　用电子商务这类站点来做个简单的举例，大家都知道，电子商务网站大多页面由以下这几种内容组成：
　　站点首页
　　信誉与说服性质的页面
　　产品详细信息和常见问题以及售后、配送信息页面
　　购物车页面
　　支付结账页面
　　那么任何访客的访问路径就可以模拟为从以上五类页面进行引导，然后下一步或者上一步，或者其他点击，直到最后访客离开的页面，这样你就需要根据自己的产品、购物、付款等页面建立你自己站点的路径筛选机制，以便于在最后每周、每月或者更长时间的筛选报告中看到访客的访问路径，根据访问页面的比例来挖掘用户内容页面消费需求，进而设计合理的点击路径和用户选择信息流程，方便用户点击。
路径分析的意义：
　　最大的路径分析在于建立更加完善的用户行为，以帮助用户来了解自己需要的内容!那么以这个基础作为你设计站点的导航依据，你就知道用户需要什么，你给他设计什么，而并非将自己的一种思维方式强加给别人。

产品经理做产品前问自己六个问题

Wed, 18 Nov 2015 20:52:19 +0800

最近做产品很迷茫，不知道自己做的产品到底干嘛的，有时做到一半时或者遇到难题时才反过来思考自己做的产品到底是干什么的，哪类用户会去用，用户会喜欢吗……当这一切问题烦绕着自己时，才发现迷失在产品怪圈里了。当然不排除很多产品的需求来自市场、来自于BOSS敲板定的，但你是产品经理，当你都没办法说服自己时，这产品是否还值得继续做下去呢?

做产品前六问自己：

第一问：你的产品定位是什么?

1、产品是什么?

你要做的产品是被用户使用还是消费，能够满足用户哪些需求?怎么满足用户的需求?做为一个产品经理需知道自己要做的产品是什么，如何满足用户的基本需求，同时对于高级用户的需求如何把握。

2、做一个什么样的产品?

抄袭还是创新?这把握在产品经理手中，但又有多少产品经理敢用自己的薪水和BOSS提创新?很多的产品经理靠经验来支撑一系列的产品，当遇到新的创新机会时是否敢用，问问自己，想做一个什么样的产品，相信乔布斯给很多产品经理做了一个很好的榜样。

3、产品的价值观体现在哪?

没有用户的产品算成功吗?没有浏览的网站算是成功的吗?当你想做一款用户接受的产品时，这款产品的价值由谁来体现?

4、产品的核心功能是什么?

一款能打动用户的产品一定有它的独特之处，随波逐流的产品最终只会走向灭亡，产品的核心功能将是产品打动用户最直接的方式，而其它的功能将围绕着核心功能展开，可以作为核心功能的软性需求，但一定要有产品的核心功能。

第二问：你的产品竞争对手是谁?

1、你的产品有多少竞争对手?

国内有多少竞争对手?国外又有多少竞争对手?“知已知彼，百战不怠”，竞争对手的分析对于你的产品定位，用户群体分析等都有直接关系，多少潜在竞争对手，竞争对手进入相同领域的壁垒有多厚，这都值得你去思考。

2、与竞争对手的区别在哪?

内容?功能?用户群体?……独舞的舞者永远不知道自己的缺陷在哪，在这样的一个大舞台下，你如何做到与竞争对手有明显的区别，如何让你的产品更容易让用户记住，更容易的让用户使用，那就认真的去区分与对手的区别吧。

3、产品的商业模式是什么?

商业模式对于很多产品经理来说是个很模糊的概念，当你不需要对你的产品的价值负责时，你也很少去关注产品的商业模式是怎么样的了。站在产品经理的角度去思考对手的商业模式，从战略、市场、用户等不同的角度去分析。

4、对自己产品有什么规划?

当你认清竞争对手时，对于自己的产品有什么建议和意见?认清别人的优点，正视自己的缺点，提出产品的修改意见，建议性、独到性、深刻性，这应该是你认清对手后你应该做到的。

第三问：你的用户从哪来?

1、谁会是你的用户?

产品的面向用户是哪些，为什么用户会选择你的产品，什么样的人才会用你的产品?认清用户群体，挖掘潜在用户。

2、产品的用户有几类?

对用户进行分类，针对于不同的用户有不同的归类，特别是对于无线类的产品，不同的用户有不同的手机，一个品牌下又有不同的系统，对于用户的分类显得格外重要，给用户最好的产品体验。

3、用户行为和特点是什么?

不同的用户对于产品使用时间、地点、频率、习惯、消费等行为都不同，用户的特点不同，如何正确的区分用户行为和特点，认真分析用户行为特点，从细节做起。

第四问：产品长远规划是什么?

1、你要留住多少用户?

一个产品要留住用户就必须给用户最好的用户体验，解决用户遇到的难题，产品上线可能短期内获得很多的用户，但又有多少长期留下的用户?内测即内测，留给用户一些期待，别拿自己的用户当鱼饵，用户第一。

2、你的产品要占领多大市场?

IE从最早的超过90%的浏览器市场到现在只有超过50%的市场，是坏事吗?不是，IE9很明显收回了很多IE以前用户，市场占有率会是评价产品成功与否的关键，但别为了市场而做市场，别给产品定过高的目标，步步为营。

3、你的产品意识在哪?

一个优秀的产品经理一定有敏锐的产品意识，有所为有所不为，宁愿将些不成熟的想法扼杀于摇篮，可落地的idea才是这款产品需要的，创新只是一部分，抄袭并不是坏事，但别阻止你的产品意识。

第五问：你的产品商业模式是什么?

1、你的产品如何赚钱?

没有永远免费的产品，你的产品怎么赚钱?广告?增值服务?搜索引擎……这些都能成为你的产品商业模式，如何让用户愿意为你的产品买单，至少不能让用户感觉到你是个“奸商”。

2、产品的商业模式用户接受吗?

当用户对你的商业模式不买单时，你是否依旧坚持?你的商业模式对于用户接受承度有多大?有多少用户因为产品的商业模式离开?

3、产品商业模式与公司发展是否一致?

产品的商业模式很多时候是公司高层直接制定的，与公司的发展是否一致，是公司的短期发展目标还是长期规划?

第六问：你做好准备了吗?

1、什么样的态度?

你是以什么样的态度去做新产品?是被动接受，还是充满热情?很多产品经理对于很多不喜欢的产品有排斥，产品需要有感情的，以产品没感情的产品经理不是个好产品经理。

2、做好加班的准备了吗?

产品经理不加班?我听过很多产品经理说经常要加班，同样我也是个经常加班的人，进度控制，沟通很多时候在加班时，才会和产品经理沟通。产品经理，不加班?似乎不存在了。

3、做好被打击的准备了吗?

打击?市场数据的打击，用户的挑“刺”，BOSS的KPI压力……做好被打击的准备吧，产品经理要有一颗坚强的心脏。面对随时可能而来的产品问题需要耐心、细心，一颗永远不能被打败的心。